Layer 3 to Layer 2 resolution in IPv6

 IPv6  Add comments
Aug 302012
 

When the packet travels down the OSI and reaches the network layer, the MAC address must be resolved from the destination host for the encapsulation process. Traditionally this was done in IPv4 using ARP which uses broadcast packets. As in IPv6 we do not have Broadcasts, this must be done with the help of Multicasts. In IPv6 we do not have a separate protocol to accomplish this; it is built into the IPv6 stack itself. The Layer 3 to Layer 2 resolution in done with ICMP neighbor discovery.

Each host which has an IPv6 address configured listens to a particular multicast group. Thus there could be many hosts which listen to the same group. Finally the neighbor discovery request will itself contain the L3 address to be resolved, and only the host which is configured with the address in question will answer the request.

The neighbor discovery packet is an ICMPv6 Packet which has a type code of 135. This is called a neighbor solicitation packet. This is equivalent to the ARP request. The host which has the address configured will answer with an ICMPv6 packet with a type code of 136. This is called a neighbor advertisement packet. This is equivalent to ARP reply.

When an interface is assigned an IPv6 address, it will join a multicast group of FF02:0:0:0:0:1:FFXX:XXXX. The X is the last 24 bits of the IPv6 address which is assigned to an interface. Let us look into the details, when R1 has the IPv6 address of 123::1/64 assigned. It will then join a multicast group of FF02::1:FF00:1.

R1(config)#interface f0/0
R1(config-if)#ipv6 address 123::1:0:123/64
 
R1#sh ipv6 interface
FastEthernet0/0 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::211:11FF:FE11:1111
  No Virtual link-local address(es):
  Global unicast address(es):
    123::1:0:123, subnet is 123::/64
  Joined group address(es):
    FF02::1
    FF02::1:FF00:123
    FF02::1:FF11:1111
  MTU is 1500 bytes
  ICMP error messages limited to one every 100 milliseconds
  ICMP redirects are enabled
  ICMP unreachables are sent
  ND DAD is enabled, number of DAD attempts: 1
  ND reachable time is 30000 milliseconds
 

R1 has joined the multicast group of FF02::1:FF00:123. It has also joined the multicast group of FF02::1:FF11:1111, which represents the Link-local address of FE80::211:11FF:FE11:1111. It has also joined all hosts multicast group (FF02::1).

As the last 24 bits of the IP address from all routers are the same, they will all join the same multicast group of FF02::1:FF00:123.

R2#sh ipv6 interface | section Joined
  Joined group address(es):
    FF02::1
    FF02::1:FF00:123
    FF02::1:FF22:2222
 
R3#sh ipv6 interface | section Joined
  Joined group address(es):
    FF02::1
    FF02::1:FF00:123
    FF02::1:FF33:3333
 

Let us now check the scenario when R1 (123::1:0:123) pings R2 (123::2:0:123):

R1 checks its neighbor table if R2 is in the state of reachable. The neighbor table does not have an entry for R2 as no packets have been transmitted yet.

  1. R1 then sends a neighbor solicitation to the solicited node multicast address of R2 (FF02::1:FF00:123) with a source address of the interface (123::1:0:123).
  2. R2 then replies to R1 with a neighbor advertisement, which has its MAC Address.
  3. R1 then can ping R2, it also stores this information in its neighbor cache.

Below is the output of debub ipv6 nd from R1

  1. 13:54:28: ICMPv6-ND: DELETE -> INCMP: 123::2:0:123
  2. 13:54:28: ICMPv6-ND: Sending NS for 123::2:0:123 on FastEthernet0/0
  3. 13:54:28: ICMPv6-ND: Received NA for 123::2:0:123 on FastEthernet0/0 from 123::2:0:123
  4. 13:54:28: ICMPv6-ND: Neighbour 123::2:0:123 on FastEthernet0/0 : LLA 0022.2222.2222
  5. 13:54:28: ICMPv6-ND: INCMP -> REACH: 123::2:0:123
  6. 13:54:33: ICMPv6-ND: Received NS for 123::1:0:123 on FastEthernet0/0 from FE80::222:22FF:FE22:2222
  7. 13:54:33: ICMPv6-ND: DELETE -> INCMP: FE80::222:22FF:FE22:2222
  8. 13:54:33: ICMPv6-ND: Neighbour FE80::222:22FF:FE22:2222 on FastEthernet0/0 : LLA 0022.2222.2222
  9. 13:54:33: ICMPv6-ND: INCMP -> STALE: FE80::222:22FF:FE22:2222
  10. 13:54:33: ICMPv6-ND: Sending NA for 123::1:0:123 on FastEthernet0/0
  11. 13:54:33: ICMPv6-ND: STALE -> DELAY: FE80::222:22FF:FE22:2222
  12. 13:54:38: ICMPv6-ND: DELAY -> PROBE: FE80::222:22FF:FE22:2222
  13. 13:54:38: ICMPv6-ND: Sending NS for FE80::222:22FF:FE22:2222 on FastEthernet0/0
  14. 13:54:38: ICMPv6-ND: Received NA for FE80::222:22FF:FE22:2222 on FastEthernet0/0 from FE80::222:22FF:FE22:2222
  15. 13:54:38: ICMPv6-ND: PROBE -> REACH: FE80::222:22FF:FE22:2222
  16. 13:54:43: ICMPv6-ND: Received NS for FE80::211:11FF:FE11:1111 on FastEthernet0/0 from FE80::222:22FF:FE22:2222
  17. 13:54:43: ICMPv6-ND: Sending NA for FE80::211:11FF:FE11:1111 on FastEthernet0/0
  18. 13:54:58: ICMPv6-ND: REACH -> STALE: 123::2:0:123
  19. 13:55:08: ICMPv6-ND: REACH -> STALE: FE80::222:22FF:FE22:2222

Entry number 1 shows that the neighbor state does not exist, as it tells that the status changed from DELETED to INCOMPLETE

Entry number 2 shows that a neighbor solicitation is sent for 123::2:0:123 out of interface FastEthernet0/0

Entry number 3 and 4  shows that a neighbor advertisement is being received from R2 which has the MAC address of R2 (0022.2222.2222)

Entry number 5 shows that the state of the neighbor changed from INCOMPLETE to REACHABLE

The rest of the debug output is not relevant for the scenario.