[ppml] 240/4

[Leo Bicknell]

In a message written on Wed, Apr 25, 2007 at 05:20:14PM -0700, Tony Hain wrote:
> 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. "

> >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.

First off, I believe any vendor for which the code chance was more
than commenting out:

if (ADDRESS_IS_CLASS_E(addr)) {
  warning(foo); /* alternatively error(foo) */
}

Was exercising poor coding.  The flag that has been thrown up is
that the "class E assumption" is littered across code, and possibly
committed to hardware.  If either are true it's a case of amazingly
poor software design.

But I'll give the vendors a full pass on getting that wrong in
revision 1.0.  Back in 1986 that may have been a fine assumption,
and I'll not penalize for that.

However, even if a vendor made that mistake they should have seen
the writing on the wall with CIDR.  When they went through the code
removing /all classful instances" "class e" space should have been
one of them.  Again, a warning or even an error would be fine, in a
small number of places.

I am appalled that vendors response to "we might want to use class
e space" is anything other than "we'll have that fixed in the next
release of code we put out".  To have the response be "we aren't sure we
can fix that for all platforms" or "it may take three years to get that
change out" is amazing to me.

Can the code really be that bad, or are the vendors just that lazy?

Last but not least, I will submit any vendor hard coding /64 into
their IPv6 code (or /56, or /48, etc) is being amazingly short sighted
and stupid.  Code classless, period.  Put checks in the CLI, in one
place, only if necessary.  Be prepared to change later, because odds
are, we won't get it right on the first try.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070425/c32846c9/attachment.sig>