Re: router behaviour with prefixes longer than /64

[Ray Hunter <[e-mail]>]

> Erik Nordmark <mailto:[e-mail]>
> 19 March 2014 00:22
> On 3/16/14 5:05 AM, Ray Hunter wrote:
>>> Erik Nordmark <mailto:[e-mail]>
>>> 14 March 2014 17:27
>>>
>>> Ray,
>>> what do you see as missing?
>>>
>>> RFC 4861 allows for PIO with L=1 for any prefix length.
>>> Thus the on-link determination is orthogonal to whether DHCPv6 or 
>>> SLAAC is used for address assignment.
>>>
>>> Thanks,
>>>    Erik
>> There are those who would like to be able to ensure proper DHCP 
>> operation without RA. e.g. 
>> http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00
> Ray,
> I can understand such a desire, but I was confused by your comment 
> about "fixed with an extension to PIO for SLAAC"; if you don't have 
> RAs you wouldn't have PIOs.
>
Well it isn't at all clear to me how to treat a prefix length in SLAAC 
PIO in all cases if all unicast prefixes except those starting with 
binary 000 really are /64.

If the address architecture [4291] takes precedence then there's no need 
at all for this prefix length information in ND PIO in the vast majority 
of cases.
On link determination isn't applicable to the special function ranges 
defined so far that start with binary 000, and routing is completely 
different as well, with the vast majority never appearing on the wire.

But on link detection [5942] contradicts assuming a /64 boundary, 
stating nodes must not assume that addresses contain structure.

What do you do if you receive an RA PIO with L=1 A=1 but prefix length /80?

I presume you cannot use SLAAC [4862] to generate a GUA from modified 
EUI64 with prefix length !=64, but SLAAC could work perfectly well 
without adaptions with other non EUI64 addresses as the source of global 
uniqueness e.g. EUI48 for /80 prefixes, and it wouldn't break AFAICS. 
But at the same time this is an architecture violation for the structure 
of GUA addresses, so should you install the /80 prefix in the prefix 
table used for on-link determination if PIO had a length of /80?

ND [4861] states very clearly in 4.6.2 that the prefix length can take 
values from the set [0 .. 128], and certainly not [0 .. 64 , 127] or [64].

On link determination [5942] which amends [4861] implies very clearly in 
Section 5 that NBMA may use some prefix length other than 64, and nodes 
must not assume any structure from assigned addresses (including a fixed 
/64 boundary).

If there are conflicting standards track RFC's, which one takes precedence?

I think it would be useful in the why-64 draft to have a simple table of 
all IPv6 standards track documents, with a tag "breaks when prefix 
length !=64", "continues working nominally with prefix length !=64", 
"not sufficiently specified as a stand alone document to determine if 
all implementations will break or fail with prefix length !=64", "not 
self consistent"

It seems to me that in most cases I've seen, the addressing architecture 
is the outlier that specifies fixed /64 prefix lengths. Plus a few 
oddball ways of generating addresses stand-alone.

I think it would be useful for implementers if that view were either 
confirmed or blown out of the water.

All IPv6 code I've every written can handle prefix length [0..128].


>>
>> But it ain't going to happen.
>>
> Agreed.
>
>    Erik
>
>
>
> ------------------------------------------------------------------------


-- 
Regards,
RayH