Regardless of the ease of implementing the change (which is quite simple
in the linux case for example), the question is really what is the
impact on existing systems? The presumption is they won't change until
they age out of the network which is the same reason any a+p solution
that requires host signalling or new private scope unicast ranges have
negative implications for the support of legacy systems. By that measure
240/4 is unequivically not useful (for this purpose). It was also not
useful 4 years ago (for this purpose).
On 9/26/11 07:07 , 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.
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf