From: ietf-bounces(_at_)ietf(_dot_)org<mailto: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
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.
<snip>
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.
WEG] See that's the point, I think we keep looking at this from a "boil the
ocean" perspective. The question is not, "could we use 240/4 as more global
unicast space?" as the ship sailed on that years ago when IETF apparently
decided it was too hard to change and nothing should be done.
The question is, "if the space were unreserved, are there valid use cases where
networks within a given administrative control might be able to make use of it?"
This idea of limited use puts the impetus on the network/operator itself to
identify a use case and force their vendors to confirm support for the space,
but it makes it more likely that for that definition of "widely used" it would
be successful. But if IETF/IANA removes the reservation, this means means that
people can go in and check in the update to the 3 lines of BSD kernel code
(based on a private reply I received on the matter) necessary to remove the
block, vendors can stop putting that logic into new devices, etc, thus making
it more attractive to attempt to use the space from that point forward.
I don't expect this to be a perfect solution for legacy IPv4-only devices, but
I do expect that it could have some use, especially when compared with other
alternatives.
Cameron's example is a case in point - you have a mobile provider who for the
most part tells the vendors exactly what features their user devices need to
support and they are built to spec, plus a closed network with NAT at the edges
that is currently squatting on public space. This means that a large amount (or
possibly all) of the devices that would need to support use of this space are
within their administrative control, and they would be responsible for updating
the code to a version that won't reject 240/4, and they could contain it within
their environment by keeping it inside of the NAT border.
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