On Apr 4, 2009, at 00:31, Rémi Després wrote:
Dave Thaler - le (m/j/a) 4/4/09 4:20 AM:
[I wrote:]
On Apr 3, 2009, at 14:56, Dave Thaler wrote:
[...] NAT66 and hence SAF fall into the third class (translation).
My understanding of SAF, from the presentation you gave at the 6AI
session at IETF 74, is that it too is a tunneling solution-- just
that the tunnel is compressed on the wire. [...]
That's not correct. The SAF model is a translate-and-detranslate
model.
I'll decline the opportunity to quibble further over the semantic
distinction between reversible translation and tunnel compression. I
don't think there is as much to contrast between them as you do, but
it's not worth arguing about.
I'll grant that the SAF model is distinct from explicit encapsulation
models, like SAM and RSIP, in that it allows irreversible translation
for legacy hosts until they are upgraded to support the SAF virtual
interfaces that enable reversible translation.
Isn't Christian Huitema's point about multi-homing relevant here?
Any reference where the point is described?
<http://www.ietf.org/mail-archive/web/nat66/current/msg00200.html>
(Remi stated he believes SAM is another SAF mechanism, for example,
and I'm sure the possibilities don't stop there).
Let me confirm here that SAM is intended in particular to restore
e2e transparency, and to support multihoming in an ingress-filtering
compatible way. It uses for this encapsulation with a stateless
address mapping. It doesn't need a new protocol.
Having comments from someone having taken the time to read the
posted draft-despres-sam-02 would be highly appreciated.
I've read the draft. I don't think SAM is a SAF mechanism; it does
not support reversible translation, i.e. what I prefer to think of as
tunnel compression.
I also think it could use some discussion to show how SAM can be
compatible with any-source multicast using embedded rendezvous point
ULA addresses. I think the two methods of overloading the IID portion
of addresses with routing information are compatible, but I'd like to
see a discussion of it.
I confess I am completely lost in regards to the SAM privacy option.
In my understanding, SAF does need encapsulation in the multihoming
case.
I think the point Christian Huitema makes in the message I referenced
above is that NAT66 as currently proposed simply doesn't work-- and
can't reasonably be made to work-- in the multi-homing scenario he
outlines. This should not be news to anyone who has ever encountered
this same problem with symmetric IPv4 NAT multi-homing after lo these
many eons of experience with it. It's one of the Well-known NAT
Problems that the NAT66 draft implicitly leaves unmitigated (where it
defers to RFC 2993 in Section 4-- indeed, RFC 2993 doesn't go into
much detail either: "NATs complicate the use of multi-homing by a site
in order to increase the reliability of their Internet connectivity.").
Without some kind of encapsulation, the local realm routers between
the hosts and the translating gateways cannot match corresponding
forward and reverse path flows consistently to their exterior realm
translator arrays and perverse loops can arise. The people who
designed RSIP and SAM understand this. I'll be surprised if a SAF
mechanism can be defined so that local realm SAF-aware routers can
efficiently perform the matching required to address the problem.
I'll be further surprised if any proposal for defining such routers
receives no significant objections relating to the incentive problem.
This is why I think we'll *lose* if we propose a 6AI solution that
relies on translators, even translators that MUST be augmented with a
SAF mechanism. I don't think we can solve this problem while avoiding
an upgrade for hosts to support an encapsulation.
However your main point, I gather, is that if we publish NAT66 as
an RFC, we should really simultaneously publish some SAF
mechanism. I am of the same opinion here.
Going further, why to exclude publishing an e2e transparent solution
before a non-transparent one, if this is possible. (Of course, it
can only be possible if tried :-))
Agreed. If we're going to insist on publishing a losing solution for
using translators to make perverse loops fast, can we please, at
least, minimize the damage we do end-to-end in the process?
--
james woodyatt <[email protected]>
member of technical staff, communications engineering
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
