Fred, I was not trying to hijack your discussion here. If that was the end result, then I apologize profusely.
If you note, I don't post to this list very often (doesn't seem to be all that active anyway). However, since it is titled "NAT66", I think it isn't particularly harmful to interject once every 6 or 12 months that not everyone is looking for the same flavor of solution of NAT66 that is being discussed here. More specifically to the point, I think the current discussion originated from the idea that there wasn't going to be any concept of "Realm" similar to that which exists in IPv4, under an IPv6 network...... that the entire IPv6 internet was going to be one big "realm". I just was trying to point out that I didn't believe that was going to be necessarily true in practice...even if it was what some people might desire. Christopher Engel > -----Original Message----- > From: Fred Baker [mailto:[email protected]] > Sent: Monday, May 03, 2010 3:39 PM > To: Chris Engel > Cc: Keith Moore; NAT66 HappyFunBall > Subject: Re: [nat66] A bit of perspective > > > 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
