Wired Intelligent Edge

The objective of this post is to help understand and discuss AOS-CX IPv6 - Link Local Addresses.

There are multiple address types in IPv6, RIPE has a great table IPv6 Address Types that summarizes and explains the different types and scopes, e.g. Global Unicast Address/GUA (2000::/3), Link Local Address/LLA (fe80::/10), Unique Local Address/ULA (fc00::/7) and multicast address (ff00::/8).
Be aware that broadcast addresses are not used in IPv6, multicast is used instead.

The benefit of LLA is: Unlike IPv4, IPv6 hosts are able to communicate on the same network subnet or VLAN without a need for DHCP servers to assign IPs.
LLAs are not routable, they are mandatory and automatically generated upon IPv6 host boot up or when an IPv6 interface is enabled.
An interface on an IPv6 host can support multiple GUAs but only 1 LLA.

The topology shown above will be used to describe LLA usage and network connectivity across an AOS-CX switch.
I have used AOS-CX switches to simulate Host1 and Host2, both hosts are placed into VLAN 20.

Let's start with a static LLA on Switched Virtual Interface/SVI "int VLAN 20", this would function as the default gateway out of the subnet when GUA is used on hosts.
AOS-CX(config)# int vlan 20
AOS-CX(config-if-vlan)# ipv6 address link-local fe80::1/64

As LLA is locally significant, you could use the same fe80::1 as default gateway on all SVIs.

AOS-CX(config-if-vlan)# do sh ipv6 int vlan 20
Interface vlan20 is up
Admin state is up
IPv6 address:
IPv6 link-local address: fe80::1/64 [VALID]
IPv6 virtual address configured: none
IPv6 multicast routing: disable
IPv6 Forwarding feature: enabled
IPv6 multicast groups locally joined:
ff02::1 ff02::1:ff00:1 ff02::1:ff00:0 ff02::2

Notice the interface has joined the ff02::1:ff00:1 multicast group for it's fe80::1/64 LLA.
Since IPv6 does not utilize ARP broadcast for IP to MAC resolution, queries are sent via ICMPv6 Neighbor Solicitation/NS message to the ff02 "solicited-node multicast address" of the destination IP to listen and respond back.
This implies that every IPv6 unicast address has a "solicited-node multicast address" for IP to MAC resolution.
This RFC https://datatracker.ietf.org/doc/rfc4291/ explains how to calculate the "solicited-node multicast address".

Let's modify from static to dynamic LLA.
AOS-CX(config-if-vlan)# no ipv6 address link-local fe80::1/64
AOS-CX(config-if-vlan)# ipv6 address link-local

AOS-CX(config)# sh ipv6 int vlan 20
Interface vlan20 is up
Admin state is up
IPv6 address:
IPv6 link-local address: fe80::9020:c280:14ba:d800/64 [VALID]
IPv6 virtual address configured: none
IPv6 multicast routing: disable
IPv6 Forwarding feature: enabled
IPv6 multicast groups locally joined:
ff02::1 ff02::1:ffba:d800 ff02::1:ff00:0 ff02::2

You will notice LLA is now fe80::9020:c280:14ba:d800/64 and it has joined the ff02::1:ffba:d800 "solicited-node multicast address" to listen in.

If you are curious about the other multicast groups this SVI has joined and listening to, e.g. ff02::1, ff02::1:ff00:0, ff02::2, refer to
IPv6 Multicast Address Space Registry


Let's move onto hosts next.
Manual LLAs are assigned to the hosts to make it easier to understand packet capture output later.

Host1# sh run int 1/1/4
interface 1/1/4
no shutdown
ipv6 address link-local fe80::11/64

Host2# sh run int 1/1/4
interface 1/1/4
no shutdown
ipv6 address link-local fe80::12/64


As LLAs only need to be unique on a link/VLAN, the same LLA can be used on multiple interfaces on an IPv6 host.
That's the reason pings using LLA require interface scope to be added.
Host1# ping6 fe80::12
Ping failed. Please specify an interface scope to ping linklocal/multicast address.


We are now able to verify network connectivity between hosts on the same link/VLAN when interface scope is added.

Host1# ping6 fe80::12 source 1/1/4
ping6: Warning: source address might be selected on device other than: m1s1p4
PING fe80::12(fe80::12) from :: m1s1p4: 100 data bytes
108 bytes from fe80::12%m1s1p4: icmp_seq=1 ttl=64 time=21.5 ms
108 bytes from fe80::12%m1s1p4: icmp_seq=2 ttl=64 time=0.187 ms
108 bytes from fe80::12%m1s1p4: icmp_seq=3 ttl=64 time=0.183 ms
108 bytes from fe80::12%m1s1p4: icmp_seq=4 ttl=64 time=0.186 ms


Host1 now has IP to MAC binding in the IPv6 neighbor table, think of this as equivalent to IPv4 ARP table.

Host1# sh ipv6 neighbors

IPv6 Address MAC Port Physical Port State
--------------------------------------------------------------------------------------------------------------------
fe80::12 54:80:28:fe:29:00 1/1/4 1/1/4 reachable

Total Number Of IPv6 Neighbors Entries Listed: 1.
--------------------------------------------------------------------------------------------------------------------



Let's look at packet captures from the AOS-CX switch when pings were initiated.

Host1/fe80::11 sends NS message to ff02::1:ff00:12 for fe80::12 IP to MAC resolution.
This is unicast to solicited-node multicast address.
14:59:06.965866 IP6 fe80::11 > ff02::1:ff00:12: ICMP6, neighbor solicitation, who has fe80::12, length 32
14:59:06.965870 IP6 fe80::11 > ff02::1:ff00:12: ICMP6, neighbor solicitation, who has fe80::12, length 32

Host2 responds back with Neighbor Advertisement/NA message to Host1.
This is unicast to unicast.
14:59:06.981321 IP6 fe80::12 > fe80::11: ICMP6, neighbor advertisement, tgt is fe80::12, length 32

Pings between Host1 and Host2 are seen.
This is unicast to unicast.
14:59:06.985952 IP6 fe80::11 > fe80::12: ICMP6, echo request, id 8758, seq 1, length 108
14:59:06.986028 IP6 fe80::12 > fe80::11: ICMP6, echo reply, id 8758, seq 1, length 108
14:59:07.965450 IP6 fe80::11 > fe80::12: ICMP6, echo request, id 8758, seq 2, length 108
14:59:07.965535 IP6 fe80::12 > fe80::11: ICMP6, echo reply, id 8758, seq 2, length 108
14:59:08.989528 IP6 fe80::11 > fe80::12: ICMP6, echo request, id 8758, seq 3, length 108
14:59:08.989532 IP6 fe80::12 > fe80::11: ICMP6, echo reply, id 8758, seq 3, length 108
14:59:10.012452 IP6 fe80::11 > fe80::12: ICMP6, echo request, id 8758, seq 4, length 108
14:59:10.012537 IP6 fe80::12 > fe80::11: ICMP6, echo reply, id 8758, seq 4, length 108


From the AOS-CX switch perspective, it has learnt MAC addresses of both hosts with correct ports.

AOS-CX# sh mac-address-table
MAC age-time : 300 seconds
Number of MAC addresses : 2

MAC Address        VLAN         Type           Port
--------------------------------------------------------------
54:80:28:fe:f9:00    20              dynamic     1/1/49
54:80:28:fe:29:00   20              dynamic     1/1/50


As hosts did not generate traffic towards "int VLAN 20" of the switch, as expected, the IPv6 neighbor table was not populated.
AOS-CX# sh ipv6 neighbors
No IPv6 neighbors found.


Let's change a host from static to dynamic LLA.
Host1(config)# int 1/1/4
Host1(config-if)# no ipv6 address link-local fe80::11/64
Host1(config-if)# ipv6 address link-local

Host1(config-if)# do sh ipv6 int 1/1/4
Interface 1/1/4 is up
Admin state is up
IPv6 address:
IPv6 link-local address: fe80::5480:2801:10fe:f900/64 [VALID]
IPv6 virtual address configured: none
IPv6 multicast routing: disable
IPv6 Forwarding feature: enabled
IPv6 multicast groups locally joined:
ff02::1 ff02::1:ff00:0 ff02::1:fffe:f900 ff02::2


You might wonder how are duplicate IPs prevented on a subnet? The answer is Duplicate Address Detection/DAD.
DAD makes use of ICMPv6 NS and NA messages to prevent IPv6 hosts from using duplicate LLA or GUA on the same subnet.

We see that host1 sends out a NS to query if the dynamic LLA is in use.
This is unicast to solicited-node multicast address.
13:45:59.315375 IP6 :: > ff02::1:fffe:f900: ICMP6, neighbor solicitation, who has fe80::5480:2801:10fe:f900, length 32
13:45:59.315379 IP6 :: > ff02::1:fffe:f900: ICMP6, neighbor solicitation, who has fe80::5480:2801:10fe:f900, length 32

If there are no hosts with that IP in use, no response will be received.
If there is a duplicate address conflict, a NA response from other hosts will be sent, host1 will try another IPv6 address and repeat DAD.


If you have questions, let's discuss!

------------------------------
DWan
------------------------------