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

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Apr 2017 10:18:31 +1200

As far as I can see this proposal makes sense and should work. But:

>    1.  The link-local address of the router in the new layer 2 domain
>        might be the same as the link-local address of the "old" router
>        (it's quite common to have link-local address on routers to be
>        explicitly configured, especially in VRRP-enabled environments)

Wow. Shouldn't there also be an operational recommendation to configure
non-clashing or at least highly-unlikely-to-clash addresses for
such routers?

   Brian

---

From: Mark Smith <[email-masked]>
Date: Wed, 5 Apr 2017 12:35:48 +1000

> non-clashing or at least highly-unlikely-to-clash addresses for

I think RFC8064, "Recommendation on Stable IPv6 Interface Identifiers"
is indirectly making that recommendation.

One of the use cases of RFC7217 is for router interface's Link-Local
addresses, and to not use use the interface's MAC address as the
Net_Iface value (e.g., module/slot number, ifindex instead), so that
the router's Link-Local IID is both unique and doesn't change if the
physical interface module is replaced, which usually means an
interface MAC address change too.

Regards,
Mark.

---

From: Jen Linkova <[email-masked]>
Date: Fri, 7 Apr 2017 14:54:10 +0200

On Wed, Apr 5, 2017 at 12:18 AM, Brian E Carpenter
<[email-masked]> wrote:
> As far as I can see this proposal makes sense and should work.

Thanks a lot for reviewing!

>But:

Well, maybe we should write smth about it. However link-local
addresses are meaningful and should be unique *on link*.
I can not see how/why we shall require them to be unique among all
interfaces on two (or more) routers.
I do see people configure fe80::1 as a vrrp link-local-address and I'm
afraid that even we try to convince the whole world that
it's not a good idea, we might not achieve 100% success ;)

-- 
SY, Jen Linkova aka Furry

---

From: Jen Linkova <[email-masked]>
Date: Fri, 7 Apr 2017 15:04:11 +0200

> interface MAC address change too.

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
(see http://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/virtual-link-local-address-edit-interfaces.html
and http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-2/addr_serv/configuration/guide/b_ipaddr_cg42crs/b_ipaddr_cg42crs_chapter_01010.html#task_96270599CAEE43DDB370F262D8C0722A
for two random examples)

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

---

From: Erik Kline <[email-masked]>
Date: Fri, 7 Apr 2017 22:11:40 +0900

On 7 April 2017 at 22:04, Jen Linkova <[email-masked]> wrote:

> (see http://www.juniper.net/documentation/en_US/junos/topics/reference/
> configuration-statement/virtual-link-local-address-edit-interfaces.html
> and http://www.cisco.com/c/en/us/td/docs/routers/crs/software/
> crs_r4-2/addr_serv/configuration/guide/b_ipaddr_cg42crs/b_ipaddr_cg42crs_
> chapter_01010.html#task_96270599CAEE43DDB370F262D8C0722A
> for two random examples)
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

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.

---

From: Jen Linkova <[email-masked]>
Date: Fri, 7 Apr 2017 15:21:01 +0200

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

---

From: Erik Kline <[email-masked]>
Date: Fri, 7 Apr 2017 22:25:13 +0900

> 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

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Apr 2017 22:32:48 +0900

On 5 Apr 2017 07:18, "Brian E Carpenter" <[email-masked]>
wrote:

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

---

From: Jen Linkova <[email-masked]>
Date: Fri, 7 Apr 2017 16:02:29 +0200

>     https://tools.ietf.org/html/rfc5798#section-7.3

oops, I stand corrected.
You are right indeed, the MAC will be the same (assuming VRID is not
changing between the interfaces, which is most likely to be the case).

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Apr 2017 02:05:44 +1200

>     https://tools.ietf.org/html/rfc5798#section-7.3

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

> 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

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Apr 2017 23:39:22 +0900

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

How do you configure RFC7217 such that the two VRRP routers in a given pair
have the same link-local address, but other routers don't?

---

From: Jen Linkova <[email-masked]>
Date: Fri, 7 Apr 2017 16:45:42 +0200

> learned from that network interface? (And yes, that breaks RFC6059.)

Well...I do not know the right answer...In some scenarios it does make
sense (for example I'd prefer my laptop and my desktop
to do that), while for mobile devices it might not be the best way to
operate (why DNA was created in the first place?).
Maybe DNA assumptions need to be changed to 'the combination of the
link-layer address, the link-local IPv6 address and the list of PIOs
is unique across links'?

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Apr 2017 02:59:42 +1200

> have the same link-local address, but other routers don't?

I'm totally ignorant about how VRRP setups are created, so I can't answer
that.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Apr 2017 03:01:35 +1200

> link-layer address, the link-local IPv6 address and the list of PIOs

Or maybe DNA implementations need to embody a heuristic approach,
not a fixed rule.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 8 Apr 2017 00:12:06 +0900

> I'm totally ignorant about how VRRP setups are created, so I can't answer

This problem isn't really specific to VRRP, it's specific to 7217. The
determinism in 7217 is obtained by running a hash function over a set of
configuration variable. To use it for this purpose you have to ensure that
all the configuration variables are the same for a given pair.

If you want different VRRP groups to have different 7217 addresses then you
need additional entropy. The VRRP group is still only 8 bits long, and the
list of parameters in 7217 doesn't leave much room to maneuver...

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 9 Apr 2017 01:34:30 +1200

> list of parameters in 7217 doesn't leave much room to maneuver...

I see. So maybe a different approach is needed. The objective is not
privacy for VRRP routers, after all; it's non-clashing LL addresses.

    Brian