Hi, all, Following some points made on the ML, please find below some clarifications on 4rd-U.
2012-04-02 17:36, Cameron Byrne: > On Apr 2, 2012 8:17 AM, "Wojciech Dec" <[email protected]> wrote: > ... > > Woj> Well, in terms of facts we have > > 1. 4rd-U does not supporting single translation mode, > Not claimed to. > or if it does then is requires NAT64/BIH/Something else. > The 4rd-u-06 draft says: "This specification only concerns IPv4 communication between IPv4-capable endpoints. For communication between IPv4-only endpoints and IPv6 only remote endpoints, the BIH specification of [RFC6535] can be used. It can coexist in a node with the CE function, including if the IPv4-only function is a NAT44 [RFC1631]" The reference here to NAT64 and "something else" is clearly inappropriate. > (How anybody thinks that deploying 4rd-u + "something" else is manageable is > a mystery) > In RFC6535, BIH lets the IPv4 stack to be used if only an AAAA record is received (which characterizes an an IPv6-only host). If 4rd-U is activated in the same node, IPv4 packets of the IPv4 stack are simply tunneled across IPv6, according to the 4rd-U specification. No mystery. > > 2. 4rd-u is incompatible with NAT64 use or deployment > Not claimed to, and no need to. 464XLAT, for example, doesn't need MAP-T (and even less MAP-E) to work with NAT64. In this respect, 464XLAT and BIH work identically. The sentence of RFC6535 that doesn' "recommend" using BIH for double translation, isn't a formal objection to using it if it is the only way to satisfy a need. (In this instance, the exact need that the 464XLAT draft identifies) I added a copy to Teemu Savolainen, a better specialist of BIH than I am. > > 2. MAP solution (call it MAP, divi, or other variants) has proven deployment > > Just for my own clarification, do these proven deployments use static ipv4 > address+port sharing with coordinated dhcp assignment? These are the key > feature and method of map-t, and it would be good to know if and how these > key features have been proven. > +1 (To renew, once more, my request to know which set of MAP-T mapping rules have actually been validated.) > Cb > > > 3. Any operator who runs NAT64 today is a proof point that 4rd-U solves > > problems that are non-issues to operators. > According to this statement, co-authors of 4rd-U coming from network operators don't understand their problems as well as Wojciech does. I find this doubtful. > > 4. 4rd-u changes the basic structure/use of the v6 header, which is a > > change to IPv6 that needs to be vetted by 6man, etc. Creating such "novel" > > (bogus?) IPv6 packets, that no regular IPv6 host today will recognize and > > use, effectively creates a new IPv6 protocol sub-class. > In discussions in Paris with Dave Thaler, Dan Wing, Stuart Cheshire, Lorenzo Colitti, I didn't get any indication that using the unused u-g combination, if useful, would be a big issue. Making a backward-compatible extension of RFC2373 shouldn't in my understanding be too difficult (if confirmed to be useful for 4rd-U). > > > > Indeed 4rd-u deserves an "experimental" status track, more than anything. > Well, with no WG consensus achieved on any 4via6 solution working on mesh topologies, that's probably the best that can be done so far. Still, it is a step forward. Regards, RD > > > > -Wojciech. > > > > _______________________________________________ > > Softwires mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/softwires > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
