[c-nsp] Humor: Cisco announces end of BGP

[sthaug at nethelp.no]

> >Please cite chapter and verse. As long as you use static IPv6 addresses,
> /126
> >is fine. No, a /126 address does *not* have to be based on a 64 bit
> interface
> >ID.
> 
> 
> Sure ... 
> 
> RFC4291 
> 2.5.1
> "   For all unicast addresses, except those that start with the binary
>    value 000, Interface IDs are required to be 64 bits long and to be
>    constructed in Modified EUI-64 format. "
> 
> 2.5.4
> "   All Global Unicast addresses other than those that start with binary
>    000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
>    described in Section 2.5.1.  Global Unicast addresses that start with
>    binary 000 have no such constraint on the size or structure of the
>    interface ID field. "
> 
> That would seem pretty clear cut to me, rather explicitly calling for 64bit
> IIDs in all unicast cases (excluding the "starts with 000 block").

In theory, I agree it would seem pretty clear. In practice, Appendix
A, "Creating Modified EUI-64 Format Interface Identifiers", leaves so 
much wiggle room that you can drive a truck through it.

Another point worth mentioning here is that RFC 4291 does not use the
normative language ("MUST", "MUST NOT" etc.) of RFC 2119.

As an example, the 2001:DB8:0:0:8:800:200C:417A unicast address on page
4 - are the lower 64 bits (0008:0800:200C:417A) constructed according
the Modified EUI-64 format or are they not? Since they don't have a 1
in bit position 6, they are clearly not based on a globally unique IEEE
MAC address...

> All I am saying that I prefer the spec(s) be updated based on real world
> preferences/implementations, and that this proposed change get reviewed as
> thoroughly as the original spec(s) did to ensure nothing breaks.  I fully
> realize that the real world doesn't always agree with the IETF, but in
> something this "low down" and yet relatively easy to codify I fail to see
> why it hasn't been done, unless there is a reason not to?  (If you don't
> mind wiggle room in specs, or implementers "reinterpreting" the specs, that
> is (cough) fine.)

Wiggle room is sometimes good, not always. In this case I would argue
that we are many years too late to change existing IPv6 implementations,
and that the wiggle room in RFC 4291 is just what we need.

And I plan to continue using /124 static address for our backbone links.
As others have mentioned, the fact that autoconfig explicitly doesn't
work with such addresses is a *good* thing.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no