Dan, As side note. Outside of the IETF a very coordinated and strong force is stating NAT business view should not be propogated with IPv6 adoption and NAT does not provide security and has a great cost. That body/force is the IPv6 Forum with Task Forces totally dedicated to the deployment of IPv6 in almost every geography in the world. The IPv6 Forum and Task Forces have the attention of Public Governments/Departments and Private Enterprise. If we are successful, and I think we will be, the idea of NAT for IPv6 adoption is dead. We are now running IPv6 network pilot across the U.S. and just had successful two week bring-up period of the new North American Moonv6 network and participation from many entities. Native IPv6 was run across the U.S. and Native IPv6 with IPsec too. www.moonv6.org Moonv6 will stay up too.
Regards, /jim > -----Original Message----- > From: Dan Lanciani [mailto:[EMAIL PROTECTED] > Sent: Friday, October 17, 2003 3:34 PM > To: [EMAIL PROTECTED] > Subject: Re: IPv6 adoption behavior > > > Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote: > > |On 17 okt 2003, at 6:29, Dan Lanciani wrote: > | > |> NAT is stiff competition--and it is the > |> incumbent, so being almost as good is nowhere near good enough. > |> Moreover, > |> a single solution is appealing exactly because it is a > single solution. > |> You have to take that into account even if it is irrational. > | > |So what are you saying? > > I'm saying that IPv6 will be a hard sell since it brings > great upgrade costs and offers a reduction in the > functionality that people expect and depend on. > > |That we should give up on IPv6 because IPv4 w/NAT is so great that we > |don't need it? > > By posing this question, are you suggesting that we really > can't make IPv6 as great as IPv4+NAT? Or that we shouldn't even try? > > |Or that we should add NAT to IPv6? > > By posing this question, are you suggesting that the only way > to make IPv6 as great as IPv4+NAT is to add NAT to IPv6? If > that is true then the market will take care of adding NAT to > IPv6; we don't have to bother. > > |I'm not buying. IPv6 is superior to IPv4 (with and without > NAT) in many > |ways. > > Unfortunately, being "superior" in some abstract sense is not > sufficient for something as utilitarian as a networking > protocol suite. We have to examine actual usage requirements. > > |The trouble with networking has always been that even poorly > |designed networks can work well so there is little incentive > to do it > |right. > > I don't buy into the idea that users are not entitled to the > functionality that they now enjoy just because it is somehow > tainted by having once been provided by NAT. If you are > claiming that there is just no way to deliver that > functionality with a network that is *not* poorly designed > then I think you have to reconsider your definition of "poorly." > > |> NAT was not as painful as it was supposed to be. > |> For most users, NAT was empowering. Anyone--even an insignificant > |> residential > |> client--could hook up an entire network of their own. > | > |But this entire network only enjoys a subset of the capabilities of a > |network connected without NAT. > > Your statement is extremely misleading, comparing apples and > turnips. It is true that _a_ network connected without NAT > enjoys a slightly larger set of capabilities (though they are > capabilities that are not important to the typical NAT user) > than the same network connected with NAT. But the > residential client in question typically does not have the > opportunity to connect _her_ network without NAT because her > ISP provides only one dynamic IP address. The correct > comparison, then, is between a NAT-connected network and a > network that is not connected to the internet at all. Which > one enjoys greater capability? > > |Application builders are bending over > |backwards to work within those limits, which costs time and > money and > |isn't 100% successful. > > Even if this were true, it merely proves that the market will > bend over backwards to accommodate the functional > requirements of the users. This is a valuable lesson that we > should take to heart. We cannot ignore those requirements > with impunity. But why did you bring this up at all? It > seems to be part of the argument that NAT is bad (and by the > way, I agree that NAT is bad--it just happens to be better > than all the alternatives) and therefore we need not provide > any of the good things that NAT offers. Why can't we provide > a protocol that offers the same benefits that NAT offers but > which does not require application builders to bend over backwards? > > |But this discussion is moot as there is no requirement that IETF > |protocols are adopted by 100% of all internet-connected systems. > > Wow. If that renders this discussion moot, wouldn't it > render any discussion of anything moot? > > |> It would be interesting to take a poll of people whose ISPs do not > |> offer > |> a globally routable IPv4 address > | > |That is impossible as ISPs by definition offer access to the internet > |which means providing globally routable addresss space. So > such an SP > |wouldn't be an _I_SP. > > Wow. I know this whole topic is sensitive, but resorting to > acronym games? > > |> |will show that we will > |> |need well over 400 additional /8's to get a single > address to 20% of > |> the > |> |population outside the countries that already have one or more for > |> 20% of > |> |theirs. This is for an HD ratio of 90% which is well in excess of > |> |the > |> pain > |> |threashold documented in RFC3194. > | > |That's 6.4 billion addresses, a little more than four times what we > |have available today, for no more than 1.3 billion users. > Can someone > |please explain where the other 4 addresses per user go? > > I did not write the above quoted text and I have no > explanation for it. > > Dan Lanciani > [EMAIL PROTECTED] > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [EMAIL PROTECTED] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
