Lol :) I couldn't agree you any more... On 11/28/08, Hallam-Baker, Phillip <pbaker@xxxxxxxxxxxx> wrote: > > > Yes, we all know that it is much easier to get O/S vendors to fix their > billion plus lines of code and the apps vendors to fix their million plus > lines of code than it is to deploy a $50 NAT box. > > What you are proposing here is that we bell the cat instead. > > > -----Original Message----- > From: Mark Andrews [mailto:Mark_Andrews@xxxxxxx] > Sent: Wed 11/26/2008 5:40 PM > To: Hallam-Baker, Phillip > Cc: Eric Klein; Fred Baker; behave@xxxxxxxx WG; IAB; IETF Discussion; > alh-ietf@xxxxxxxx; IESG IESG > Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to > applicationdevelopers > > > In message > <2788466ED3E31C418E9ACC5C316615572FFBAB@xxxxxxxxxxxxxxxxxxxxxxxxxxxx > om>, "Hallam-Baker, Phillip" writes: >> This is a multi-part message in MIME format. >> >> Eric, >> >> The problem here is that you assume that the IETF has decision power >> that can magic away NAT66. Clearly it did not for NAT44 and will not for >> NAT66. >> >> So the real question for App designers is: >> >> 1) Should they design protocols that assume no NAT66 >> 2) Should they regard the assumption that there is no NAT6 as a design >> fault that may lead to lack of interoperability. >> >> The only way that the effort being expended to kill NAT66 makes any >> sense is if the idea is to allow this type of argument to be rulled out >> of scope as similar arguments were ruled out of scope when they were >> brought up in existing protocols that simply do not work properly >> because the design was intentionally made to be unfriendly to NAT. >> >> If we recognize that there is no consensus that applications that are >> not NAT66-agile will work in future then we should agree that the >> reasonable default requirement for an apps WG should be that it should >> build a protocol that is NAT66 tolerant. But I suspect that there will >> be severe pushback against that. >> >> >> Peter Dambier is right in this case, >> >> I would NAT66 my network for the simple reason that very few endpoint >> devices actually tollerate a change in the IP address without at a >> minimum a service interruption. Since I cannot guarantee that my IPv6 >> address from my ISP will never change I am going to NAT66 my internal >> network for the sake of having static numbering inside the network. > > And if you stop thinking IPv6 == IPv4 + big addresses and > start thinking multiple IPv6 addresses including a ULA IPv6 > address + RFC 3484 you get local address stability without > needing a NAT. You use ULAs for internal communication and > global addresses for external communication. > > This isn't future stuff, you can do this today. You can > renumber your external addresses daily and keep internal > sessions up for weeks. > >> The more infrequent you posit the need for renumbering is, the greater >> my reluctance to allowing it will become. If you have a network event >> that happens only once a year it is going to mean a very serious >> disruption when it happens. DHCP only solves some of the problems, I am >> still effectively forced to perform a reboot, I will lose connections >> and this will cost me real time and money to fix. > > If your OS requires a reboot when you renumber get a real OS. > If your apps require that they restart when you renumber get > your apps fixed. > > Mark > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@xxxxxxx > > -- AJ Jaghori Chief Network Architect | Author | Professor ciscoworkz@xxxxxxxxx M: 703.362.5002 _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf