>> The traditional NAPT model which can only permit outgoing >> sessions is not sufficient for an effective transition from v4 to v6. > > Here we differ. I find that to be good enough for the vast majority > of cases, and in those cases where it doesn't work one can deploy > native access so that the NAT-PT box is avoided entirely. > > Given that the vast majority of users are behind NAPT boxes today, > either provided by their ISP or purchased at a store, I have a problem > with anyone saying that providing the equivalent (poor) level of > functionality via NAT-PT is insufficient. the two cases aren't as similar as they may seem at first, for a couple of reasons: 1. "users" != "hosts". in a case where we run out of v4 addresses, it's not sufficient to just move "users" to IPv6 and let the "services" stay in IPv4. and a "solution" that introduces more special cases only creates pain. we need a solution that supports an arbitrary mixture of v4 and v6 peers in an application. 2. "today" != "tomorrow". the Internet (and the way people use it) changes significantly every two years. analysis based on how things are today is not reliable at predicting what will satisfy tomorrow's needs. > If we give v6-only users NAT-PT to access v4-only hosts and native > (non-NAT) v6 access, that is better than they have today. The only > other option is multi-layered v4 NAT, which is arguably worse from an > e2e standpoint and certainly from an administrative one. I see many other options than these. But I'd rather spend time writing up my proposal than answering dozens of emails about it. >>> As a matter of fact, I like your choice of "NAT-XY" to describe the >>> general mechanism you are working on (if I got it right). This IMHO >>> shows the expressive power of generalizing Alain's approach, >>> introducing a dash, as you did, to separate IP versions >>> identifications from "NAT". What about NAT-XX, NAT-XY, NAT-44, >>> NAT-64, NAT-46 ? I would be very happy if this debate, introduced >>> by Ran Atkinson, would end up with such a step against confusion. >> >> To me NAT-64 and NAT-46 are even more confusing, because I >> can't tell which end is which. If sessions can be initiated from either >> the v4 or the v6 side (which IMO is a necessary condition for the >> translation box to be effective), what's the significance of the first >> digit vs. the second? > > I find the distinction mostly useless since any NAT-PT box will > necessarily need to translate a given flow in both directions because > of the state involved. > > However, there is a potentially-useful distinction between deployment > types. For instance, a NAT-PT box at an eyeball site that allows local > IPv6-only hosts to access remote IPv4-only hosts will look somewhat > different than a NAT-PT box at a content site that allows remote > IPv6-only hosts to access local IPv4-only hosts. (And ditto for > reversing the versions for each case...) We may need to distinguish > between roles, because the expectations and configurations will > differ, but the core technology and protocol-mangling is the same for > all of them. Agreed that the different cases require slightly different solutions. I actually think this varies on a per application basis. But I'd rather see a comprehensive solution developed that considers the different cases, than to see piecemeal solutions developed for each separate case. I see a big advantage to having a common interface (API and control protocol) across all of the different solutions. Keith _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf