Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]

[Fernando Gont <[e-mail]>]

On 01/16/2017 04:57 PM, Brian E Carpenter wrote:
> On 16/01/2017 22:36, Lorenzo Colitti wrote:
>> Brian,
>>
>> what's the specific rationale for this change? Is it a bug in 4291 which
>> you're proposing that we resolve in 4291 bis? If so, what is the bug?
> 
> The bug is that in SLAAC, the IID length is a parameter, not a constant,
> and that in routing protocols, the prefix length is a parameter, not
> a constant. The addressing architecture needs to recognise that.

+1



>> The "interface identifiers are 64 bits" long text in RFC 4291 goes back all
>> the way to 1998 and the text below would be a major change to text that has
>> likely been baked into implementations for almost two decades years. I
>> don't see why we would change that now.
> 
> Any SLAAC implementation that has 64 baked into it is already non-conformant.
> But I very much doubt if anyone will need to change their code as a result
> (except for any non-conformant routers such as you mentioned recently).

+1


>> In general, IPv6 addresses are
>> aggregatable on all bit lengths. But global unicast addresses (other than
>> ::/3) have a 64-bit IID, so links in that space are assigned 64-bit prefix
>> lengths. These two properties can coexist even in global unicast space. For
>> example, you could load-balance traffic to a given global unicast /64 by
>> announcing it to the backbone as two /65s. The "addresses are aggregatable
>> on all bit lengths" text means that the /65 are valid prefixes that can be
>> routed by routers.
> 
> Sure. And this text doesn't aim to change anything in any current (and
> non-broken) implememtations. It aims to respond to the objections that have
> been discussed on the IETF list recently.

Agreed.

(Thanks for proposing text, btw!)

-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492