Subject: Re: IPv6 prefix notation

From: Ray Hunter <[email-masked]>
Date: Wed, 21 Sep 2011 10:58:26 +0200

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<[email-masked]>
>>> To: Randy Bush<[email-masked]>
>>> Cc: ipv6 deployment prevention<[email-masked]>
>>> Subject: Re: IPv6 prefix notation
>>> Message-ID:<[email-masked]>
>>> 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
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Sep 2011 09:34:50 +1200

Ray,

We agree.

Regards
   Brian Carpenter