On Mon, Sep 26, 2011 at 9:41 AM, Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Sep 26, 2011, at 10:07 AM, George, Wes wrote: > > > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf > Of Keith Moore > Sent: Friday, September 23, 2011 10:04 PM > To: Cameron Byrne > Cc: IETF Discussion > Subject: Re: Last Call: <draft-weil-shared-transition-space-request-03.txt> > (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC > > On Sep 23, 2011, at 9:53 PM, Cameron Byrne wrote: > So if there is going to be breakage, and folks are willing to fix it over > time because the good outweighs the bad (I personally do not believe this), > then why not dedicate 240/4 for this purpose? The 240/4 work has been shot > down multiple times ( I don't know the history ), are we now changing the > rules for the end run ? > >>It's hard to know for sure, but I believe there's greater risk associated >> with use of 240/4 than with a /10 from existing public IPv4 space. That is, >> I think more software would be needed to allow 240/4 to be used reliably. > > WEG] you know, the more I think about this line of logic, the more I wonder > about it. > In essence, the 240/4 problem is that lots of host and router > implementations have one or more functions in their input validation code > that says “240/4 == invalid” thus preventing you from configuring or using > it. To my (admittedly oversimplified) view, this is a simple matter of: > 1) Search source code for “240” > 2) Comment out any relevant code you find > 3) Recompile, test (changes only), ship > I’d be happy for one or more folks who have some experience with the > appropriate bits of Windows, Linux, MacOS, IOS, JunOS source code would > explain where I’m oversimplifying. > > I think that's basically right. The problem isn't in the difficulty of > finding these changes and fixing them, for currently maintained code. The > problem is in the zillions of systems in the field that have assumptions > about 240/4 wired into them, most of which either have no automatic upgrade > mechanism, aren't set up to use it, or aren't being maintained. This is > of course, in addition to any changes that have to be made to application > software because of its wired-in assumptions about 240/4. By contrast, if a > /10 from public unicast IPv4 address space is used, only the application > software has to be changed (if the application software needs to care about > whether an address is ambiguous). That's a much smaller impact, though > probably still a significant one. > Actually it wouldn't bother me personally if the /10 were specified only for > use with DS-Lite or with some other service that provided native v6 prefixes > to customers in addition to any IPv4 service...though I don't know of any > way to enforce that. > This is the 2nd time DS-lite has come up, this comment is off topic, but i want to make sure the inputs are right. DS-lite would not use this space and does not need this space, DS-lite assumes the following: RFC1918 + IPv6 public in the end-site (my home) with a B4 tunneling home gateway, IPv6-access network (DSL/Cable access network), and public routable space in the CGN/AFTR. DS private IPv4 LAN -----{IPv6 only access network} ---- CGN ---- Internet draft-weil space is only for what draft-weil says it is for, and that is the NAT4'4'4, the middle 4 SP access network or to facilitate 6to4-PMT (NAT66 of 6to4). IPv4 LAN ---IPv4 access with shared space---- CGN --- Internet IMHO, this allocation does not move IPv6 forward... it just makes NAT444 more possible and "fixes" 6to4 so that the IPv6 part returns to the correct IPv4 NAT network. DS-lite does move IPv6 forward. But, AFAIK, the draft-weil folks want a /10 so that they don't have to spend money to upgrade their access network or associated CPE. In this way, end points that need real unique IPv4 space are subsidizing the upgrade deferral of these networks. Cameron > I’m willing to write a draft about it if there are people willing to support > it, but I only have so many windmills that I can tilt at per cycle, so I’d > like to hear support either privately or publicly before I undertake it. > > Honestly I'd guess that if vendors started changing their code today, it > would be 10 years before 240/4 could be widely used in the field. > Keith > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf