OK, so for your usage case, you want the exact concepts in IPv4/IPv4 NAT re-implemented in an IPv6/IPv6 world. Got it.
Can we who are talking about something else discuss the topic of this list, please? On May 3, 2010, at 12:40 PM, Chris Engel wrote: > Fred, > > On 10,000 ft level, I think that the real success story of the internet is > that it allows for a wide diversity of usage cases and supports organizations > with a wide diversity of goals. If it's going to continue to be successful in > future, I think it will need to continue to support such diversity of > goals/usage. Those goals/usage cases don't have to be compatible with each > other. In fact, I think that would be an unachievable goal. However, I > believe there needs to be room for all of them to continue to exist on the > Net. > > I really don't have any problem with anyone who values "end-to-end > transparency" as their goal for their OWN usage case of the NET. I have a big > problem when some-one is trying to tell me that goal MUST apply to my usage > case as well, whether I want it to or not....and then work to retard any > public standards being published which describe how my desired goals might be > enacted. > > For example, peer to peer networking is pretty much anthetical to the > standards that my organization embraces. That being said, I have never had a > problem with anyone attempting to publish protocols involved with > peer-to-peer applications. The end result of such publication might even make > peer-to-peer applications more popular...which could even increase MY > workload in attempting to prevent unauthorized use of such applications on my > network. However, I've never seen that as a justification for my attempting > to interfere with the publication of such standards. I'm pretty sure that the > authors of such protocols are attempting to provide a solution for people who > WANT to embrace it... not make the lives of people who don't more > difficult.... even if that is part of the effective result. > > If you or Keith or others don't see the value in the kind of NAT solution > that I want to use, that's fine. I can't make you see it if you don't want to > do so. If Cisco or Apple or whoever don't want to sell that sort of equipment > for IPv6 that's fine as well. All that will do is limit the market segment to > which you can sell your products. It's a free market economy, if you don't > offer such solutions, I'm pretty sure if there is a strong economic demand > for them (which I believe there will be) that those of us who strongly desire > such solutions will eventually find a vendor willing to fill that demand and > accept our cash. All that is really happening right now without that is > another factor slowing wide scale adoption of IPv6. > > I think on the very first exchange of e-mail I had with Margaret, I mentioned > that this particular proposed implementation of NAT66 didn't sufficiently > cover my usage requirements. However, I was happy to see it brought forward, > as I definitely could see how it might prove useful to certain usage cases. > From my perspective, the greater variety of options available the better.... > and having publication of standards for those options is better then not > having them. > > My purpose here is simply as a reminder that there is a large user segment > that is currently under represented in discussions taking place on the > subject of NAT in IETF and certain other venues.....and that indeed there is > VERY far from universal agreement on the goals of end-to-end transparency or > reachability. In essence, I'm attempting to provide a counter-point for those > who consider such goals as an apriori that everyone is going to be willing to > embrace. > > > > > > Christopher Engel > >> -----Original Message----- >> From: Fred Baker [mailto:[email protected]] >> Sent: Monday, May 03, 2010 2:21 PM >> To: Chris Engel >> Cc: Keith Moore; NAT66 HappyFunBall >> Subject: Re: [nat66] A bit of perspective >> >> >> >> On May 3, 2010, at 10:25 AM, Chris Engel wrote: >> >>> On the network level, I basicaly want something that entirely >>> abstracts my internal architecture from my external >> advertisement of >>> services...and essentialy functions as a proxy/intermediary >> between my >>> internal devices and thier external presence at the >> boundary between >>> internal/external. NAT very handly does that currently in >> IPv4. From >>> the discussions that I've had with alot of people involved with >>> IPv6...and many of the people who have strongly argued against any >>> sort of NAT in IPv6... they basicaly seem to be disagreeing >> not just >>> with the particular method I want to use....but with my end goal >>> itself. >> >> I would agree that many in the IPv6 community disagree with >> your goal. Their fundamental objective is end to end >> transparency, and your fundamental objective is end to end >> opaqueness. You disagree with each other. I understood from >> your previous emails in this thread that you felt they were >> "wrong" or that you felt that they felt you were "wrong"; I >> don't think either is "wrong" per se, but you certainly disagree. >> >> 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. When the IETF had a BOF on the topic, that was >> incredibly clear. We had a proposal on the table which was >> most decidedly *not* re-implementing IPv4/IPv4 NAT in an >> IPv6/IPv6 world, but the entire discussion from the floor was >> "we don't want to re-implement IPv4/IPv4 NAT in an IPv6/IPv6 >> world", largely non-responsive to the topic at hand. It winds >> up consuming a lot of cycles, is very emotional, and drowns >> out reasonable discussion on anything else. Take a look at >> this thread as an example. We have collectively exchanged 39 >> messages (this is the 40th), of which perhaps half a dozen >> have been on topic and the remainder have been related to >> re-implementing IPv4/IPv4 NAT in an IPv6/IPv6 world, >> something which is specifically not the topic of the list. >> >> Regarding NAT, though, in >> http://www.ietf.org/rfc/rfc4864.txt, some strong proponents >> of the transparent model addressed what they thought were the >> primary reasons for the use of NAT. They didn't cover this >> one, so to speak. But it might be worth your while to >> acquaint yourself with their viewpoint. In short, NATs not >> only achieve a certain level of obfuscation of the network >> layer, they make it harder to build applications of a certain >> class - applications in which the address of one's peer must >> be known at the time one wants to use it. Real time >> applications, such as VoIP and Video/IP, fall in this >> category. More generally, the entire realm of peer-to-peer >> applications does. The imposition of NAT has not altogether >> stopped such development, though; what it has done is make it >> a lot harder, resulting in companies like Napster, >> BitTorrent, and Skype building byzantine overlay networks to >> overcome the issues it presents. In the realm of voice and >> video, it has engendered RSIP and the use of SIP Proxies as >> gateways between domains. NAT hasn't actually protected any >> networks, I will argue; it has merely made scaling the walls >> a little harder. >> >> 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. >> >> For my part, and the part of this proposal (and the ILNP >> proposal that RRG is putting forward), I am all for the free >> development of useful applications. I don't see the value of >> NAT, given its history of not stopping attacks and of >> preventing applications. I see a problem that needs >> addressing though, related to management of the backbone >> route table. In short, we now have O(10^5) prefixes in the >> IPv4 route table, and perhaps two years from now will easily >> have O(10^6) as people buy and sell prefixes. As an equipment >> vendor, I have no problem with that - if you'll pay for the >> memory, I'll happily sell it to you. But I don't want to hear >> about either capex or opex, I don't want to hear about >> "green" aspirations, and I don't want to hear about the price >> of the equipment. You make the bed, you lie in it. As we >> collectively move to IPv6, we have a choice. We can replicate >> the IPv4 swamp, complete with its route table, or we can >> change it. I vote that we change it. >> >> In the area of addressing, networks at the edge are pushing >> back very hard on the provider-allocated addressing model, >> and are driving for provider-independent addressing. Reason: >> they don't want to be captives of their providers. I'm >> sympathetic with them. But consider the implications: if they >> all have PI addresses, we are enumerating the objects at the >> edge, and even today we have O(10^7) or more objects at the >> edge. PI addresses take us in the direction of a swamp at >> least as bad as that in the IPv4 network. Service providers >> find the PA model very attractive, both because it provides a >> market lock on their customers and because it helps them >> manage their route tables. >> >> 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. And for those that >> operate networks, it reduces their capex and opex. It >> requires everyone to think a little differently, but if they >> are willing, they get most of what they are looking for. >> >> I hope this is useful. >> http://www.ipinc.net/IPv4.GIF _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
