IPv6 autoconfiguration

IPv6 Address Autoconfiguration and Stateless DHCPv6

 

We always hear much excitement regarding the stateless address autoconfiguration capability in IPv6, but we never seem to get to see it in action. And also, we realize that one router can provide another with the address information it needs, but what about things like DNS server information? In this demonstration I will show how the stateless autoconfiguration can be setup, as well as a nifty stateless DHCPv6 implementation that can assist with the other configuration information.

For this demonstration, I just fired up two routers in Dynamips (R1 and R2) and connected them via their respective Fa0/0 interfaces. R1 will be our “server” and R2 will be our dependent little “client”. Let us start at the server and ensure it is configured for the IPv6 stateless address autoconfiguration part.

R1# conf t
R1(config)# ipv6 unicast-routing
R1(config)# int fa0/0
R1(config-if)# no shut
R1(config-if)# ipv6 address 2001:1212::/64 eui-64
R1(config-if)# ipv6 nd prefix 2001:1212::/64
R1(config-if)# no ipv6 nd suppress-ra

Simple stuff – notice that we are leveraging the Neighbor Discovery process of IPv6 in order to provide the prefix for autoconfiguration to the link. Notice also how we have to unsuppress the sending of Router Advertisements on the link.
Now we head over to the client device:

R2# conf t
R2(config)# int fa0/0
R2(config-if)# no shut
R2(config-if)# ipv6 address autoconfig
R2(config-if)# do show ipv6 int fa0/0
FastEthernet0/0 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::C001:7FF:FEDA:0
  Global unicast address(es):
    2001:1212::C001:7FF:FEDA:0, subnet is 2001:1212::/64 [PRE]
      valid lifetime 2591911 preferred lifetime 604711
  Joined group address(es):
    FF02::1
    FF02::2
    FF02::1:FFDA:0
  MTU is 1500 bytes
  ICMP error messages limited to one every 100 milliseconds
  ICMP redirects are enabled
  ND DAD is enabled, number of DAD attempts: 1
  ND reachable time is 30000 milliseconds
  Default router is FE80::C000:7FF:FEDA:0 on FastEthernet0/0

How about that! One command – ipv6 address autoconfig – and the client autoconfigures its link-local and global unicast addresses. But now we want to have R1 provide R2 with its DNS server address and domain name. To do this, we will configure stateless DHCPv6.

R1# conf t
R1(config)# ipv6 dhcp pool DHCP_POOL
R1(config-dhcp)# dns-server 2001:1212::100
R1(config-dhcp)# domain-name test.com
R1(config-dhcp)# int fa0/0
R1(config-if)# ipv6 dhcp server DHCP_POOL
R1(config-if)# ipv6 nd other-config-flag

Notice the key ND command here instructing that autoconfiguration process that there is additional configuration to obtain. What is there to do on the client device? Nothing! That is the whole point.  Let’s verify this actually worked at the client, however:

R2# show ipv6 dhcp int fa0/0
FastEthernet0/0 is in client mode
  State is IDLE
  List of known servers:
    Reachable via address: 2001:1212::C000:7FF:FEDA:0
    DUID: 00030001C20007DA0000
    Preference: 0
    Configuration parameters:
      DNS server: 2001:1212::100
      Domain name: test.com
  Rapid-Commit: disabled

I hope you enjoyed this.

Note: there are codes that  does not support “no ipv6 nd suppress-ra” even without this command things worked just fine.  Debug on client side showed RA advertisements and RA requests from Server were being sent.
Also its quite interesting to note that “ipv6 nd prefix xxxx” command can help us to force client side to accept ipv6 address xxxx (provided by ipv6 nd prefix xxxx) along with server side interface address. Now client will have two IPv6 address, auto configured.

The “ipv6 nd other-config-flag” command on the server side of the configuration sets a flag in the Router Advertisements (RAs) sent from the router. This flag setting instructs the clients how they can obtain the non-IPv6 address information they need. In our example, this was the DNS Server address and Domain Name. What is a bit confusing about this is the fact that the flag that is being set is the “other stateful configuration” flag per the documentation. We realize, of course, that the way we implemented things here, it is really all stateless. The IPv6 address information is going to the client stateless via autoconfiguration, and the DNS information is going stateless via a stateless DHCPv6 implementation.

EUI-64 in IPv6

Guidelines for EUI-64 Registration Authority, this is a reserved value which equipment manufacturers cannot include in "real" EUI-64 address assignments. In other words, any EUI-64 address having 0xFFFE immediately following its OUI portion can be recognized as having been generated from an EUI-48 (or MAC) address.

RFC 2373 dictates the conversion process, which can be described as having two steps. The first step is to convert the 48-bit MAC address to a 64-bit value. To do this, we break the MAC address into its two 24-bit halves: the Organizationally Unique Identifier (OUI) and the NIC specific part. The 16-bit hex value 0xFFFE is then inserted between these two halves to form a 64-bit address.

Why 0xFFFE? As explained in the IEEE's Guidelines for EUI-64 Registration Authority, this is a reserved value which equipment manufacturers cannot include in "real" EUI-64 address assignments. In other words, any EUI-64 address having 0xFFFE immediately following its OUI portion can be recognized as having been generated from an EUI-48 (or MAC) address.


The second step is to invert the universal/local (U/L) flag (bit 7) in the OUI portion of the address. Globally unique addresses assigned by the IEEE originally have this bit set to zero, indicating global uniqueness. Likewise, locally created addresses, such as those used for virtual interfaces or a MAC address manually configured by an administrator, will have this bit set to one. The U/L bit is inverted when using an EUI-64 address as an IPv6 interface ID.

Again, you're probably wondering why this is done. The answer lies buried in section 2.5.1 of RFC 2373: but note --->> https://tools.ietf.org/html/rfc2373 obsolete by rfc3513 So please check -- https://tools.ietf.org/html/rfc3513

The motivation for inverting the "u" bit when forming the interface identifier is to make it easy for system administrators to hand configure local scope identifiers when hardware tokens are not available. This is expected to be case for serial links, tunnel end-points, etc. The alternative would have been for these to be of the form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler ::1, ::2, etc.

The important part to remember here is that the scope of the address never changes: global addresses are still global and local addresses are still local. Rather, the meaning of the bit is inverted for convenience, so the value of the bit must be inverted as well.
We can see this conversion in action when we assign an IPv6 address to a router interface. First, take note of the interface's MAC address (this is typically the same as its burned-in address, or BIA).

Router# show interface f0/0
FastEthernet0/0 is up, line protocol is down
  Hardware is Gt96k FE, address is 0012.7feb.6b40 (bia 0012.7feb.6b40)
...

After assigning an EUI-64-designated IPv6 address to the interface, we can verify that the interface ID has been drawn from the MAC address in the process described for both the assigned and the link local address:

Router(config)# interface f0/0
Router(config-if)# ipv6 address 2001:db8::/64 eui-64
Router(config-if)# do show ipv6 interface f0/0
FastEthernet0/0 is up, line protocol is down
  IPv6 is enabled, link-local address is FE80::212:7FFF:FEEB:6B40 [TEN]
  No Virtual link-local address(es):
  Global unicast address(es):
2001:DB8::212:7FFF:FEEB:6B40, subnet is 2001:DB8::/64 [EUI/TEN]
...

IPv6 Unique Local Addressing RFC4193

  IPv6 Unique Local Addressing

https://tools.ietf.org/html/rfc4193

A unique local address (ULA) is an IPv6 address in the block fc00::/7, defined in RFC 4193. It is the approximate IPv6 counterpart of the IPv4 private address. Unique local addresses are available for use in private networks, e.g. inside a single site or organization or spanning a limited number of sites or organizations. They are not routable in the global IPv6 Internet.

The address block fc00::/7 is divided into two /8 groups:

• The block fc00::/8 has not been defined yet. It has been proposed to be managed by an allocation authority, but this has not gained acceptance in the IETF.^[1][2][3] This block is also used by the cjdns mesh network.
• The block fd00::/8 is defined for /48 prefixes, formed by setting the 40 least-significant bits of the prefix to a randomly generated bit string. This results in the format fdxx:xxxx:xxxx:: for a prefix in this range. RFC 4193 offers a suggestion for generating the random identifier to obtain a minimum-quality result if the user does not have access to a good source of random numbers.

-==

Format


   The Local IPv6 addresses are created using a pseudo-randomly
   allocated global ID.  They have the following format:

      | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
      +--------+-+------------+-----------+----------------------------+
      | Prefix |L| Global ID  | Subnet ID |        Interface ID        |
      +--------+-+------------+-----------+----------------------------+

   Where:

      Prefix            FC00::/7 prefix to identify Local IPv6 unicast
                        addresses.

      L                 Set to 1 if the prefix is locally assigned.
                        Set to 0 may be defined in the future.  See
                        Section 3.2 for additional information.

      Global ID         40-bit global identifier used to create a
                        globally unique prefix.  See Section 3.2 for
                        additional information.

      Subnet ID         16-bit Subnet ID is an identifier of a subnet
                        within the site.

      Interface ID      64-bit Interface ID as defined in [ADDARCH].

Example

As an example, a routing prefix in the fd00::/8 range would be constructed by generating a random 40-bit hexadecimal string, taken to be e48dba82e1 in this example. This 40-bit string is appended to the fd00::/8 prefix. This forms the 48-bit routing prefix fde4:8dba:82e1::/48. With this prefix, 65536 subnets of size /64 are available for the private network: fde4:8dba:82e1::/64 to fde4:8dba:82e1:ffff::/64.

Properties

Prefixes in the fd00::/8 range have similar properties as those of the IPv4 private address ranges:

• They are not allocated by an address registry and may be used in networks by anyone without outside involvement.
• They are not guaranteed to be globally unique.
• Reverse Domain Name System (DNS) entries (under ip6.arpa) for fd00::/8 ULAs cannot be delegated in the global DNS.

As fd00::/8 ULAs are not meant to be routed outside their administrative domain (site or organization), administrators of interconnecting networks normally do not need to worry about the uniqueness of ULA prefixes. However, if networks require routing ULAs between each other in the event of a merger, for example, the risk of address collision is extremely small if the RFC 4193 selection algorithm was used.

More information: https://tools.ietf.org/html/rfc4193

IPv6 Global unicast address

IPv6 Aggregatable global unicast address 

RFC 3587 https://tools.ietf.org/rfcmarkup/3587

An aggregatable global address is an IPv6 address from the aggregatable global unicast prefix. The structure of aggregatable global unicast addresses enables strict aggregation of routing prefixes that limits the number of routing table entries in the global routing table. Aggregatable global addresses are used on links that are aggregated upward through organizations, and eventually to the Internet service providers (ISPs).

Aggregatable global IPv6 addresses are defined by a global routing prefix, a subnet ID, and an interface ID. Except for addresses that start with binary 000, all global unicast addresses have a 64-bit interface ID. The IPv6 global unicast address allocation uses the range of addresses that start with binary value 001 (2000::/3). The figure below shows the structure of an aggregatable global address.

Figure 1

Aggregatable Global Address Format

Addresses with a prefix of 2000::/3 (001) through E000::/3 (111) are required to have 64-bit interface identifiers in the extended universal identifier (EUI)-64 format. The Internet Assigned Numbers Authority (IANA) allocates the IPv6 address space in the range of 2000::/16 to regional registries.

The aggregatable global address typically consists of a 48-bit global routing prefix and a 16-bit subnet ID or Site-Level Aggregator (SLA). In the IPv6 aggregatable global unicast address format document (RFC 2374), the global routing prefix included two other hierarchically structured fields named Top-Level Aggregator (TLA) and Next-Level Aggregator (NLA). The IETF decided to remove the TLS and NLA fields from the RFCs because these fields are policy-based. Some existing IPv6 networks deployed before the change might still be using networks based on the older architecture.

A 16-bit subnet field called the subnet ID could be used by individual organizations to create their own local addressing hierarchy and to identify subnets. A subnet ID is similar to a subnet in IPv4, except that an organization with an IPv6 subnet ID can support up to 65,535 individual subnets.

An interface ID is used to identify interfaces on a link. The interface ID must be unique to the link. It may also be unique over a broader scope. In many cases, an interface ID will be the same as or based on the link-layer address of an interface. Interface IDs used in aggregatable global unicast and other IPv6 address types must be 64 bits long and constructed in the modified EUI-64 format.

Interface IDs are constructed in the modified EUI-64 format in one of the following ways:

•  For all IEEE 802 interface types (for example, Ethernet, and FDDI interfaces), the first three octets (24 bits) are taken from the Organizationally Unique Identifier (OUI) of the 48-bit link-layer address (the Media Access Control [MAC] address) of the interface, the fourth and fifth octets (16 bits) are a fixed hexadecimal value of FFFE, and the last three octets (24 bits) are taken from the last three octets of the MAC address. The construction of the interface ID is completed by setting the Universal/Local (U/L) bit--the seventh bit of the first octet--to a value of 0 or 1. A value of 0 indicates a locally administered identifier; a value of 1 indicates a globally unique IPv6 interface identifier.
•  For other interface types (for example, serial, loopback, ATM, Frame Relay, and tunnel interface types--except tunnel interfaces used with IPv6 overlay tunnels), the interface ID is constructed in the same way as the interface ID for IEEE 802 interface types; however, the first MAC address from the pool of MAC addresses in the router is used to construct the identifier (because the interface does not have a MAC address).
•  For tunnel interface types that are used with IPv6 overlay tunnels, the interface ID is the IPv4 address assigned to the tunnel interface with all zeros in the high-order 32 bits of the identifier.

Note

For interfaces using Point-to-Point Protocol (PPP), given that the interfaces at both ends of the connection might have the same MAC address, the interface identifiers used at both ends of the connection are negotiated (picked randomly and, if necessary, reconstructed) until both identifiers are unique. The first MAC address in the router is used to construct the identifier for interfaces using PPP.

If no IEEE 802 interface types are in the router, link-local IPv6 addresses are generated on the interfaces in the router in the following sequence:

1.      The router is queried for MAC addresses (from the pool of MAC addresses in the router).

2.      If no MAC addresses are available in the router, the serial number of the router is used to form the link-local addresses.

3.      If the serial number of the router cannot be used to form the link-local addresses, the router uses a message digest algorithm 5 (MD5) hash to determine the MAC address of the router from the hostname of the router.

Understanding IPv6 Link local address

IPv6 Link local address 

The purpose of this document is to provide an understanding of IPv6 Link-local address in a network. 

A link-local address is an IPv6 unicast address that can be automatically configured on any interface using the link-local prefix FE80::/10 (1111 1110 10) and the interface identifier in the modified EUI-64 format. Link-local addresses are not necessarily bound to the MAC address (configured in a EUI-64 format). Link-local addresses can also be manually configured in the FE80::/10 format using the ipv6 address link-local command.

These addresses refer only to a particular physical link and are used for addressing on a single link for purposes such as automatic address configuration and neighbor discovery protocol. Link-local addresses can be used to reach the neighboring nodes attached to the same link. The nodes do not need a globally unique address to communicate. Routers will not forward datagram using link-local addresses. IPv6 routers must not forward packets that have link-local source or destination addresses to other links. All IPv6 enabled interfaces have a link-local unicast address.

So, In a computer network, a link-local address is a network address that is valid only for communications within the network segment (link) or the broadcast domain that the host is connected to.

Link-local addresses are usually not guaranteed to be unique beyond a single network segment. Routers therefore do not forward packets with link-local addresses.

For protocols that have only link-local addresses, such as Ethernet, hardware addresses that the manufacturer delivers in network circuits are unique, consisting of a vendor identification and a serial identifier.

Link-local addresses for IPv4 are defined in the address block 169.254.0.0/16, in CIDR notation. In IPv6, they are assigned with the FE80::/64 prefix. ^[1]

Video https://supportforums.cisco.com/video/11930026/understanding-ipv6-link-local-address 

In this example, the routers R1, R2 and R3 are connected via serial interface and have the IPv6 addresses configured as mentioned in the network diagram. Loopback addresses are configured on the routers R1 and R3, and the routers use OSPFv3 to communicate with each other. This example uses the ping command to demonstrate the connectivity between the routers using link-local addresses. The routers R1 and R3 can ping each other with the IPv6 global unicast address, but not with their link-local address. However, router R2 being directly connected to R1 and R3 can communicate with both the routers using their link-local address, because link-local addresses are used only within that local network specific to the physical interface.

t.

Network Diagram

Router R1

! hostname R1 ! ipv6 cef ! ipv6 unicast-routing ! interface Loopback10  no ip address  ipv6 address 2010::/64 eui-64 !--- Assigned a IPv6 unicast address in EUI-64 format.   ipv6 ospf 1 area 1 !--- Enables OSPFv3 on the interface and associates  the interface looback10 to area 1. ! interface Loopback20  no ip address  ipv6 address 2020::/64 eui-64  ipv6 ospf 1 area 2 !--- Associates the Interface loopback20 to area 2. ! interface Serial0/0  no ip address  ipv6 address 2001::1/124  ipv6 ospf 1 area 0 !--- Associates the Interface serial0/0 to area 0.  clock rate 2000000 ! ipv6 router ospf 1  router-id 1.1.1.1 !--- Router R1 uses 1.1.1.1 as router id.  log-adjacency-changes ! end

Router R2

Router R3

hostname R2 ! ipv6 cef ! ! ! ! ipv6 unicast-routing ! ! ! interface Serial0/0  no ip address  ipv6 address 2001::2/124  ipv6 ospf 1 area 0  clock rate 2000000 ! ! interface Serial0/1  no ip address  ipv6 address 2002::1/124  ipv6 ospf 1 area 0  clock rate 2000000 ! ! ! ipv6 router ospf 1 router-id 2.2.2.2 log-adjacency-changes ! end

! hostname R3 ! ipv6 cef ! ipv6 unicast-routing ! interface Loopback10  no ip address  ipv6 address 1010::/64 eui-64  ipv6 ospf 1 area 1 ! interface Loopback20  no ip address  ipv6 address 2020::/64 eui-64  ipv6 ospf 1 area 2 ! interface Serial0/0  no ip address  ipv6 address FE80::AB8 link-local  ipv6 address 2002::2/124  ipv6 ospf 1 area 0  clock rate 2000000 ! ipv6 router ospf 1  router-id 3.3.3.3  log-adjacency-changes ! end

Verifying OSPF Configuration

In order to verify the OSPF has been configured properly, use the show ipv6 route ospf command in routers R1 and R3.

show ipv6 route ospf

Router R1 R1#show ipv6 route ospf IPv6 Routing Table - 10 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 OI  1010::C002:1DFF:FEE0:0/128 [110/128]      via FE80::C001:1DFF:FEE0:0, Serial0/0 O   2002::/124 [110/128]      via FE80::C001:1DFF:FEE0:0, Serial0/0 OI  2020::C002:1DFF:FEE0:0/128 [110/128]      via FE80::C001:1DFF:FEE0:0, Serial0/0 Router R3 R3#show ipv6 route ospf IPv6 Routing Table - 10 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 O   2001::/124 [110/128]      via FE80::C001:1DFF:FEE0:0, Serial0/0 OI  2010::C000:1DFF:FEE0:0/128 [110/128]      via FE80::C001:1DFF:FEE0:0, Serial0/0 OI  2020::C000:1DFF:FEE0:0/128 [110/128]      via FE80::C001:1DFF:FEE0:0, Serial0/0

Verifying Link-Local Address Reachability

The routers can ping each other with the global unicast address. However, when using link-local address only the directly connected networks can communicate. For example, R1 can ping R3 using global unicast address but the two routers cannot communicate using link-local addresses. This is shown using the ping and debug ipv6 icmp commands in router R1 and R3. This section provides scenarios to develop a better understanding about link-local addresses.

Pinging Link-Local Address from Remote Network

When the router R1 tries to communicate with router R3 using the link local address, the router R1 returns with an ICMP time-out message indicating that the link-local address is locally specific and cannot communicate to link-local addresses that are outside the directly connected network.

Pinging R3's Link-Local Address from router R1

In Router R1 R1#ping FE80::AB8   !--- Pinging Link-Local Address of router R3.   Output Interface: serial0/0   !--- To ping LLA, output interface must be entered.   Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to FE80::AB8, timeout is 2 seconds: Packet sent with a source address of FE80::C000:1DFF:FEE0:0 ..... Success rate is 0 percent (0/5)   !--- The ping is unsuccessful and the ICMP packet cannot reach the destination through serial0/0. This timeout indicates that R1 has not received any replies from the router R3.

Pinging Link-Local Address From Directly Connected Network

For router R2, the routers R1 and R3 are directly connected and can ping the link-local address of both router R1 and R2 by mentioning the corresponding interface that is connected to the router. The output is shown here:

Pinging R1 Link-Local Addresses from router R2

In Router R2 R2#ping FE80::C000:1DFF:FEE0:0 !--- Pinging Link-Local Address of router R1. Output Interface: serial0/0 !--- Note that, to ping LLA, output interface should be mentioned In our case, R2 connects to R1 via serial0/0. Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to FE80::C000:1DFF:FEE0:0, timeout is 2 seconds: Packet sent with a source address of FE80::C001:1DFF:FEE0:0 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 0/19/56 ms Debug output from R1 R1# *Mar  1 03:59:53.367: ICMPv6: Received echo request from FE80::C001:1DFF:FEE0:0 *Mar  1 03:59:53.371: ICMPv6: Sending echo reply to FE80::C001:1DFF:FEE0:0 *Mar  1 03:59:53.423: ICMPv6: Received echo request from FE80::C001:1DFF:FEE0:0 *Mar  1 03:59:53.427: ICMPv6: Sending echo reply to FE80::C001:1DFF:FEE0:0 *Mar  1 03:59:53.463: ICMPv6: Received echo request from FE80::C001:1DFF:FEE0:0 *Mar  1 03:59:53.463: ICMPv6: Sending echo reply to FE80::C001:1DFF:FEE0:0 *Mar  1 03:59:53.467: ICMPv6: Received echo request from FE80::C001:1DFF:FEE0:0 *Mar  1 03:59:53.467: ICMPv6: Sending echo reply to FE80::C001:1DFF:FEE0:0 R1# *Mar  1 03:59:53.471: ICMPv6: Received echo request from FE80::C001:1DFF:FEE0:0 *Mar  1 03:59:53.471: ICMPv6: Sending echo reply to FE80::C001:1DFF:FEE0:0 !--- The debug output shows that the router R2 can ping router R1's link-local address.

Pinging R3 Link-Local Addresses from router R2

In Router R2 R2#pingFE80::AB8 !--- Pinging Link-Local Address of router R3. Output Interface: serial0/1 !--- Note that,to ping LLA,output interface should be mentioned. In our case, R2 connects to R3 throught serial0/1. Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to FE80::AB8, timeout is 2 seconds: Packet sent with a source address of FE80::C001:1DFF:FEE0:0 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 0/18/60 ms Debug output from R3 R3# *Mar  1 04:12:11.518: ICMPv6: Received echo request from FE80::C001:1DFF:FEE0:0 *Mar  1 04:12:11.522: ICMPv6: Sending echo reply to FE80::C001:1DFF:FEE0:0 *Mar  1 04:12:11.594: ICMPv6: Received echo request from FE80::C001:1DFF:FEE0:0 *Mar  1 04:12:11.598: ICMPv6: Sending echo reply to FE80::C001:1DFF:FEE0:0 *Mar  1 04:12:11.618: ICMPv6: Received echo request from FE80::C001:1DFF:FEE0:0 *Mar  1 04:12:11.618: ICMPv6: Sending echo reply to FE80::C001:1DFF:FEE0:0 *Mar  1 04:12:11.622: ICMPv6: Received echo request from FE80::C001:1DFF:FEE0:0 *Mar  1 04:12:11.622: ICMPv6: Sending echo reply to FE80::C001:1DFF:FEE0:0 R3# *Mar  1 04:12:11.626: ICMPv6: Received echo request from FE80::C001:1DFF:FEE0:0 *Mar  1 04:12:11.630: ICMPv6: Sending echo reply to FE80::C001:1DFF:FEE0:0 !--- The debug output shows that the router R2 can ping router R3's link-local address.

The link-local address as the name implies, is specific only to that local network. In other words, the routers can have the same link-local address and still the directly connected network can communicate with each other without any conflict. This will not be the same in case of global unicast address. The global unicast address being routable should be unique in a network. The show ipv6 interface brief command shows the information about link-local address on the interface.

show ipv6 interface brief

In router R1 R1#show ipv6 interface brief Serial0/0                  [up/up]     FE80::AB8     2001::1 Loopback10                 [up/up]     FE80::C000:1DFF:FEE0:0     2010::C000:1DFF:FEE0:0 Loopback20                 [up/up]     FE80::C000:1DFF:FEE0:0     2020::C000:1DFF:FEE0:0 In router R3 R3#show ipv6 interface brief Serial0/0                  [up/up]     FE80::AB8     2002::2 Loopback10                 [up/up]     FE80::C002:1DFF:FEE0:0     1010::C002:1DFF:FEE0:0 Loopback20                 [up/up]     FE80::C002:1DFF:FEE0:0     2020::C002:1DFF:FEE0:0 !--- Shows that R1 and R3's serial interface has same link-local address FE80::AB8.

In this example, R1 and R3 are assigned with the same link-local address and R2 can still reach both the routers by specifying the corresponding output interface.

Pinging R1 and R3's Link-local address from R2

Pinging R1's link-local address from R2 R2#ping FE80::AB8 Output Interface: serial0/0 !--- R2 is connected to R1 through serial0/0. Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to FE80::AB8, timeout is 2 seconds: Packet sent with a source address of FE80::C001:1DFF:FEE0:0 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 0/26/92 ms Debug output from R1 R1# *Mar  1 19:51:31.855: ICMPv6: Received echo request from FE80::C001:1DFF:FEE0:0 *Mar  1 19:51:31.859: ICMPv6: Sending echo reply to FE80::C001:1DFF:FEE0:0 *Mar  1 19:51:31.915: ICMPv6: Received echo request from FE80::C001:1DFF:FEE0:0 *Mar  1 19:51:31.919: ICMPv6: Sending echo reply to FE80::C001:1DFF:FEE0:0 *Mar  1 19:51:31.947: ICMPv6: Received echo request from FE80::C001:1DFF:FEE0:0 *Mar  1 19:51:31.947: ICMPv6: Sending echo reply to FE80::C001:1DFF:FEE0:0 *Mar  1 19:51:31.955: ICMPv6: Received echo request from FE80::C001:1DFF:FEE0:0 *Mar  1 19:51:31.955: ICMPv6: Sending echo reply to FE80::C001:1DFF:FEE0:0 R1# *Mar  1 19:51:31.955: ICMPv6: Received echo request from FE80::C001:1DFF:FEE0:0 *Mar  1 19:51:31.955: ICMPv6: Sending echo reply to FE80::C001:1DFF:FEE0:0 Pinging R3's link-local address from R2 R2#ping FE80::AB8 Output Interface: serial0/1 !--- R2 is connected to R1 through serial0/1. Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to FE80::AB8, timeout is 2 seconds: Packet sent with a source address of FE80::C001:1DFF:FEE0:0 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/28/76 ms Debug output from R3 R3# *Mar  1 19:53:38.815: ICMPv6: Received echo request from FE80::C001:1DFF:FEE0:0 *Mar  1 19:53:38.819: ICMPv6: Sending echo reply to FE80::C001:1DFF:FEE0:0 *Mar  1 19:53:38.911: ICMPv6: Received echo request from FE80::C001:1DFF:FEE0:0 *Mar  1 19:53:38.915: ICMPv6: Sending echo reply to FE80::C001:1DFF:FEE0:0 *Mar  1 19:53:38.923: ICMPv6: Received echo request from FE80::C001:1DFF:FEE0:0 *Mar  1 19:53:38.927: ICMPv6: Sending echo reply to FE80::C001:1DFF:FEE0:0 *Mar  1 19:53:38.955: ICMPv6: Received echo request from FE80::C001:1DFF:FEE0:0 *Mar  1 19:53:38.955: ICMPv6: Sending echo reply to FE80::C001:1DFF:FEE0:0 R3# *Mar  1 19:53:38.963: ICMPv6: Received echo request from FE80::C001:1DFF:FEE0:0 *Mar  1 19:53:38.963: ICMPv6: Sending echo reply to FE80::C001:1DFF:FEE0:0

Note: The R2 can ping the link-local address of R1 and R3 only because they are directly connected. R2 cannot ping the link-local address of the loopback interfaces in routers R1 and R3 as they are not directly connected. Ping works on link-local addresses only in case of directly connected networks.

Note: Traceroutes do not work in case of link-local addresses and return with the % No valid source address for destination. error message. This is because IPv6 routers must not forward packets that have link-local source or destination addresses to other links.