Neighbor Discovery

From Citizendium
Revision as of 10:23, 8 August 2008 by imported>TJ Evans (→‎Router Discovery)
Jump to navigation Jump to search
This article is developing and not approved.
Main Article
Discussion
Definition [?]
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article is under development and subject to a disclaimer.

The Neighbor Discovery Protocol is the name of a series of processes used by IPv6 for the purposes of Neighbor Discovery (a bit of recursive naming there, sorry!), Router Discovery and Neighbor Unreachability Detection (NUD). The actual act of Neighbor Discovery is how IPv6 nodes determine the L2 address (e.g. - MAC) for a known L3 address (e.g. - IPv6); very analogous to the function performed by ARP in IPv4.

Neighbor Discovery

The goal of Neighbor Discovery is to allow nodes on-link with each other to communicate. In order to accomplish this on most media types, the source needs to "discovery" the L2 (e.g. - MAC) address of the destination.

In IPv4 this is done using ARP, which while certainly functional, entails the use of broadcast. Broadcast-based mechanisms, by definition, interrupt all other hosts on that network segment.

IPv6 uses multicast-based Neighbor Discovery to accomplish this goal, without interrupting every other node on that link. Ideally, only the correct destination node receives the frame/packet.

This is accomplished in several steps:

  • Let's assume a destination address of 2001:db8:1:1::1.
  • This is mapped into the "Solicited Node Multicast Address" (SNMA) format of ff02::1:ffXX:XXXX.
  • The XX:XXXX represent the last 24 bits of the SNMA, and are derived directly from the last 24 bits of the destination address.
  • Resulting in a SNMA ff02::1:ff00:0001, or ff02::1:ff00:1.
  • This, being a multicast address, can be mapped to a multicast MAC address, using the format 33-33-XX-XX-XX-XX
  • Resulting in 33-33-ff-00-00-01
  • This is a MAC address that is only being listened for by nodes sharing the same last 24 bits.
  • In other words, while there is a chance for a "address collision", it is a vast improvement over ARP's guaranteed "collision".

With the above process in mind, now we can get into how we use them ...

  • There are two new ICMPv6 messages for this portion of Neighbor Discovery, the Neighbor Advertisement and the Neighbor Solicitation. (In IPv4 we would call these ARP-Request and ARP-Reply.)
  • When used as described above, Neighbor Solicitation (NS) messages are multicast to the SNMA of the destination using ICMPv6 messaging (type 135); specifying the 128bit "Target Address" and using the "Source Link Layer Address Option" (SLLAO) so that the destination will not need to do similar to find the source's MAC address.
  • Again, following the above situation, the response to a NS would be a Neighbor Advertisement (NA). Again, suing ICMPv6 messaging (type 136, this time) and using the "Target Link Layer Address Option" (TLLAO).


After the NS-NA exchange the hosts can now communicate as they know each others' L2 addresses.

  • Note that the NS and NA messages can be used for other purposes, such as Duplicate Address Detection (NS), Neighbor Unreachability Detection (NS) and updating Neighbor Tables (NA).

Router Discovery

The goal of Router Discovery is to provide a mechanism for routers to provide information to hosts.

This is accomplished through the sending of Router Advertisements (RAs). RAs use ISMPv6 messaging (type 134) of the following format (Updated from RFC4861's picture to include RFC4191 and RFC3775):

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |          Checksum             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Cur Hop Limit |M|O|H|DRP|RSVRD|       Router Lifetime         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Reachable Time                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Retrans Timer                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Options ...
    +-+-+-+-+-+-+-+-+-+-+-+-

Most noticeably, the RA provides default gateway information (the router's MAC address, and it's Link Local address) and (when SLAAC or Stateless DHCPv6 is in use) prefix information to hosts. The Gateway Information can also include a "Default Router Preference" or more specific routes (both defined in RFC4191, although note that Cisco does not currently support the latter).

Prefix Information is TLV encoded into an Option (as are SLLAO, TLLAO, MTU & Redirects).

 Option Name                                  Option #
 Source Link-Layer Address                    1         (SLLAO)
 Target Link-Layer Address                    2         (TLLAO)
 Prefix Information                           3         (PIO)
 Redirected Header                            4         (Redirect)
 Maximum Transmission Unit                    5         (MTU)

Note that the PIO includes other information needed for SLAAC as well; things such as the Valid & Preferred Lifetimes, an On-Link indicator, an AutoConfiguration bit and - of course - the Prefix, or prefixes, needed for SLAAC.

The RAs are sent periodically (approximately once every 3 minutes) by default, or in response to a Router Solicitation (RS). Note that the time interval can be manually defined.

Neighbor Unreachability Detection