>-----Original Message----- >From: sth...@nethelp.no [mailto:sth...@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/