|
From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On
Behalf Of Keith Moore 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf