ietf
[Top] [All Lists]

240/4 unreservation (was RE: Last Call: <draft-weil-shared-transition-space-request-03.txt> (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)

2011-09-26 09:07:48

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.

Now, compare that with the discussion of adding a new set of non-unique address 
space where you likely have to add code to catch this if you care about the 
scope of the address that you've been assigned.
The authors (or at least one of them) of draft-bdgks maintain that they've 
discussed this with vendors 
(http://www.ietf.org/mail-archive/web/opsawg/current/msg01879.html, search for 
Linksys to find the relevant section of the message) and the vendors seem 
willing to make code changes in support of this, at least in new gear. Now this 
doesn't represent a commitment nor a critical mass necessarily, but I'm 
wondering why 240/4 is so much harder?

Also, I don't see why we don't use all of the tools in our toolkit. We're out 
of IANA space, except for a whole /4, which keeps getting shot down due to the 
perceived problems with getting global support, when there are probably 
multiple use cases that absolutely don't require global support. Why haven't we 
gone ahead and unreserved the space, and then let those interested in using it 
beat on the appropriate folks to fix it, rather than not even trying? I think 
that it would be fully possible to caveat use of the space appropriately so 
that people know what the risks are, but right now it's essentially useless 
even for those who might be able to try.
Seems wasteful, no?

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.

Wes George

________________________________
This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>