[ppml] 240/4

michael.dillon at bt.com michael.dillon at bt.com
Thu May 3 04:53:45 EDT 2007


> I'd be happy to write a draft redesignating the class E space if
> somebody can tell me what the consensus is on what it should be
> redesignated to, e.g., "normal" unicast?  RFC-1918 extension?  Half-
> and-half?  Something else?

I suggest that it be redesignated entirely to normal unicast. But you
should include a warning that use of these addresses MAY require
patching software in end-systems and routers, therefore the RIRs should
only allocate/assign these addresses with that warning. The basic
approach is to make the addresses available for those who wish to use
them.

It is too early to provide any advice on the limitations of this address
space since it may be a simple software patch to make Class E addresses
work normally. The RFC should warn about possible issues and recommend
that people test these addresses before applying for an
allocation/assignment.

The value of this RFC is that it will stimulate patching, raise
awareness of the 3 to 5 year horizon for IPv4 exhaustion, and provide a
small supply of addresses in the bank for one last gasp of allocations,
if and when people get caught short when IPv4 non-class-E runs out.
Proper stewardship of IP addresses requires that we do not FORCE people
to transition to IPv6 even if this seems to provide a better
cost-benefit ratio. So we need this RFC to show that we are doing all
that we can to extend the life of IPv4 as long as there is demand for
these addresses.

One thing that should NOT be in the RFC is an RFC1918 extension. In
order to be useful, and extended RFC 1918 space needs to be completely
free of any limitations, even using legacy equipment like SCO Xenix
servers and Windows 3.1 workstations. RFC 1918 space is widely used
inside the corporate world where technology refresh is spotty at best.
Of course, an RFC 1918 extension would help delay IPv4 exhaustion but it
is better to explore doing that with one of the low-numbered /8 blocks,
perhaps the military ones.

--Michael Dillon




More information about the ARIN-PPML mailing list