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
