[c-nsp] Humor: Cisco announces end of BGP
TJ
trejrco at gmail.com
Thu Jul 30 10:31:25 EDT 2009
>-----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
More information about the cisco-nsp
mailing list