2007/631 Class E IP Address Configuration

[Darren Reed]

Erik Nordmark wrote:

> Nicolas Williams wrote:
>
>> You could wait until the IESG issues the protocol action placing the I-D
>> on the Standards Track, rather than waiting for it to be an RFC.
>>
>> In any case, there are *two* unexpired, individual submission I-Ds on
>> this topic.  Both have "I-D Exists" as their status.  That is definitely
>> not enough.  The ARC should at least wait for there to be an AD
>> sponsoring one of these (or other) documents, and preferably there
>> should be some consensus somewhere about doing this.  In this case I
>> think the best place to seek consensus would be the IETF list, or else
>> ask the IAB for their view on the matter.
>
>
> In case the news haven't been received, the current estimate is that 
> the last IPv4 address block will be handed out by IANA in early 2009 - 
> that is less than 18 months away.
>
> (The peer-reviewed powerpoint presentation that explains this is up on 
> http://www.youtube.com/watch?v=_y36fG2Oba0 ;-)
>
> Given that everybody that needs more IP address space might not be 
> ready to move to IPv6 in 18 months, being able to use Class E would 
> buy some time.
>
> But given our release cycles it would seem a bit silly to say that we 
> must wait; for all I know it could take the IETF and the IESG more 
> than 18 months to agree on a draft even if the concept that is 
> proposed has rough consensus and running code.
>
> If we want Solaris to be relevant in the Internet thing, I think we 
> should try to move fast on this one. And I don't know of any possible 
> harm we could cause by removing the checks we have in the code which 
> today prevent Class E addresses from being assigned and forwarded by 
> Solaris. Do you see anything that could break?


The only concern I have had is with strangeness that might happen
if 255.255.255.255 is seen as a broadcast address that applies to
only one NIC and is not seen to be local to all NICs.

(non-psarc stuff...)
Also, we need to fix various commands, e.g. ping, where
"ping -s 255.255.255.255" returns an error.  A code sweep to replace
inet_addr() with inet_aton() seems required in order to stop broken
behaviour.

Darren