Ray, We agree.
Regards Brian Carpenter On 2011-09-21 20:58, Ray Hunter wrote: > 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 --------------------------------------------------------------------
