Subject: Re: [v6ops] IPv6 prefix notation (Nathan Ward)

From: Ray Hunter <[email-masked]>
Date: Tue, 20 Sep 2011 10:48:47 +0200

>
> 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?

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.

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]

regards,
RayH

---

From: Nathan Ward <[email-masked]>
Date: Tue, 20 Sep 2011 20:57:08 +1200

On 20/09/2011, at 8:48 PM, Ray Hunter wrote:

> Wait a minute. Have I really understood this statement "A reasonable prefix will end with at least 64 zeros" correctly?
> 
> 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.
> 
> 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]

That's funny, postgres has a column type that handles IPv4 and IPv6 in the same column. I use that :-)

My advice to people deploying IPv6 is that within your network, /112s or whatever are great for link-nets, between routers. Where there are any servers etc., use /64s. Where you don't own/control all the devices on the link (i.e. customer links), use /64s.

Not really sure how this thread got on to v6ops or how it got my name in the subject, did I push a wrong button somewhere?

--
Nathan Ward

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Sep 2011 10:22:40 +1200

Ray,

> 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.

> support non /64 prefixes in the future.

But SLAAC today doesn't do that, so it isn't a current operational issue.

> 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