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

[Jared Mauch]

Anyone can write an informational rfc. See apr 1 as an example. One  
can easily write up what they do, or survey responses. You can then  
follow the feedback from your request.

Jared Mauch

On Jul 30, 2009, at 10:31 AM, "TJ" <trejrco at gmail.com> wrote:

>> -----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
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/