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

[TJ]

>-----Original Message-----
>From: sthaug at nethelp.no [mailto:sthaug at nethelp.no]
>Subject: Re: [c-nsp] Humor: Cisco announces end of BGP
>
>> My feeling is based on two things:
>> I don't like the idea of vendors/providers ignoring an RFC just because.
>> 	And note the RFC in question leaves no wiggle room here.
>
>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").
Additionally, 3177 implies the same:
3.
"      -  /64 when it is known that one and only one subnet is needed by
         design. "


Again - I am not saying /126s (or others!) don't work.  And most
implementations let you assign arbitrary values for prefix length.
I am not saying /126s or similar options are (evil|bad), or even
functionally problematic.  
	In fact, RFC3627 explicitly mentions /126s as "less bad than /127s" 
	... but prefers /112s over /126s, and prefers /64s over all of the
above.

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

In closing, I would turn the question around - can you cite chapter and
verse where it says you are allowed to do this?  Hopefully including an
assessment of the potential "unintended consequences" (Note: If it exists,
Great! ... sorry I missed it!)



/TJ