[ppml] 240/4

[Tony Hain]

Leo Bicknell wrote:
> In a message written on Tue, Apr 24, 2007 at 12:03:04PM -0700, Tony Hain
> wrote:
> > Even if the vendors implemented a change and shipped it within 18
> > months (an aggressive window), there is a very, very, very large
> > installed base of systems that can't/won't be upgraded to allow use of
> > a block that was 'undefined' at the time they were tested & shipped.
> > By the time those work their way out of the network, we will be long
> > past the point where the 240/4 block might have been useful.
> 
> I would hope that anyone who interpreted "reserved" to mean "code so
> that it can never be used" has been fired from all vendors.
> That's a mistake we should never make again.
> 

Reserved does not mean the same thing in all parts of the IANA space. You
appear to assume the 'right thing' to do was to just make them respond like
all the 'Reserved' space below 224. Why would a vendor assume that? The
224/4 block was 'special', and the RFC text says:
" Note:  No addresses are allowed with the four highest-order bits
      set to 1-1-1-1.  These addresses, called "class E", are reserved. "

If the vendors had ignored that and said 'despite 224/4 being special we
will make the 240/4 block just like everything below'; then someone decided
that 'googlecasting' (don't come after me if that is already trademarked -
if not it's mine) needed an identifiable address block for special handling,
everyone would be screaming about the 'incompetents' that ignored the RFC
and built up an installed base that could not be changed to use that space
according to the new definition.  

>From a vendor perspective there is no simple answer, so the 'right thing' to
do is to believe that space will be defined later, and lacking another
definition to test against just obey the RFC and disallow use of that block.
If you want that status changed, write an RFC to define it differently. Just
don't expect the installed base to conform to changes in definition.

Tony