On Sep 26, 2011, at 10:07 AM, George, Wes wrote:
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] 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.
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf