The premiere source of truth powering network automation. Open and extensible, trusted by thousands.
NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.
IPv6 Link-Local Addresses
By stretch | Thursday, April 28, 2011 at 12:40 a.m. UTC
IPv6 link-local addresses are a special scope of address which can be used only within the context of a single layer two domain. Packets sourced from or destined to a link-local address are not forwarded out of the layer two domain by routers. These addresses are useful for establishing communication across a link in the absence of a globally routable prefix or for intentionally limiting the scope of traffic which should not be routed (for example, routing protocol advertisements).
Link-local addresses are defined in section 2.5.6 of RFC 4291 as having a ten-bit prefix of 0xfe80 followed by 54 zero bits and a 64-bit interface ID:
| 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+
Thus, link-local addresses are typically described as always starting with 0xfe80. However, section 5.3 of RFC 4862 elaborates on the process used to generate a link-local address:
The left-most 'prefix length' bits of the address are those of the link-local prefix.
The bits in the address to the right of the link-local prefix are set to all zeroes.
If the length of the interface identifier is N bits, the right-most N bits of the address are replaced by the interface identifier.
Technically speaking, any address within the prefix fe80::/10 is considered a link-local address; this includes addresses beginning with fe80:: through febf::. (This last address prefix bumps up next to the fec0::/10 range assigned to the deprecated site-local address scope.) In common practice though, link-local addresses will typically begin with 0xfe80.
On Cisco IOS, an IPv6 interface must be assigned at least a link-local address. A link-local address is automatically generated using EUI-64 when a global IPv6 address is assigned or when IPv6 is explicitly enabled on the interface:
R1(config)# interface f0/0
R1(config-if)# ipv6 address 2001:db8:0:12::1/64
R1(config-if)# interface f0/1
R1(config-if)# ipv6 enable
R1(config-if)# do show ipv6 interface brief
FastEthernet0/0 [up/up]
FE80::C001:37FF:FE6C:0
2001:DB8:0:12::1
FastEthernet0/1 [up/up]
FE80::C001:37FF:FE6C:1
Link-local addresses can alternatively be manually configured:
R1(config-if)# ipv6 address fe80::1 ?
link-local Use link-local address
R1(config-if)# ipv6 address fe80::1 link-local
R1(config-if)# do show ipv6 interface brief
FastEthernet0/0 [up/up]
FE80::C001:37FF:FE6C:0
2001:DB8:0:12::1
FastEthernet0/1 [up/up]
FE80::1
Notice that the link-local argument is only applicable when assigning an address within the link-local scope:
R1(config-if)# ipv6 address fe90::1 link-local R1(config-if)# ipv6 address febf::1 link-local R1(config-if)# ipv6 address 2001:db8:0:12::1 link-local % Invalid link-local address
Issuing the no form of the ipv6 address command will replace a manually configured link-local address with an automatically configured one.
Note that, due to the nature of link-local addresses, the fe80::/10 prefix does not appear in the routing table; it is considered available via all IPv6 interfaces.
R1# show ipv6 route
IPv6 Routing Table - 3 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static route, M - MIPv6
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
D - EIGRP, EX - EIGRP external
C 2001:DB8:0:12::/64 [0/0]
via ::, FastEthernet0/0
L 2001:DB8:0:12::1/128 [0/0]
via ::, FastEthernet0/0
L FF00::/8 [0/0]
via ::, Null0
As such, it is necessary to specify from which interface packets should be sourced when you ping a link-local address:
R1# ping FE80::C002:37FF:FE6C:0 Output Interface: f0/0 % Invalid interface. Use full interface name without spaces (e.g. Serial0/1) Output Interface: fastethernet0/0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to FE80::C002:37FF:FE6C:0, timeout is 2 seconds: Packet sent with a source address of FE80::C001:37FF:FE6C:0 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
Newer IOS versions also support specification of the outgoing interface using the % character, in the following form:
R1# ping FE80::C002:37FF:FE6C:0%fastethernet0/0
Posted in IPv6
Comments
April 28, 2011 at 2:07 a.m. UTC
Stretch, good write up. You should also talk about how HSRPv2 requires that the shared IP must be the link-local address and cannot be a global unicast address.
April 28, 2011 at 1:44 p.m. UTC
Also note that you have to completely spell out the interface name when pinging a link-local address, at least the last time I checked. Using a shortened form such as fa0/0 won't work.
April 28, 2011 at 2:18 p.m. UTC
In a IPv6 only environment can a WAN point-to-point link utilize only the link-local for network traffic to flow over? Assuming the routers on either end have at least one global IPv6 addresses assigned to them, perhaps on a loopback interface. Will this cause any issues with the MTU on the path?
May 3, 2011 at 11:03 p.m. UTC
Nice post Jeremy...
It clears most doubts about link-local which were not covered by CCNA Books.
July 21, 2011 at 1:26 a.m. UTC
Hi,
May you please comment why fe80 addresses are needed? I know that some routing protocols use these addresses (why?), and I thougth that they are specially needed in the neighbor discovery, but a quick test here (where I removed the fe80 address of my desktop interface) just showed that the neighbor discovery works fine with only global address.
So fe80 are just a convenience(?) but it seems to be mandatory (RFC4291?).
August 31, 2011 at 12:40 p.m. UTC
Hello Stretch, Can you give us some idea as to how two IPv6 hosts communicate in the same subnet and in differnet subnet.
I am unable to understand this in IPv6. In IPv4 it uses, network address and broadcast adress of the subnet.
July 20, 2013 at 5:53 a.m. UTC
Which protocol assigns IPv6 link local interface addresses?
February 27, 2014 at 4:19 p.m. UTC
Hi Anshu,Check out RFC 6724, section 5. This is what defines IPv6 "source address selection" process. Typically, when communicating with other LINK LOCAL addresses, an IPv6 interface will use its own LINK LOCAL address. And when communicating with an external address (different subnet), an IPv6 interface CAN NOT use its link local address, and therefore must use something else (typically a Global Unicast address)
https://tools.ietf.org/html/rfc6724
Hi Christian Lyra,
Link-Local addresses are mandatory for any IPv6 interface. Every (proper) implementation of IPv6 I've ran into would 'automagically' configure a link local address if I ever tried to remove a manually configured one (typically using EUI-64 or Privacy Extensions -- RFC 3041). So I'd be curious as to how you removed your interface's FE80 address, and whether or not your desktop re-established an FE80 address on its own.
NDP Does require link-local addresses. The answer to 'why' is a maybe a bit more complicated than a simple paragraph can provide, but I'll give it a shot using the example of "ARP" in IPv6:
NDP is responsible for L3 to L2 address mappings, but it doesn't use ARP as we know it in IPv4. Instead, it uses the Solicited Node Multicast (SNM) address of the intended L3 target to communicate with whomever truly owns a particular IPv6 address. The SNM address is multicast, and therefore requires the "Multicast Listener Discovery" (MLD) protocol to properly join the multicast group. Communication for MLD is done in the link-local scope, and therefore, a link-local address is required.
(this is just one use-case for link local, but honestly the use and requirement of link-local is simply built into the protocol itself. Must like IPv4 -requires- there to be a broadcast address on a network, IPv4 -requires- there to be a link-local address on an interface).
And lastly, Hi Stretch,
A point of clarity, you say a link-local address can only be used "...within the context of a single layer two domain". Shouldn't this be a Layer THREE domain? I've taken a L2 domain to mean a single collision network, and a L3 domain to span an entire broadcast network.
I only bring that up because I teach IPv6, and in my slides I initially had that Link-Local was only valid within a L2 domain. After a conversation with a student, I updated my slides to L3 domain, as I think that is more accurate to describe the scope of link-local.
What do you think?
May 4, 2014 at 12:49 a.m. UTC
I am confused as to the claim made that it would be possible to have FF80-FFBF as Link-Local prefixes. I understand your theory on the binary math, but follow me.
You refer to section 5.3 of the RFC to say it is technically possible, since the interface identifier can override the right-most N bits of the address that a link Local address could start with FF80, all the way to FFBF. I can see how you might arrive at your conclusion if your assertion assumes that the interface identifier is greater than 64 bits, eating its way out of the EUI-64 area. I think that is flawed due to lack of context. If you read 5.3, you can see that it makes this allowance assuming you're using proper RFC4291 prefix to begin with - this is stated just before the 3 rules you quoted. Also, just below those 3 rules, is the following: The length of the interface identifier is defined in a separate link-type-specific document, which should also be consistent with the address architecture [RFC4291] This tells me that the Interface identifier may not overrun into the 'network' 64 bits of the link local address
October 15, 2014 at 2:57 p.m. UTC
Hi West,
I think you are over thinking it. The simple truth is, IANA allocated FE80::/10 for Link Local addressing: http://www.iana.org/assignments/ipv6-unicast-address-assignments
The FE80::/10 range is anything from: FE80:0000:0000:0000:0000:0000:0000:0000 to: FEBF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
Anything in that range is considered a valid link-local address.
EUI-64, however, only 'generates' 64 bits of an interface identifier, so more than likely any EUI-64 generated address is just going to begin with FE80 (and never "eat in" to the additional bits to case a prefix of FE90, or whatnot). In fact, with all the IPv6 work I've done, I've never come across an implementation of IPv6 Link Local that didn't start with FE80. But, the entire range above is perfectly valid and acceptable.