Subject: [v6ops] Use of MAC addresses in IPv6 link local addresses

From: Toerless Eckert <[email-masked]>
Date: Fri, 7 Jul 2017 01:03:47 +0200

For a protocol design, we are wondering what the current state of the
art is wrt to IPv6 link local addresses potentially being the same
on multiple interfaces of a network device like a router.

I was told by Brian that RFC7217 is recommended, but recommendations are
one thing and reality can be another thing. If there are widely deployed
network devices that do have the same link local address across multiple
interfaces then it could take quite a while for this to get changed,
so it might be prudent for a protocol design NOT to expect that eg: RFC7217
is supported everywhere.

The one type of datapoint i seem to vaguely remember is that routers
with large number of "cheap" L3 interfaces often derive their MAC
utilization designs from L2 switches where you do not automatically
assign a separate MAC address to every port because thats a cost factor,
and instead there is just a limited number of MAC addresses assigned to
the box (i think i remember '8' from some cisco products) and
once those are exhausted, additional L3 interfaces repeat the MAC
addresses. And of course if the link-local addresses are derived from
interfaces MAC addresses then we have the problem in question.

Standard disclaimer:
Just because i am paranoid does not mean they are not after me.

So, would love to hear that duplicate link-local IPv6 addresses are
not to be found anywhere in deployed  IPv6 networks and that i am
just paranoid ;-) Or else we know that we should take this into
consideration.

Thanks
    Toerless

---

From: Mark Smith <[email-masked]>
Date: Fri, 7 Jul 2017 09:51:23 +1000

> so it might be prudent for a protocol design NOT to expect that eg: RFC7217

It would be prudent.

RFC4291bis explicitly says that the same IID can be used on a device's
different interfaces.

"The same
   interface identifier may be used on multiple interfaces on a single
   node, as long as they are attached to different subnets."

This might sound a little ambiguous because the LL prefix ("subnet")
is the same on all links, however I think "different subnets or
instances of the same subnet" would be accurate. The overriding
requirement is

"They are required to be unique within a subnet prefix."

An Internet search for "fe80::1" shows that this is also a common
value being used for router interfaces.

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Jul 2017 14:13:09 +1200

> value being used for router interfaces.

Which makes my head hurt, since it's a guaranteed failure if two
such routers are on the same subnet.

Thanks for reminding us of the "may" in RFC4291(bis). We'd be
foolish to ignore that.

Regards
   Brian

---

From: Mark Smith <[email-masked]>
Date: Fri, 7 Jul 2017 13:26:46 +1000

DAD should catch it and stop the latter one coming up. Alternatively poor
man's VRRP by having them as anycast addresses.

Regards
   Brian

---

From: Ross Chandler <[email-masked]>
Date: Fri, 7 Jul 2017 07:42:53 +0100

> On 7 Jul 2017, at 04:26, Mark Smith <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On 7 Jul. 2017 12:13, "Brian E Carpenter" <[email-masked] <mailto:[email-masked]>> wrote:
> 
> DAD should catch it and stop the latter one coming up. Alternatively poor man’s VRRP by having them as anycast addresses.

DAD protection on the well behaved router yes but it would be better if the router Ethernet interface used an address formed from using its MAC.
The misbehaving router might also have its DNS proxy responding with AAAA records for its webgui that point at the link-local instead of a GUA or horror a ULA.
I find that http://[fe80::1]/ <http://[fe80::1]/> currently works on Windows as that assumes to forward out the default interface.
Access to the same link-local URL using macOS doesn’t work as might be reasonably expected.

Anycast doesn’t apply as the two routers RAing fe80::1 share the same LAN.

Ross

---

From: Gert Doering <[email-masked]>
Date: Fri, 7 Jul 2017 10:42:32 +0200

Hi,

> so it might be prudent for a protocol design NOT to expect that eg: RFC7217

Checking one of our boxes, which was not exactly "cheap":

Cisco#sh ipv int | inc FE80
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
[..]
  IPv6 is enabled, link-local address is FE80::1 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
[..]
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 [UNA]
    FE80::5:73FF:FEA0:6 [OOD]
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 [UNA]
    FE80::5:73FF:FEA0:6 [OOD]

... so yes, it seems to use the same LLA on all L3 interfaces, unless
configured otherwise...  (UNA and OOD seem to appear "if HSRPv2 is
involved", but even then, the box picks the same LLA for all HSRPv2-
enabled interfaces if the HSRPv2 group is the same)

Checking on a much newer box with IOS XR and "router hardware", things
look different, but still not sufficiently uniqe:

RP/0/RSP0/CPU0:Cisco#sh ipv6 int | inc fe80
Fri Jul  7 10:39:55.203 MEDST
  IPv6 is enabled, link-local address is fe80::d80:22ff:fe39:18cf 
  IPv6 is enabled, link-local address is fe80::d80:22ff:fe39:18cf 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:5a00 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:5a01 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:5a02 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:5a02 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59e8 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59e9 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59e9 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59fe 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59fe 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59fe 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59fe 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59fe 
  IPv6 is enabled, link-local address is fe80::21a:6cff:fe9e:6529 

(this one is "there are dot1q subinterfaces involved, and all subifs
have the same LLA as the parent interface" - which is unsurprising,
when you think about it :-) - and I expect this part to be the same
across most vendors that assign MAC-address derived LLA addresses)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 7 Jul 2017 17:29:55 +0200

Thanks, Mark, Gert,...:

So in summary & followup Q:
- Address architecture says addresses MAY be the same (RFC4291bis)

- MAC based LL assignment is still common and leads to this

- Q: fe80::1 - i assume this is manual config ? Wasn't even aware 
  whether manual config of LL was possible in all/most routers.
  (but i can see how this may be attractive to operators whose
   habits have been formed by too many decades with IPv4).
  
- Also: Wrt RFC7217, 
  Whats the motivation for device vendors to implement this on
  network devices ? Would operators ask for this for their network
  devices ? MAC address could be considered randomn enough but the operators
  might have databases with them, so they could identify them.
  (not arguing about the obvious benefits for host addresses of rfc7217)

-- 
---
[email-masked]

---

From: Sander Steffann <[email-masked]>
Date: Fri, 7 Jul 2017 18:09:24 +0200

Hi,

>   habits have been formed by too many decades with IPv4).

Also: if you use things like fe80::<vlan-id> then looking at your default gateway from RA will immediately show you if you accidentally connected to the wrong VLAN :)

Cheers,
Sander

---

From: Gert Doering <[email-masked]>
Date: Fri, 7 Jul 2017 19:38:23 +0200

Hi,

>    habits have been formed by too many decades with IPv4).

All (real) routers I've seen so far can do it, and I wouldn't call
my habits "formed by too many decades with IPv4" :-)

It's more like "if you standardize on fe80::1, misconfiguration of the
default gateway address on the host side is a thing of the past" - and
no, we don't do RA/SLAAC, we do static v6 addresses, no privacy extention,
and static default routes.  With HSRP/VRRP for quick failover in case
one router goes down.

So, single-gateway setups have the router set to fe80::1, redundant-gateway
setups have the HSRP/VRRP address set to fe80::1

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Jul 2017 10:40:54 +1200

Gert,

Very interesting, but I have to ask a picky question to be sure 
I understand 100%.

For code running in the box *above* layer 3, are these really different
interfaces? In other words, are the complete addresses with zone IDs,
such as you would get from getsockname(), all different:
FE80::222:55FF:FE93:8480%eth0
FE80::222:55FF:FE93:8480%eth1  (or whatever Cisco uses as interface names)

Regards
   Brian

---

From: Sander Steffann <[email-masked]>
Date: Sat, 8 Jul 2017 01:10:16 +0200

Hi Brian,

> FE80::222:55FF:FE93:8480%eth1  (or whatever Cisco uses as interface names)

I have another example right here. With interface names:

TenGigabitEthernet1/6 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::7E0E:CEFF:FE02:AAC0
  ...
TenGigabitEthernet1/13 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::7E0E:CEFF:FE02:AAC0
  ...
Loopback0 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::7E0E:CEFF:FE02:AAC0
  ...
Port-channel1 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::7E0E:CEFF:FE02:AAC0
  ...
Port-channel2 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::7E0E:CEFF:FE02:AAC0
  ...
Port-channel5 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::7E0E:CEFF:FE02:AAC0
  ...
Port-channel6 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::7E0E:CEFF:FE02:AAC0
  ...

Loopback, TenGig, Port channels, all the same link-local address. Those are definitely separate interfaces connected to different devices having separate routes etc. All full layer-3 interfaces.

#ping FE80::7E0E:CEFF:FE02:AAC0%TenGigabitEthernet1/13
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::7E0E:CEFF:FE02:AAC0, timeout is 2 seconds:
Packet sent with a source address of FE80::7E0E:CEFF:FE02:AAC0%TenGigabitEthernet1/13
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Cheers!
Sander

---

From: Gert Doering <[email-masked]>
Date: Sat, 8 Jul 2017 21:34:38 +0200

Hi,

> FE80::222:55FF:FE93:8480%eth1  (or whatever Cisco uses as interface names)

Yes.  These are "vlan 3", "vlan 570", etc. - that's the routed interface
tied to a given VLAN in the switch fabric (Cisco used to call them "SVI"
or "BVI" - bridge virtual interface - no idea how anyone else calls them).

In other words, from a routing protocol point of view, like OSPFv3, 
these are all fully independent layer3 interfaces.  The fact that they
are tied to the switch fabric is not visible further up.

(The other example also involves VLANs, but as dot1q subinterfaces on
a router that is not really a switch inside - so that would be akin
to Linux' %eth0.3, %eth0.75, etc.)

Gert Doering
        -- NetMaster

---

From: Francis Dupont <[email-masked]>
Date: Sun, 09 Jul 2017 18:29:22 +0200

>  on multiple interfaces of a network device like a router.

=> in fact the IEEE spec were loose enough to have Sun to intepret them
as to give a MAC address per box instead of a MAC address per NIC
(i.e., device = box vs device = Network Interface Card).
So the problem is very far to be new and the answer is you can get
the same link-local address on different links. Of course this led
to some bugs but this was a long time ago so they were repaired
and ready to come back (:-)...

>  so it might be prudent for a protocol design NOT to expect that eg: RFC7217

=> the purpose of RFC 7217 was very different but of course if the MAC
address is not embedded into the link-local address this solves
any issue with multiple interfaces using the same MAC address...

>  Just because i am paranoid does not mean they are not after me.

=> no, the oppostunity of new bugs or old bugs to come back is too high
to not justify some kind of paranoia.

>  just paranoid ;-) Or else we know that we should take this into

=> in fact the first time someone reported a link-local IPv6
address collision it came from a blind copy of a router config.
Unfortunately the fact routers derived link-local addresses from
MAC addresses did not save in that particular case because they
were DEC routers with the standard DECnet setup (*).

Regards

[email-masked]

PS (*): (for young people) DECnet derived the MAC address from
the DECnet one (i.e. the exact opposite of (early?) IPv6).

---

From: Francis Dupont <[email-masked]>
Date: Sun, 09 Jul 2017 18:35:55 +0200

>  such routers are on the same subnet.

=> if you want to give the same address to all routers I recommend
the fe80:: address. At least it is very officially an anycast address!

Regards

PS: and of course it won't work as you expect (I tried a very long
time ago: a fine idea on and only on the paper :-).

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Jul 2017 10:10:09 +0300

> just paranoid ;-) Or else we know that we should take this into

Well, for legacy systems, you could have duplicate link-local addresses
for a umber of reasons:

* vendors re-using the same MAC address in different devices
* Products using the same MAC address on multiple interfaces (as you
describe)
* virtualization technolgies 8which, in many cases, obtain a randomized
MAC address at the time the VM was fist created).

RFC7217 reduces the likelihood of this happening...

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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Jul 2017 10:35:37 +0300

> such routers are on the same subnet.

+1