RFC6177 that you quote also states: "The actual intention has always
been that there be no hard- coded boundaries within addresses, and that
Classless Inter- Domain Routing (CIDR) continues to apply to all bits of
the routing prefixes."
Also the context of RFC6177 is end site assignments, not link assignments.
Therefore IMHO prefixes longer than /64 should be explicitly supported
by any parsing system.
As for the human readable form, I agree with the assertion that it is up
to the humans to ensure that they are unambiguous, without having to
resort to assumptions.
regards,
RayH
Brian E Carpenter wrote:
Ray,
On 2011-09-20 20:48, Ray Hunter wrote:
Message: 8
Date: Tue, 20 Sep 2011 16:50:32 +1200
From: Brian E Carpenter<brian.e.carpen...@gmail.com>
To: Randy Bush<ra...@psg.com>
Cc: ipv6 deployment prevention<ipv6@ietf.org>
Subject: Re: IPv6 prefix notation
Message-ID:<4e781b98.7080...@gmail.com>
Content-Type: text/plain; charset=UTF-8
On 2011-09-20 15:58, Randy Bush wrote:
I think that RFC 5952 (an update on RFC 4291) provides the
guidance
you describe in section 4.2.3.
I see that it does (and the errata on 4291 do not). Thanks.
A reasonable prefix will end with at least 64 zeros, so :: will
always be the last element according to RFC 5952. (Unless someone
uses prefixes longer than /64, in which case I for one don't care.)
> a shame. once upon a time, the academics in the ietf did care
about
operational networks.
I'm not sure that I've yet seen a case where>64 is operationally
justified, except for the /126 or whatever discussion we had a while
back for pt2pt links - where I don't think the problem that started
this thread would apply.
Wait a minute. Have I really understood this statement "A reasonable
prefix will end with at least 64 zeros" correctly?
Yes, in the context of any prefix handed out to a user; that should
be at the *longest* a /64. RFC 6177.
In that case, the notation as defined by RFC 5952 settles the original
question in this thread (which has mysteriously jumped between WGs).
Of course ISPs may choose to use longer prefixes inside the ISP network,
out to /127 (as Steinar said; my /126 was a mistake) but that isn't the
majority case.
Firstly, I have not seen any discussion in the IETF that says IPv6 MUST
NOT support CIDR beyond /64.
I would oppose any such an assertion. In fact, I have written (but have
not published) a sketch ID on how IPv6 SLAAC could be extended to
support non /64 prefixes in the future.
But SLAAC today doesn't do that, so it isn't a current operational issue.
Secondly, there are people who code IPv4 prefixes into IPv6 prefixes to
combine them in a single DB table of rules e.g. IPv6 ::ffff:10.0.0.0/104
is used to represent the equivalent of IPv4 10/8 [although I've since
come to the conclusion myself that it's simply better and easier to have
one DB table per address family]
Yes, which is why the ::ffff:0:0/96 prefix was defined as long ago as RFC 1884
for IPv4-mapped IPv6 addresses. I have written it as RFC 5952 requires,
and it's clear that ::ffff/96 is *not* the same - its correct interpretation
can only be equal to ::/96.
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
