On 2 April 2012 19:10, Rémi Després <despres.r...@laposte.net> wrote:
> > > > Woj> Well, in terms of facts we have > > 1. 4rd-U does not supporting single translation mode, > > Not claimed to. > It's good to get clarity now that previous 4rd-U claims of supporting services such as web-caching, log-on-portals, etc. are now false, and no longer claimed. MAP(-T) continues to allow these. 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. > There already is a decent solution for IPv4-IPv4 only, without loss of info = IPinIP tunnel. Now, let "something else" be BIH (or whatever), this is an admission that 4rd-U is not any kind of unified solution, but rather a different collation a novel "pseudo-tunneling" solution with an addon in the form of BIH. Ironically since BIH is NAT64 based, all the problems 4rd-U tries to solve, remain still applicable in that BIH dimension. It is thus no complete solution. > > (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. > The managing of a MAP deployment looks far much simpler, and less mysterious too, including the use of less moving parts. > > > 2. 4rd-u is incompatible with NAT64 use or deployment > > Not claimed to, and no need to. > That's your call, but its neither the starting point of most customers who deploy and use NAT64 today, or the direction which sees NAT64 usage. With 4rd-u, such NAT64's need to be replaced or extra operational complexity brought in by running in parallel with 4rd-u (possibly serving the same end points). > > 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. > This is not about BIH, but rather that 4rd-U needs "something else" to cover the MAP space. It thus is no unifying solution at all as it claims to be > > > 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.) > One work in progress... http://tools.ietf.org/html/draft-sunq-v6ops-ivi-sp-02. More data was presented at the softwire IETF interim (lost the link for now) > 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. > Rather, according to this statement co-authors of MAP, including numerous operators, don't care about the problems 4rd-U solves. > > > 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). > Not sure how the above constitute the v6man WG, or what the personal opinions of these individuals have to do with the fact that ultimately you're changing core IPv6 semantics, incl those of the fragmentation header, which is not within softwire charter. > > > 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. > For 4rd-U experimental would indeed be a fitting track, given that it has a lot of experimentation and proving yet to do, less so for MAP. -Woj. > > Regards, > RD > > > > > > -Wojciech. > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > > > > >
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
