Manually configuring link-local = global unicast cannot use EUI 64??

[mmanthe]

Is this normal behavior? When I configure *just* a global unicast address on an interface using EUI 64 (and allow the link-local to be auto-configured), it works as I think it should (e.g. they both use EUI 64).

BUT - if I *manually* configure my link-local address while still configuring the global unicast address to use EUI 64, it (the global unicast address) does NOT use EUI 64. In fact, it appears to 'mirror' the link-local address's interface ID (see output from one of my lab routers below).

Is this normal? If so - why? Thanks in advance!

R1-2851(config-if)#do sho run int lo69
Building configuration...

Current configuration : 138 bytes
!
interface Loopback69
description telnet-ssh interface
ip address 9.9.9.1 255.255.255.255
ipv6 address 2001:ABCD:9:1::/64 eui-64
end

R1-2851(config-if)#do sho ipv6 int bri lo69
Loopback69 [up/up]
FE80::1EAA:7FF:FE3A:F300
2001:ABCD:9:1:1EAA:7FF:FE3A:F300
R1-2851(config-if)#
R1-2851(config-if)#
R1-2851(config-if)#ipv6 add fe80:abcd:9:1::1 link
R1-2851(config-if)#
R1-2851(config-if)#do sho run int lo69
Building configuration...

Current configuration : 180 bytes
!
interface Loopback69
description telnet-ssh interface
ip address 9.9.9.1 255.255.255.255
ipv6 address FE80:ABCD:9:1::1 link-local
ipv6 address 2001:ABCD:9:1::/64 eui-64
end
R1-2851(config-if)#do sho ipv6 int bri lo69
Loopback69 [up/up]
FE80:ABCD:9:1::1
2001:ABCD:9:1::1

[Peter Paluch · Accepted solution]

Hello,

Good observation!

In IOS, the assumption is that the link-local address is always constructed using Modified EUI-64 - and if it is configured manually, then it is assumed that the last 64 bits of the link-local address already contain the final Modified EUI-64 value. Therefore, if you later ask the router to configure its global prefix on the same interface using Modified EUI-64, it will reuse the lowmost 64 bits from the link-local address, treating their value as the Modified EUI-64 ID of the interface. This rule allows keeping the link-local and EUI-64-derived global addresses congruent as far their Interface ID part is concerned.

Remember: Ethernet-based interfaces do not have factory-assigned EUI-64 IDs, so the IOS has to derive a Modified EUI-64 value for each interface to use it for IPv6. If you do not touch the link-local address, the IOS will use the MAC address of the interface to generate a Modified EUI-64 ID. If you specify the link-local address yourself, then as a part of it, you also specify the Modified EUI-64, so the IOS no longer resorts to the MAC address of the interface to derive a Modified EUI-64 value; instead, it treats whatever value you entered into the lowmost 64 bits of the link-local address as the final Modified EUI-64 ID, and reuses it later for global prefixes if needed.

Feel welcome to ask further!

Best regards,
Peter

[mmanthe]

Peter

thanks so much for the explanation. I’d literally never come across that info anywhere before - but seeing your explanation - it makes a lot of sense and I can definitely see why it’s done that way. That’s getting filed under ‘very good to know!’

I assume then that the same holds true for Site Local as well?

thanks again!

-mike 

[Peter Paluch]

Hi Mike,

You are very much welcome!

Regarding site-local, well... formally, they do not exist anymore, they have been deprecated since 2004 in RFC 3879. But either way, to a router, there is no difference between a site-local and a global IPv6 address. If you configured a prefix of fec0:: (which used to be the site-local prefix) and asked the router to fill in the IID using EUI-64, it would do the same thing as with global addresses - it would reuse the IID from the link-local address, regardless where it came from (automatically generated or manually specified).

Best regards,
Peter