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" <[email protected]> wrote:
-----Original Message-----
From: [email protected] [mailto:[email protected]]
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 [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
