On 5/3/10 2:21 PM, Fred Baker wrote: > > Personally, I think the term "NAT" in the moniker for this draft was > particularly unfortunate, and said that to Margaret when I agreed to > co-author. Since we are talking about something fundamentally different than > IPv4/IPv4 NAT, we have the same issue that has been discussed with the term > "realm". We wind up with this discussion, which is not a stupid discussion, > but is off topic with respect to the proposal in question. Well, nat66 *is* a NAT in the literal sense - it does address translation. But the nat66 draft appeared at about the same time that people were starting to use natXY (or NATxy) as a general notation for NATting between two addressing realms, and it's always been a bit confusing that "nat66" was supposed to mean a specific proposal while other usages of natXY were not specific proposals. So it's not surprising if the nat66 group has attracted discussion broader than that proposal. And there's no obvious other place to discuss other proposals for NAT between v6 and v6.
(In hindsight, the best use of the nat66 name would have been as a discussion group equivalent of the Golgafrincham B Ark. Seriously.) The other problem is that we've come to associate several things with NAT that were not, strictly speaking, inherent in address translation, e.g: port translation (NAPT), automatic implicit assignment of bindings within the NAT based on heuristics and observed traffic, lack of fate-sharing between the NAT and its endpoints, etc. But there have always been various kinds of NAT even in IPv4, and we never minded using the term NAT to apply to all of these. It's just that the more common NAT44 configurations involved all of these, so we tended to use "NAT" as a shorthand for the most common case. So I do think that associating the nat66 name with a specific proposal was unfortunate. But even if the name were to be changed, it would still need to have the word "NAT". It still involves address translation, and it still has some of the issues associated with address translation, and the discussion needs to attract people who care about those issues. > > > The goal of those that would like to not have any translation at all - here, > Keith, I'm putting words into your mouth, so please feel free to correct them > - is essentially the counterpoint of that. The world is poorer for the > applications that have not been developed due to firewall and NAT boundaries, > and they would like to be able to build interesting applications that don't > need the byzantine structures to bypass what they consider to be ineffective > and deluded security architectures. If using NAT to flatten the addresses > expressed at the DMZ has been ineffective in preventing attacks (the vast > majority of which come from behind the firewall anyhow) and have made > application development more difficult, what's the point? They would rather > go with the end to end principle as stated by Saltzer > (http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf) and > enable users to make the Internet and the applications that use it more > valuable. That's an accurate reflection of my view. > From my perspective, I would like to achieve some of the goals of all of the > players. I obviously can't both lock and unlock customers, so whatever I do > is wrong there from someone's perspective. But by Network Prefix Translation, > the subject of this list, I can give edge networks the appearance of PI (they > are independent of their providers for addressing) and the service providers > the appearance of PA (they enumerate the ISPs at the edge, O(10^3 to 10^4) > instead of objects at the edge, O(10^5, 10^6, or 10^7)). The boundaries are > address-translucent, not either transparent or opaque, so while I don't give > you what you want I give you something a step in its direction. And I give > Keith what he wants - if he can find it in his heart to have applications use > names instead of addresses, he gets all of the access between applications > that he needs. Maybe I've missed it - I'm certainly not in the loop as much as I used to be. But so far, I've yet to see a name mapping system that is fast, secure, reliable, scalable, location-independent, and with enough support behind it that it will get widely deployed. Frankly, I have no idea how to build such a thing. But until we come up with such a naming system, we're not solving the routing scalability problem - at best we're just moving it, and we could be replacing a merely very difficult problem with an intractable one. Keith
_______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
