Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2461

Neighbor Discovery for IP Version 6 (IPv6)

Pages: 93
Obsoletes:  1970
Obsoleted by:  4861
Updated by:  4311
Part 2 of 4 – Pages 17 to 37
First   Prev   Next

ToP   noToC   RFC2461 - Page 17   prevText
4.  MESSAGE FORMATS

4.1.  Router Solicitation Message Format

   Hosts send Router Solicitations in order to prompt routers to
   generate Router Advertisements quickly.

      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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Reserved                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address
                     An IP address assigned to the sending interface, or
                     the unspecified address if no address is assigned
                     to the sending interface.

      Destination Address
                     Typically the all-routers multicast address.

      Hop Limit      255

      Authentication Header
                     If a Security Association for the IP Authentication
                     Header exists between the sender and the
                     destination address, then the sender SHOULD include
                     this header.

   ICMP Fields:

      Type           133

      Code           0

      Checksum       The ICMP checksum.  See [ICMPv6].

      Reserved       This field is unused.  It MUST be initialized to
                     zero by the sender and MUST be ignored by the
                     receiver.
ToP   noToC   RFC2461 - Page 18
   Valid Options:

      Source link-layer address
                     The link-layer address of the sender, if known.
                     MUST NOT be included if the Source Address is the
                     unspecified address.  Otherwise it SHOULD be
                     included on link layers that have addresses.

      Future versions of this protocol may define new option types.
      Receivers MUST silently ignore any options they do not recognize
      and continue processing the message.

4.2.  Router Advertisement Message Format

   Routers send out Router Advertisement message periodically, or in
   response to a Router Solicitation.

      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|  Reserved |       Router Lifetime         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Reachable Time                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Retrans Timer                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address
                     MUST be the link-local address assigned to the
                     interface from which this message is sent.

      Destination Address
                     Typically the Source Address of an invoking Router
                     Solicitation or the all-nodes multicast address.

      Hop Limit      255

      Authentication Header
                     If a Security Association for the IP Authentication
                     Header exists between the sender and the
                     destination address, then the sender SHOULD include
                     this header.
ToP   noToC   RFC2461 - Page 19
   ICMP Fields:

      Type           134

      Code           0

      Checksum       The ICMP checksum.  See [ICMPv6].

      Cur Hop Limit  8-bit unsigned integer.  The default value that
                     should be placed in the Hop Count field of the IP
                     header for outgoing IP packets.  A value of zero
                     means unspecified (by this router).

      M              1-bit "Managed address configuration" flag.  When
                     set, hosts use the administered (stateful) protocol
                     for address autoconfiguration in addition to any
                     addresses autoconfigured using stateless address
                     autoconfiguration.  The use of this flag is
                     described in [ADDRCONF].

      O              1-bit "Other stateful configuration" flag.  When
                     set, hosts use the administered (stateful) protocol
                     for autoconfiguration of other (non-address)
                     information.  The use of this flag is described in
                     [ADDRCONF].

      Reserved       A 6-bit unused field.  It MUST be initialized to
                     zero by the sender and MUST be ignored by the
                     receiver.

      Router Lifetime
                     16-bit unsigned integer.  The lifetime associated
                     with the default router in units of seconds.  The
                     maximum value corresponds to 18.2 hours.  A
                     Lifetime of 0 indicates that the router is not a
                     default router and SHOULD NOT appear on the default
                     router list.  The Router Lifetime applies only to
                     the router's usefulness as a default router; it
                     does not apply to information contained in other
                     message fields or options.  Options that need time
                     limits for their information include their own
                     lifetime fields.

      Reachable Time 32-bit unsigned integer.  The time, in
                     milliseconds, that a node assumes a neighbor is
                     reachable after having received a reachability
                     confirmation.  Used by the Neighbor Unreachability
                     Detection algorithm (see Section 7.3).  A value of
ToP   noToC   RFC2461 - Page 20
                     zero means unspecified (by this router).

      Retrans Timer  32-bit unsigned integer.  The time, in
                     milliseconds, between retransmitted Neighbor
                     Solicitation messages.  Used by address resolution
                     and the Neighbor Unreachability Detection algorithm
                     (see Sections 7.2 and 7.3).  A value of zero means
                     unspecified (by this router).

   Possible options:

      Source link-layer address
                     The link-layer address of the interface from which
                     the Router Advertisement is sent.  Only used on
                     link layers that have addresses.  A router MAY omit
                     this option in order to enable inbound load sharing
                     across multiple link-layer addresses.

      MTU            SHOULD be sent on links that have a variable MTU
                     (as specified in the document that describes how to
                     run IP over the particular link type).  MAY be sent
                     on other links.

      Prefix Information
                     These options specify the prefixes that are on-link
                     and/or are used for address autoconfiguration.  A
                     router SHOULD include all its on-link prefixes
                     (except the link-local prefix) so that multihomed
                     hosts have complete prefix information about on-
                     link destinations for the links to which they
                     attach.  If complete information is lacking, a
                     multihomed host may not be able to choose the
                     correct outgoing interface when sending traffic to
                     its neighbors.

      Future versions of this protocol may define new option types.
      Receivers MUST silently ignore any options they do not recognize
      and continue processing the message.
ToP   noToC   RFC2461 - Page 21
4.3.  Neighbor Solicitation Message Format

   Nodes send Neighbor Solicitations to request the link-layer address
   of a target node while also providing their own link-layer address to
   the target.  Neighbor Solicitations are multicast when the node needs
   to resolve an address and unicast when the node seeks to verify the
   reachability of a neighbor.

         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             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                           Reserved                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                                                               +
        |                                                               |
        +                       Target Address                          +
        |                                                               |
        +                                                               +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Options ...
        +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address
                     Either an address assigned to the interface from
                     which this message is sent or (if Duplicate Address
                     Detection is in progress [ADDRCONF]) the
                     unspecified address.

      Destination Address
                     Either the solicited-node multicast address
                     corresponding to the target address, or the target
                     address.

      Hop Limit      255

      Authentication Header
                     If a Security Association for the IP Authentication
                     Header exists between the sender and the
                     destination address, then the sender SHOULD include
                     this header.
ToP   noToC   RFC2461 - Page 22
   ICMP Fields:

      Type           135

      Code           0

      Checksum       The ICMP checksum.  See [ICMPv6].

      Reserved       This field is unused.  It MUST be initialized to
                     zero by the sender and MUST be ignored by the
                     receiver.

      Target Address
                     The IP address of the target of the solicitation.
                     It MUST NOT be a multicast address.

   Possible options:

      Source link-layer address
                     The link-layer address for the sender.  MUST NOT be
                     included when the source IP address is the
                     unspecified address.  Otherwise, on link layers
                     that have addresses this option MUST be included in
                     multicast solicitations and SHOULD be included in
                     unicast solicitations.

      Future versions of this protocol may define new option types.
      Receivers MUST silently ignore any options they do not recognize
      and continue processing the message.
ToP   noToC   RFC2461 - Page 23
4.4.  Neighbor Advertisement Message Format

   A node sends Neighbor Advertisements in response to Neighbor
   Solicitations and sends unsolicited Neighbor Advertisements in order
   to (unreliably) propagate new information quickly.

       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             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R|S|O|                     Reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                       Target Address                          +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Options ...
      +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address
                     An address assigned to the interface from which the
                     advertisement is sent.

      Destination Address
                     For solicited advertisements, the Source Address of
                     an invoking Neighbor Solicitation or, if the
                     solicitation's Source Address is the unspecified
                     address, the all-nodes multicast address.

                     For unsolicited advertisements typically the all-
                     nodes multicast address.

      Hop Limit      255

   Authentication Header
                     If a Security Association for the IP Authentication
                     Header exists between the sender and the
                     destination address, then the sender SHOULD include
                     this header.
ToP   noToC   RFC2461 - Page 24
   ICMP Fields:

      Type           136

      Code           0

      Checksum       The ICMP checksum.  See [ICMPv6].

      R              Router flag.  When set, the R-bit indicates that
                     the sender is a router.  The R-bit is used by
                     Neighbor Unreachability Detection to detect a
                     router that changes to a host.

      S              Solicited flag.  When set, the S-bit indicates that
                     the advertisement was sent in response to a
                     Neighbor Solicitation from the Destination address.
                     The S-bit is used as a reachability confirmation
                     for Neighbor Unreachability Detection.  It MUST NOT
                     be set in multicast advertisements or in
                     unsolicited unicast advertisements.

      O              Override flag.  When set, the O-bit indicates that
                     the advertisement should override an existing cache
                     entry and update the cached link-layer address.
                     When it is not set the advertisement will not
                     update a cached link-layer address though it will
                     update an existing Neighbor Cache entry for which
                     no link-layer address is known.  It SHOULD NOT be
                     set in solicited advertisements for anycast
                     addresses and in solicited proxy advertisements.
                     It SHOULD be set in other solicited advertisements
                     and in unsolicited advertisements.

      Reserved       29-bit unused field.  It MUST be initialized to
                     zero by the sender and MUST be ignored by the
                     receiver.

      Target Address
                     For solicited advertisements, the Target Address
                     field in the Neighbor Solicitation message that
                     prompted this advertisement.  For an unsolicited
                     advertisement, the address whose link-layer address
                     has changed.  The Target Address MUST NOT be a
                     multicast address.
ToP   noToC   RFC2461 - Page 25
   Possible options:

      Target link-layer address
                     The link-layer address for the target, i.e., the
                     sender of the advertisement.  This option MUST be
                     included on link layers that have addresses when
                     responding to multicast solicitations.  When
                     responding to a unicast Neighbor Solicitation this
                     option SHOULD be included.

                     The option MUST be included for multicast
                     solicitations in order to avoid infinite Neighbor
                     Solicitation "recursion" when the peer node does
                     not have a cache entry to return a Neighbor
                     Advertisements message.  When responding to unicast
                     solicitations, the option can be omitted since the
                     sender of the solicitation has the correct link-
                     layer address; otherwise it would not have be able
                     to send the unicast solicitation in the first
                     place. However, including the link-layer address in
                     this case adds little overhead and eliminates a
                     potential race condition where the sender deletes
                     the cached link-layer address prior to receiving a
                     response to a previous solicitation.

      Future versions of this protocol may define new option types.
      Receivers MUST silently ignore any options they do not recognize
      and continue processing the message.
ToP   noToC   RFC2461 - Page 26
4.5.  Redirect Message Format

   Routers send Redirect packets to inform a host of a better first-hop
   node on the path to a destination.  Hosts can be redirected to a
   better first-hop router but can also be informed by a redirect that
   the destination is in fact a neighbor.  The latter is accomplished by
   setting the ICMP Target Address equal to the ICMP Destination
   Address.

       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             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                       Target Address                          +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                     Destination Address                       +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Options ...
      +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address
                     MUST be the link-local address assigned to the
                     interface from which this message is sent.

      Destination Address
                     The Source Address of the packet that triggered the
                     redirect.

      Hop Limit      255
ToP   noToC   RFC2461 - Page 27
      Authentication Header
                     If a Security Association for the IP Authentication
                     Header exists between the sender and the
                     destination address, then the sender SHOULD include
                     this header.

   ICMP Fields:

      Type           137

      Code           0

      Checksum       The ICMP checksum.  See [ICMPv6].

      Reserved       This field is unused.  It MUST be initialized to
                     zero by the sender and MUST be ignored by the
                     receiver.

      Target Address An IP address that is a better first hop to use for
                     the ICMP Destination Address.  When the target is
                     the actual endpoint of communication, i.e., the
                     destination is a neighbor, the Target Address field
                     MUST contain the same value as the ICMP Destination
                     Address field.  Otherwise the target is a better
                     first-hop router and the Target Address MUST be the
                     router's link-local address so that hosts can
                     uniquely identify routers.

      Destination Address
                     The IP address of the destination which is
                     redirected to the target.

   Possible options:

      Target link-layer address
                     The link-layer address for the target.  It SHOULD
                     be included (if known).  Note that on NBMA links,
                     hosts may rely on the presence of the Target Link-
                     Layer Address option in Redirect messages as the
                     means for determining the link-layer addresses of
                     neighbors.  In such cases, the option MUST be
                     included in Redirect messages.

      Redirected Header
                     As much as possible of the IP packet that triggered
                     the sending of the Redirect without making the
                     redirect packet exceed 1280 octets.
ToP   noToC   RFC2461 - Page 28
4.6.  Option Formats

   Neighbor Discovery messages include zero or more options, some of
   which may appear multiple times in the same message.  All options are
   of the form:

        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      |    Length     |              ...              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                              ...                              ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fields:

      Type           8-bit identifier of the type of option.  The
                     options defined in this document are:

                           Option Name                             Type

                        Source Link-Layer Address                    1
                        Target Link-Layer Address                    2
                        Prefix Information                           3
                        Redirected Header                            4
                        MTU                                          5


      Length         8-bit unsigned integer.  The length of the option
                     (including the type and length fields) in units of
                     8 octets.  The value 0 is invalid.  Nodes MUST
                     silently discard an ND packet that contains an
                     option with length zero.

4.6.1.  Source/Target Link-layer Address

      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      |    Length     |    Link-Layer Address ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fields:

      Type
                     1 for Source Link-layer Address
                     2 for Target Link-layer Address
ToP   noToC   RFC2461 - Page 29
      Length         The length of the option (including the type and
                     length fields) in units of 8 octets.  For example,
                     the length for IEEE 802 addresses is 1 [IPv6-
                     ETHER].

      Link-Layer Address
                     The variable length link-layer address.

                     The content and format of this field (including
                     byte and bit ordering) is expected to be specified
                     in specific documents that describe how IPv6
                     operates over different link layers.  For instance,
                     [IPv6-ETHER].

   Description
                     The Source Link-Layer Address option contains the
                     link-layer address of the sender of the packet.  It
                     is used in the Neighbor Solicitation, Router
                     Solicitation, and Router Advertisement packets.

                     The Target Link-Layer Address option contains the
                     link-layer address of the target.  It is used in
                     Neighbor Advertisement and Redirect packets.

                     These options MUST be silently ignored for other
                     Neighbor Discovery messages.

4.6.2.  Prefix Information

       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      |    Length     | Prefix Length |L|A| Reserved1 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Valid Lifetime                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Preferred Lifetime                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved2                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                            Prefix                             +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ToP   noToC   RFC2461 - Page 30
   Fields:

      Type           3

      Length         4

      Prefix Length  8-bit unsigned integer.  The number of leading bits
                     in the Prefix that are valid.  The value ranges
                     from 0 to 128.

      L              1-bit on-link flag.  When set, indicates that this
                     prefix can be used for on-link determination.  When
                     not set the advertisement makes no statement about
                     on-link or off-link properties of the prefix.  For
                     instance, the prefix might be used for address
                     configuration with some of the addresses belonging
                     to the prefix being on-link and others being off-
                     link.

      A              1-bit autonomous address-configuration flag.  When
                     set indicates that this prefix can be used for
                     autonomous address configuration as specified in
                     [ADDRCONF].

      Reserved1      6-bit unused field.  It MUST be initialized to zero
                     by the sender and MUST be ignored by the receiver.

      Valid Lifetime
                     32-bit unsigned integer.  The length of time in
                     seconds (relative to the time the packet is sent)
                     that the prefix is valid for the purpose of on-link
                     determination.  A value of all one bits
                     (0xffffffff) represents infinity.  The Valid
                     Lifetime is also used by [ADDRCONF].

      Preferred Lifetime
                     32-bit unsigned integer.  The length of time in
                     seconds (relative to the time the packet is sent)
                     that addresses generated from the prefix via
                     stateless address autoconfiguration remain
                     preferred [ADDRCONF].  A value of all one bits
                     (0xffffffff) represents infinity.  See [ADDRCONF].

      Reserved2      This field is unused.  It MUST be initialized to
                     zero by the sender and MUST be ignored by the
                     receiver.
ToP   noToC   RFC2461 - Page 31
      Prefix         An IP address or a prefix of an IP address.  The
                     Prefix Length field contains the number of valid
                     leading bits in the prefix.  The bits in the prefix
                     after the prefix length are reserved and MUST be
                     initialized to zero by the sender and ignored by
                     the receiver.  A router SHOULD NOT send a prefix
                     option for the link-local prefix and a host SHOULD
                     ignore such a prefix option.

   Description
                     The Prefix Information option provide hosts with
                     on-link prefixes and prefixes for Address
                     Autoconfiguration.

                     The Prefix Information option appears in Router
                     Advertisement packets and MUST be silently ignored
                     for other messages.

4.6.3.  Redirected Header

       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      |    Length     |            Reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                       IP header + data                        ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fields:

      Type           4

      Length         The length of the option in units of 8 octets.

      Reserved       These fields are unused.  They MUST be initialized
                     to zero by the sender and MUST be ignored by the
                     receiver.

      IP header + data
                     The original packet truncated to ensure that the
                     size of the redirect message does not exceed 1280
                     octets.
ToP   noToC   RFC2461 - Page 32
   Description
                     The Redirected Header option is used in Redirect
                     messages and contains all or part of the packet
                     that is being redirected.

                     This option MUST be silently ignored for other
                     Neighbor Discovery messages.

4.6.4.  MTU

       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      |    Length     |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              MTU                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fields:

      Type           5

      Length         1

      Reserved       This field is unused.  It MUST be initialized to
                     zero by the sender and MUST be ignored by the
                     receiver.

      MTU            32-bit unsigned integer.  The recommended MTU for
                     the link.

   Description
                     The MTU option is used in  Router Advertisement
                     messages to insure that all nodes on a link use the
                     same MTU value in those cases where the link MTU is
                     not well known.

                     This option MUST be silently ignored for other
                     Neighbor Discovery messages.

                     In configurations in which heterogeneous
                     technologies are bridged together, the maximum
                     supported MTU may differ from one segment to
                     another.  If the bridges do not generate ICMP
                     Packet Too Big messages, communicating nodes will
                     be unable to use Path MTU to dynamically determine
                     the appropriate MTU on a per-neighbor basis.  In
                     such cases, routers use the MTU option to specify
ToP   noToC   RFC2461 - Page 33
                     the maximum MTU value that is supported by all
                     segments.

5.  CONCEPTUAL MODEL OF A HOST

   This section describes a conceptual model of one possible data
   structure organization that hosts (and to some extent routers) will
   maintain in interacting with neighboring nodes.  The described
   organization is provided to facilitate the explanation of how the
   Neighbor Discovery protocol should behave.  This document does not
   mandate that implementations adhere to this model as long as their
   external behavior is consistent with that described in this document.

   This model is only concerned with the aspects of host behavior
   directly related to Neighbor Discovery.  In particular, it does not
   concern itself with such issues as source address selection or the
   selecting of an outgoing interface on a multihomed host.

5.1.  Conceptual Data Structures

   Hosts will need to maintain the following pieces of information for
   each interface:

      Neighbor Cache
                   - A set of entries about individual neighbors to
                     which traffic has been sent recently.  Entries are
                     keyed on the neighbor's on-link unicast IP address
                     and contain such information as its link-layer
                     address, a flag indicating whether the neighbor is
                     a router or a host (called IsRouter in this
                     document), a pointer to any queued packets waiting
                     for address resolution to complete, etc.

                     A Neighbor Cache entry also contains information
                     used by the Neighbor Unreachability Detection
                     algorithm, including the reachability state, the
                     number of unanswered probes, and the time the next
                     Neighbor Unreachability Detection event is
                     scheduled to take place.

      Destination Cache
                   - A set of entries about destinations to which
                     traffic has been sent recently.  The Destination
                     Cache includes both on-link and off-link
                     destinations and provides a level of indirection
                     into the Neighbor Cache; the Destination Cache maps
                     a destination IP address to the IP address of the
                     next-hop neighbor.  This cache is updated with
ToP   noToC   RFC2461 - Page 34
                     information learned from Redirect messages.
                     Implementations may find it convenient to store
                     additional information not directly related to
                     Neighbor Discovery in Destination Cache entries,
                     such as the Path MTU (PMTU) and round trip timers
                     maintained by transport protocols.

      Prefix List  - A list of the prefixes that define a set of
                     addresses that are on-link.  Prefix List entries
                     are created from information received in Router
                     Advertisements.  Each entry has an associated
                     invalidation timer value (extracted from the
                     advertisement) used to expire prefixes when they
                     become invalid.  A special "infinity" timer value
                     specifies that a prefix remains valid forever,
                     unless a new (finite) value is received in a
                     subsequent advertisement.

                     The link-local prefix is considered to be on the
                     prefix list with an infinite invalidation timer
                     regardless of whether routers are advertising a
                     prefix for it.  Received Router Advertisements
                     SHOULD NOT modify the invalidation timer for the
                     link-local prefix.

      Default Router List
                   - A list of routers to which packets may be sent.
                     Router list entries point to entries in the
                     Neighbor Cache; the algorithm for selecting a
                     default router favors routers known to be reachable
                     over those whose reachability is suspect.  Each
                     entry also has an associated invalidation timer
                     value (extracted from Router Advertisements) used
                     to delete entries that are no longer advertised.

   Note that the above conceptual data structures can be implemented
   using a variety of techniques.  One possible implementation is to use
   a single longest-match routing table for all of the above data
   structures.  Regardless of the specific implementation, it is
   critical that the Neighbor Cache entry for a router is shared by all
   Destination Cache entries using that router in order to prevent
   redundant Neighbor Unreachability Detection probes.

   Note also that other protocols (e.g., IPv6 Mobility) might add
   additional conceptual data structures.  An implementation is at
   liberty to implement such data structures in any way it pleases.  For
   example, an implementation could merge all conceptual data structures
   into a single routing table.
ToP   noToC   RFC2461 - Page 35
   The Neighbor Cache contains information maintained by the Neighbor
   Unreachability Detection algorithm.  A key piece of information is a
   neighbor's reachability state, which is one of five possible values.
   The following definitions are informal; precise definitions can be
   found in Section 7.3.2.

      INCOMPLETE  Address resolution is in progress and the link-layer
                  address of the neighbor has not yet been determined.

      REACHABLE   Roughly speaking, the neighbor is known to have been
                  reachable recently (within tens of seconds ago).

      STALE       The neighbor is no longer known to be reachable but
                  until traffic is sent to the neighbor, no attempt
                  should be made to verify its reachability.

      DELAY       The neighbor is no longer known to be reachable, and
                  traffic has recently been sent to the neighbor.
                  Rather than probe the neighbor immediately, however,
                  delay sending probes for a short while in order to
                  give upper layer protocols a chance to provide
                  reachability confirmation.

      PROBE       The neighbor is no longer known to be reachable, and
                  unicast Neighbor Solicitation probes are being sent to
                  verify reachability.

5.2.  Conceptual Sending Algorithm

   When sending a packet to a destination, a node uses a combination of
   the Destination Cache, the Prefix List, and the Default Router List
   to determine the IP address of the appropriate next hop, an operation
   known as "next-hop determination".  Once the IP address of the next
   hop is known, the Neighbor Cache is consulted for link-layer
   information about that neighbor.

   Next-hop determination for a given unicast destination operates as
   follows.  The sender performs a longest prefix match against the
   Prefix List to determine whether the packet's destination is on- or
   off-link.  If the destination is on-link, the next-hop address is the
   same as the packet's destination address.  Otherwise, the sender
   selects a router from the Default Router List (following the rules
   described in Section 6.3.6).  If the Default Router List is empty,
   the sender assumes that the destination is on-link.

   For efficiency reasons, next-hop determination is not performed on
   every packet that is sent.  Instead, the results of next-hop
   determination computations are saved in the Destination Cache (which
ToP   noToC   RFC2461 - Page 36
   also contains updates learned from Redirect messages).  When the
   sending node has a packet to send, it first examines the Destination
   Cache.  If no entry exists for the destination, next-hop
   determination is invoked to create a Destination Cache entry.

   Once the IP address of the next-hop node is known, the sender
   examines the Neighbor Cache for link-layer information about that
   neighbor.  If no entry exists, the sender creates one, sets its state
   to INCOMPLETE, initiates Address Resolution, and then queues the data
   packet pending completion of address resolution.  For multicast-
   capable interfaces Address Resolution consists of sending a Neighbor
   Solicitation message and waiting for a Neighbor Advertisement.  When
   a Neighbor Advertisement response is received, the link-layer
   addresses is entered in the Neighbor Cache entry and the queued
   packet is transmitted.  The address resolution mechanism is described
   in detail in Section 7.2.

   For multicast packets the next-hop is always the (multicast)
   destination address and is considered to be on-link.  The procedure
   for determining the link-layer address corresponding to a given IP
   multicast address can be found in a separate document that covers
   operating IP over a particular link type (e.g., [IPv6-ETHER]).

   Each time a Neighbor Cache entry is accessed while transmitting a
   unicast packet, the sender checks Neighbor Unreachability Detection
   related information according to the Neighbor Unreachability
   Detection algorithm (Section 7.3).  This unreachability check might
   result in the sender transmitting a unicast Neighbor Solicitation to
   verify that the neighbor is still reachable.

   Next-hop determination is done the first time traffic is sent to a
   destination.  As long as subsequent communication to that destination
   proceeds successfully, the Destination Cache entry continues to be
   used.  If at some point communication ceases to proceed, as
   determined by the Neighbor Unreachability Detection algorithm, next-
   hop determination may need to be performed again.  For example,
   traffic through a failed router should be switched to a working
   router.  Likewise, it may be possible to reroute traffic destined for
   a mobile node to a "mobility agent".

   Note that when a node redoes next-hop determination there is no need
   to discard the complete Destination Cache entry.  In fact, it is
   generally beneficial to retain such cached information as the PMTU
   and round trip timer values that may also be kept in the Destination
   Cache entry.
ToP   noToC   RFC2461 - Page 37
   Routers and multihomed hosts have multiple interfaces.  The remainder
   of this document assumes that all sent and received Neighbor
   Discovery messages refer to the interface of appropriate context.
   For example, when responding to a Router Solicitation, the
   corresponding Router Advertisement is sent out the interface on which
   the solicitation was received.

5.3.  Garbage Collection and Timeout Requirements

   The conceptual data structures described above use different
   mechanisms for discarding potentially stale or unused information.

   From the perspective of correctness there is no need to periodically
   purge Destination and Neighbor Cache entries.  Although stale
   information can potentially remain in the cache indefinitely, the
   Neighbor Unreachability Detection algorithm ensures that stale
   information is purged quickly if it is actually being used.

   To limit the storage needed for the Destination and Neighbor Caches,
   a node may need to garbage-collect old entries.  However, care must
   be taken to insure that sufficient space is always present to hold
   the working set of active entries.  A small cache may result in an
   excessive number of Neighbor Discovery messages if entries are
   discarded and rebuilt in quick succession.  Any LRU-based policy that
   only reclaims entries that have not been used in some time (e.g., ten
   minutes or more) should be adequate for garbage-collecting unused
   entries.

   A node should retain entries in the Default Router List and the
   Prefix List until their lifetimes expire.  However, a node may
   garbage collect entries prematurely if it is low on memory.  If not
   all routers are kept on the Default Router list, a node should retain
   at least two entries in the Default Router List (and preferably more)
   in order to maintain robust connectivity for off-link destinations.

   When removing an entry from the Prefix List there is no need to purge
   any entries from the Destination or Neighbor Caches.  Neighbor
   Unreachability Detection will efficiently purge any entries in these
   caches that have become invalid.  When removing an entry from the
   Default Router List, however, any entries in the Destination Cache
   that go through that router must perform next-hop determination again
   to select a new default router.



(page 37 continued on part 3)

Next Section