Re: I-D Action: draft-linkova-6man-default-addr-selection-update-00.txt

[Brian E Carpenter <[e-mail]>]

On 08/04/2017 01:25, Erik Kline wrote:
> On 7 April 2017 at 22:21, Jen Linkova <[e-mail]> wrote:
> 
>> On Fri, Apr 7, 2017 at 3:11 PM, Erik Kline <[e-mail]> wrote:
>>>> I probably need to make the text a bit more clear but the use case
>>>> I've observed has nothing to do with SLAAC, so neither
>>>> RFC 7217 nor RFC8064 are applicable here. People do configure VRRP LLAs
>>>> manually
>>>> and it's understandable that they do not want to generate an unique
>>>> LLA for each interface (LLAs are supposed to be unique within a link,
>>>> right? so it's perfectly fine to have fe80::1 configured on each
>>>> interface).
>>>> It's operational reality, it does make sense (or we shall stop
>>>> pretending that  LLAs have link scope...;( ) so I believe it would be
>>>> nice to tweak the source address selection a bit to deal better with
>>>> the real life..;)
>>
>>> It is a sad, but seemingly true, state of affairs that all of this blows
>> up
>>> the core DNAv6 working assumption:
>>>
>>>     https://tools.ietf.org/html/rfc6059#section-1.5
>>>
>>>    o  The combination of the link-layer address and the link-local IPv6
>>>       address of a router is unique across links.
>>
>> Well, I'd expect that the combination of the L2 address AND LLA v6
>> address would still be unique (unless
>> people are explicitly configuring L2 addresses or MAC addresses are
>> not unique - both cases do happen but from my limited experience,
>> not so often as explicitly configured VRRP LLA Ipv6 addresses).
> 
> 
> If people are using the VRRP MAC space, then I don't see a lot of room for
> uniqueness:
> 
>     https://tools.ietf.org/html/rfc5798#section-7.3
> 

The problem is section 7.4. It should be updated to RECOMMEND RFC7217/8064.

That also answers Lorenzo's point:

> There's no way to do "highly unlikely" with only 256 VRRP groups.

But Jen is correct, we also have to consider reality with clashing
addresses.

Doesn't that mean that "when the host moves from one network segment
to another" we should suggest that the stack *deletes* all state
learned from that network interface? (And yes, that breaks RFC6059.)

    Brian

   Brian