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 4 of 4 – Pages 70 to 93
First   Prev   None

ToP   noToC   RFC2461 - Page 70   prevText
8.  REDIRECT FUNCTION

   This section describes the functions related to the sending and
   processing of Redirect messages.

   Redirect messages are sent by routers to redirect a host to a better
   first-hop router for a specific destination or to inform hosts that a
   destination is in fact a neighbor (i.e., on-link).  The latter is
   accomplished by having the ICMP Target Address be equal to the ICMP
   Destination Address.
ToP   noToC   RFC2461 - Page 71
   A router MUST be able to determine the link-local address for each of
   its neighboring routers in order to ensure that the target address in
   a Redirect message identifies the neighbor router by its link-local
   address.  For static routing this requirement implies that the next-
   hop router's address should be specified using the link-local address
   of the router.  For dynamic routing this requirement implies that all
   IPv6 routing protocols must somehow exchange the link-local addresses
   of neighboring routers.

8.1.  Validation of Redirect Messages

   A host MUST silently discard any received Redirect message that does
   not satisfy all of the following validity checks:

      - IP Source Address is a link-local address.  Routers must use
        their link-local address as the source for Router Advertisement
        and Redirect messages so that hosts can uniquely identify
        routers.

      - The IP Hop Limit field has a value of 255, i.e., the packet
        could not possibly have been forwarded by a router.

      - If the message includes an IP Authentication Header, the message
        authenticates correctly.

      - ICMP Checksum is valid.

      - ICMP Code is 0.

      - ICMP length (derived from the IP length) is 40 or more octets.

      - The IP source address of the Redirect is the same as the current
        first-hop router for the specified ICMP Destination Address.

      - The ICMP Destination Address field in the redirect message does
        not contain a multicast address.

      - The ICMP Target Address is either a link-local address (when
        redirected to a router) or the same as the ICMP Destination
        Address (when redirected to the on-link destination).

      - All included options have a length that is greater than zero.

   The contents of the Reserved field, and of any unrecognized options
   MUST be ignored.  Future, backward-compatible changes to the protocol
   may specify the contents of the Reserved field or add new options;
   backward-incompatible changes may use different Code values.
ToP   noToC   RFC2461 - Page 72
   The contents of any defined options that are not specified to be used
   with Redirect messages MUST be ignored and the packet processed as
   normal.  The only defined options that may appear are the Target
   Link-Layer Address option and the Redirected Header option.

   A host MUST NOT consider a redirect invalid just because the Target
   Address of the redirect is not covered under one of the link's
   prefixes.  Part of the semantics of the Redirect message is that the
   Target Address is on-link.

   A redirect that passes the validity checks is called a "valid
   redirect".

8.2.  Router Specification

   A router SHOULD send a redirect message, subject to rate limiting,
   whenever it forwards a packet that is not explicitly addressed to
   itself (i.e. a packet that is not source routed through the router)
   in which:

      - the Source Address field of the packet identifies a neighbor,
        and

      - the router determines that a better first-hop node resides on
        the same link as the sending node for the Destination Address of
        the packet being forwarded, and

      - the Destination Address of the packet is not a multicast
        address, and

   The transmitted redirect packet contains, consistent with the message
   format given in Section 4.5:

      - In the Target Address field: the address to which subsequent
        packets for the destination SHOULD be sent.  If the target is a
        router, that router's link-local address MUST be used.  If the
        target is a host the target address field MUST be set to the
        same value as the Destination Address field.

      - In the Destination Address field: the destination address of the
        invoking IP packet.

      - In the options:

           o Target Link-Layer Address option: link-layer address of the
             target, if known.
ToP   noToC   RFC2461 - Page 73
           o Redirected Header: as much of the forwarded packet as can
             fit without the redirect packet exceeding 1280 octets in
             size.

   A router MUST limit the rate at which Redirect messages are sent, in
   order to limit the bandwidth and processing costs incurred by the
   Redirect messages when the source does not correctly respond to the
   Redirects, or the source chooses to ignore unauthenticated Redirect
   messages.  More details on the rate-limiting of ICMP error messages
   can be found in [ICMPv6].

   A router MUST NOT update its routing tables upon receipt of a
   Redirect.

8.3.  Host Specification

   A host receiving a valid redirect SHOULD update its Destination Cache
   accordingly so that subsequent traffic goes to the specified target.
   If no Destination Cache entry exists for the destination, an
   implementation SHOULD create such an entry.

   If the redirect contains a Target Link-Layer Address option the host
   either creates or updates the Neighbor Cache entry for the target.
   In both cases the cached link-layer address is copied from the Target
   Link-Layer Address option.  If a Neighbor Cache entry is created for
   the target its reachability state MUST be set to STALE as specified
   in Section 7.3.3.  If a cache entry already existed and it is updated
   with a different link-layer address, its reachability state MUST also
   be set to STALE.  If the link-layer address is the same as that
   already in the cache, the cache entry's state remains unchanged.

   If the Target and Destination Addresses are the same, the host MUST
   treat the Target as on-link.  If the Target Address is not the same
   as the Destination Address, the host MUST set IsRouter to TRUE for
   the target.  If the Target and Destination Addresses are the same,
   however, one cannot reliably determine whether the Target Address is
   a router.  Consequently, newly created Neighbor Cache entries should
   set the IsRouter flag to FALSE, while existing cache entries should
   leave the flag unchanged.  If the Target is a router, subsequent
   Neighbor Advertisement or Router Advertisement messages will update
   IsRouter accordingly.

   Redirect messages apply to all flows that are being sent to a given
   destination.  That is, upon receipt of a Redirect for a Destination
   Address, all Destination Cache entries to that address should be
   updated to use the specified next-hop, regardless of the contents of
   the Flow Label field that appears in the Redirected Header option.
ToP   noToC   RFC2461 - Page 74
   A host MAY have a configuration switch that can be set to make it
   ignore a Redirect message that does not have an IP Authentication
   header.

   A host MUST NOT send Redirect messages.

9.  EXTENSIBILITY - OPTION PROCESSING

   Options provide a mechanism for encoding variable length fields,
   fields that may appear multiple times in the same packet, or
   information that may not appear in all packets.  Options can also be
   used to add additional functionality to future versions of ND.

   In order to ensure that future extensions properly coexist with
   current implementations, all nodes MUST silently ignore any options
   they do not recognize in received ND packets and continue processing
   the packet.  All options specified in this document MUST be
   recognized.  A node MUST NOT ignore valid options just because the ND
   message contains unrecognized ones.

   The current set of options is defined in such a way that receivers
   can process multiple options in the same packet independently of each
   other.  In order to maintain these properties future options SHOULD
   follow the simple rule:

        The option MUST NOT depend on the presence or absence of any
        other options.  The semantics of an option should depend only on
        the information in the fixed part of the ND packet and on the
        information contained in the option itself.

   Adhering to the above rule has the following benefits:

     1) Receivers can process options independently of one another.  For
        example, an implementation can choose to process the Prefix
        Information option contained in a Router Advertisement message
        in a user-space process while the link-layer address option in
        the same message is processed by routines in the kernel.

     2) Should the number of options cause a packet to exceed a link's
        MTU, multiple packets can carry subsets of the options without
        any change in semantics.

     3) Senders MAY send a subset of options in different packets.  For
        instance, if a prefix's Valid and Preferred Lifetime are high
        enough, it might not be necessary to include the Prefix
        Information option in every Router Advertisement.  In addition,
        different routers might send different sets of options.  Thus, a
        receiver MUST NOT associate any action with the absence of an
ToP   noToC   RFC2461 - Page 75
        option in a particular packet.  This protocol specifies that
        receivers should only act on the expiration of timers and on the
        information that is received in the packets.

   Options in Neighbor Discovery packets can appear in any order;
   receivers MUST be prepared to process them independently of their
   order.  There can also be multiple instances of the same option in a
   message (e.g., Prefix Information options).

   If the number of included options in a Router Advertisement causes
   the advertisement's size to exceed the link MTU, the router can send
   multiple separate advertisements each containing a subset of the
   options.

   The amount of data to include in the Redirected Header option MUST be
   limited so that the entire redirect packet does not exceed 1280
   octets.

   All options are a multiple of 8 octets of length, ensuring
   appropriate alignment without any "pad" options.  The fields in the
   options (as well as the fields in ND packets) are defined to align on
   their natural boundaries (e.g., a 16-bit field is aligned on a 16-bit
   boundary) with the exception of the 128-bit IP addresses/prefixes,
   which are aligned on a 64-bit boundary.  The link-layer address field
   contains an uninterpreted octet string; it is aligned on an 8-bit
   boundary.

   The size of an ND packet including the IP header is limited to the
   link MTU (which is at least 1280 octets).  When adding options to an
   ND packet a node MUST NOT exceed the link MTU.

   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.

10.  PROTOCOL CONSTANTS

   Router constants:

            MAX_INITIAL_RTR_ADVERT_INTERVAL  16 seconds

            MAX_INITIAL_RTR_ADVERTISEMENTS    3 transmissions

            MAX_FINAL_RTR_ADVERTISEMENTS      3 transmissions

            MIN_DELAY_BETWEEN_RAS             3 seconds

            MAX_RA_DELAY_TIME                 .5 seconds
ToP   noToC   RFC2461 - Page 76
   Host constants:

            MAX_RTR_SOLICITATION_DELAY        1 second

            RTR_SOLICITATION_INTERVAL         4 seconds

            MAX_RTR_SOLICITATIONS             3 transmissions

   Node constants:

            MAX_MULTICAST_SOLICIT             3 transmissions

            MAX_UNICAST_SOLICIT               3 transmissions

            MAX_ANYCAST_DELAY_TIME            1 second

            MAX_NEIGHBOR_ADVERTISEMENT        3 transmissions

            REACHABLE_TIME               30,000 milliseconds

            RETRANS_TIMER                 1,000 milliseconds

            DELAY_FIRST_PROBE_TIME            5 seconds

            MIN_RANDOM_FACTOR                 .5

            MAX_RANDOM_FACTOR                 1.5

   Additional protocol constants are defined with the message formats in
   Section 4.

   All protocol constants are subject to change in future revisions of
   the protocol.

   The constants in this specification may be overridden by specific
   documents that describe how IPv6 operates over different link layers.
   This rule allows Neighbor Discovery to operate over links with widely
   varying performance characteristics.

11.  SECURITY CONSIDERATIONS

   Neighbor Discovery is subject to attacks that cause IP packets to
   flow to unexpected places.  Such attacks can be used to cause denial
   of service but also allow nodes to intercept and optionally modify
   packets destined for other nodes.
ToP   noToC   RFC2461 - Page 77
   The protocol reduces the exposure to such threats in the absence of
   authentication by ignoring ND packets received from off-link senders.
   The Hop Limit field of all received packets is verified to contain
   255, the maximum legal value.  Because routers decrement the Hop
   Limit on all packets they forward, received packets containing a Hop
   Limit of 255 must have originated from a neighbor.

   An example of denial of service attacks is that a node on the link
   that can send packets with an arbitrary IP source address can both
   advertise itself as a default router and also send "forged" Router
   Advertisement messages that immediately time out all other default
   routers as well as all on-link prefixes.  An intruder can achieve
   this by sending out multiple Router Advertisements, one for each
   legitimate router, with the source address set to the address of
   another router, the Router Lifetime field set to zero, and the
   Preferred and Valid lifetimes set to zero for all the prefixes.  Such
   an attack would cause all packets, for both on-link and off-link
   destinations, to go to the rogue router.  That router can then
   selectively examine, modify or drop all packets sent on the link. The
   Neighbor Unreachability Detection will not detect such a black hole
   as long as the rogue router politely answers the NUD probes with a
   Neighbor Advertisement with the R-bit set.

   Many link layers are also subject to different denial of service
   attacks such as continuously occupying the link in CSMA/CD networks
   (e.g., by sending packets closely back-to-back or asserting the
   collision signal on the link), or originating packets with somebody
   else's source MAC address to confuse, e.g., Ethernet switches.

   The trust model for redirects is the same as in IPv4.  A redirect is
   accepted only if received from the same router that is currently
   being used for that destination.  It is natural to trust the routers
   on the link.  If a host has been redirected to another node (i.e.,
   the destination is on-link) there is no way to prevent the target
   from issuing another redirect to some other destination.  However,
   this exposure is no worse than it was; the target host, once
   subverted, could always act as a hidden router to forward traffic
   elsewhere.

   The protocol contains no mechanism to determine which neighbors are
   authorized to send a particular type of message (e.g., Router
   Advertisements); any neighbor, presumably even in the presence of
   authentication, can send Router Advertisement messages thereby being
   able to cause denial of service.  Furthermore, any neighbor can send
   proxy Neighbor Advertisements as well as unsolicited Neighbor
   Advertisements as a potential denial of service attack.
ToP   noToC   RFC2461 - Page 78
   Neighbor Discovery protocol packet exchanges can be authenticated
   using the IP Authentication Header [IPv6-AUTH].  A node SHOULD
   include an Authentication Header when sending Neighbor Discovery
   packets if a security association for use with the IP Authentication
   Header exists for the destination address.  The security associations
   may have been created through manual configuration or through the
   operation of some key management protocol.

   Received Authentication Headers in Neighbor Discovery packets MUST be
   verified for correctness and packets with incorrect authentication
   MUST be ignored.

   It SHOULD be possible for the system administrator to configure a
   node to ignore any Neighbor Discovery messages that are not
   authenticated using either the Authentication Header or Encapsulating
   Security Payload.  The configuration technique for this MUST be
   documented.  Such a switch SHOULD default to allowing unauthenticated
   messages.

   Confidentiality issues are addressed by the IP Security Architecture
   and the IP Encapsulating Security Payload documents [IPv6-SA, IPv6-
   ESP].

12.  RENUMBERING CONSIDERATIONS

   The Neighbor Discovery protocol together with IPv6 Address
   Autoconfiguration [ADDRCONF] provides mechanisms to aid in
   renumbering - new prefixes and addresses can be introduced and old
   ones can be deprecated and removed.

   The robustness of these mechanisms is based on all the nodes on the
   link receiving the Router Advertisement messages in a timely manner.
   However, a host might be turned off or be unreachable for an extended
   period of time (i.e., a machine is powered down for months after a
   project terminates).  It is possible to preserve robust renumbering
   in such cases but it does place some constraints on how long prefixes
   must be advertised.

   Consider the following example in which a prefix is initially
   advertised with a lifetime of 2 months, but on August 1st it is
   determined that the prefix needs to be deprecated and removed due to
   renumbering by September 1st.  This can be done by reducing the
   advertised lifetime to 1 week starting on August 1st and as the
   cutoff gets closer the lifetimes can be made shorter until by
   September 1st the prefix is advertised with a zero lifetime.  The
   point is that, if one or more nodes were unplugged from the link
   prior to September 1st they might still think that the prefix is
   valid since the last lifetime they received was 2 months.  Thus if a
ToP   noToC   RFC2461 - Page 79
   node was unplugged on July 31st it thinks the prefix is valid until
   September 30th.  If that node is plugged back in prior to September
   30th it may continue to use the old prefix.  The only way to force a
   node to stop using a prefix that was previously advertised with a
   long Lifetime is to have that node receive an advertisement for that
   prefix that changes the lifetime downward.  The solution in this
   example is simple: continue advertising the prefix with a lifetime of
   0 from September 1st until October 1st.

   In general, in order to be robust against nodes that might be
   unplugged from the link it is important to track the furthest into
   the future a particular prefix can be viewed valid by any node on the
   link.  The prefix must then be advertised with a 0 Lifetime until
   that point in future. This "furthest into the future" time is simply
   the maximum, over all Router Advertisements, of the time the
   advertisement was sent plus the prefix's Lifetime contained in the
   advertisement.

   The above has an important implication on using infinite lifetimes.
   If a prefix is advertised with an infinite lifetime, and that prefix
   later needs to be renumbered, it is undesirable to continue
   advertising that prefix with a zero lifetime forever.  Thus either
   infinite lifetimes should be avoided or there must be a limit on how
   long time a node can be unplugged from the link before it is plugged
   back in again.  However, it is unclear how the network administrator
   can enforce a limit on how long time hosts such as laptops can be
   unplugged from the link.

   Network administrators should give serious consideration to using
   relatively short lifetimes (i.e., no more than a few weeks).  While
   it might appear that using long lifetimes would help insure
   robustness, in reality a host will be unable to communicate in the
   absence of properly functioning routers.  Such routers will be
   sending Router Advertisements that contain appropriate (and current)
   prefixes.  A host connected to a network that has no functioning
   routers is likely to have more serious problems than just a lack of a
   valid prefix and address.

   The above discussion does not distinguish between the preferred and
   valid lifetimes.  For all practical purposes it is probably
   sufficient to track the valid lifetime since the preferred lifetime
   will not exceed the valid lifetime.
ToP   noToC   RFC2461 - Page 80
REFERENCES

   [ADDRCONF]   Thomson, S. and T. Narten, "IPv6 Address
                Autoconfiguration", RFC 2462, December 1998.

   [ADDR-ARCH]  Hinden, R. and S. Deering, "IP Version 6 Addressing
                Architecture", RFC 2373, July 1998.

   [ANYCST]     Partridge, C., Mendez, T. and W. Milliken, "Host
                Anycasting Service", RFC 1546, November 1993.

   [ARP]        Plummer, D., "An Ethernet Address Resolution Protocol",
                STD 37, RFC 826, November 1982.

   [HR-CL]      Braden, R., Editor, "Requirements for Internet Hosts --
                Communication Layers", STD 3, RFC 1122, October 1989.

   [ICMPv4]     Postel, J., "Internet Control Message Protocol", STD 5,
                RFC 792, September 1981.

   [ICMPv6]     Conta, A. and S. Deering, "Internet Control Message
                Protocol (ICMPv6) for the Internet Protocol Version 6
                (IPv6) Specification", RFC 2463, December 1998.

   [IPv6]       Deering, S. and R. Hinden, "Internet Protocol, Version 6
                (IPv6) Specification", RFC 2460, December 1998.

   [IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over
                Ethernet Networks", RFC 2464, December 1998.

   [IPv6-SA]    Kent, S. and R. Atkinson, "Security Architecture for the
                Internet Protocol", RFC 2401, November 1998.

   [IPv6-AUTH]  Kent, S. and R. Atkinson, "IP Authentication Header",
                RFC 2402, November 1998.

   [IPv6-ESP]   Kent, S. and R. Atkinson, "IP Encapsulating Security
                Payload (ESP)", RFC 2406, November 1998.

   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RDISC]      Deering, S., "ICMP Router Discovery Messages", RFC 1256,
                September 1991.

   [SH-MEDIA]   Braden, R., Postel, J. and Y. Rekhter, "Internet
                Architecture Extensions for Shared Media", RFC 1620, May
                1994.
ToP   noToC   RFC2461 - Page 81
   [ASSIGNED]   Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", STD 2,
                RFC 1700, October 1994. See also:
                http://www.iana.org/numbers.html

   [SYNC]       S. Floyd, V. Jacobson, "The Synchronization of Periodic
                Routing Messages", IEEE/ACM Transactions on Networking,
                April 1994.  ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z

Authors' Addresses

   Thomas Narten
   IBM Corporation
   P.O. Box 12195
   Research Triangle Park, NC 27709-2195
   USA

   Phone: +1 919 254 7798
   EMail: narten@raleigh.ibm.com


   Erik Nordmark
   Sun Microsystems, Inc.
   901 San Antonio Road
   Palo Alto, CA 94303
   USA

   Phone: +1 650 786 5166
   Fax:   +1 650 786 5896
   EMail: nordmark@sun.com


   William Allen Simpson
   Daydreamer
   Computer Systems Consulting Services
   1384 Fontaine
   Madison Heights, Michigan  48071
   USA

   EMail: Bill.Simpson@um.cc.umich.edu
          bsimpson@MorningStar.com
ToP   noToC   RFC2461 - Page 82
APPENDIX A: MULTIHOMED HOSTS

   There are a number of complicating issues that arise when Neighbor
   Discovery is used by hosts that have multiple interfaces.  This
   section does not attempt to define the proper operation of multihomed
   hosts with regard to Neighbor Discovery.  Rather, it identifies
   issues that require further study.  Implementors are encouraged to
   experiment with various approaches to making Neighbor Discovery work
   on multihomed hosts and to report their experiences.

   If a multihomed host receives Router Advertisements on all of its
   interfaces, it will (probably) have learned on-link prefixes for the
   addresses residing on each link.  When a packet must be sent through
   a router, however, selecting the "wrong" router can result in a
   suboptimal or non-functioning path.  There are number of issues to
   consider:

     1) In order for a router to send a redirect, it must determine that
        the packet it is forwarding originates from a neighbor.  The
        standard test for this case is to compare the source address of
        the packet to the list of on-link prefixes associated with the
        interface on which the packet was received.  If the originating
        host is multihomed, however, the source address it uses may
        belong to an interface other than the interface from which it
        was sent.  In such cases, a router will not send redirects, and
        suboptimal routing is likely.  In order to be redirected, the
        sending host must always send packets out the interface
        corresponding to the outgoing packet's source address.  Note
        that this issue never arises with non-multihomed hosts; they
        only have one interface.

     2) If the selected first-hop router does not have a route at all
        for the destination, it will be unable to deliver the packet.
        However, the destination may be reachable through a router on
        one of the other interfaces.  Neighbor Discovery does not
        address this scenario; it does not arise in the non-multihomed
        case.

     3) Even if the first-hop router does have a route for a
        destination, there may be a better route via another interface.
        No mechanism exists for the multihomed host to detect this
        situation.

   If a multihomed host fails to receive Router Advertisements on one or
   more of its interfaces, it will not know (in the absence of
   configured information) which destinations are on-link on the
   affected interface(s).  This leads to a number of problems:
ToP   noToC   RFC2461 - Page 83
     1) If no Router Advertisement is received on any interfaces, a
        multihomed host will have no way of knowing which interface to
        send packets out on, even for on-link destinations.  Under
        similar conditions in the non-multihomed host case, a node
        treats all destinations as residing on-link, and communication
        proceeds.  In the multihomed case, however, additional
        information is needed to select the proper outgoing interface.
        Alternatively, a node could attempt to perform address
        resolution on all interfaces, a step involving significant
        complexity that is not present in the non-multihomed host case.

     2) If Router Advertisements are received on some, but not all
        interfaces, a multihomed host could choose to only send packets
        out on the interfaces on which it has received Router
        Advertisements.  A key assumption made here, however, is that
        routers on those other interfaces will be able to route packets
        to the ultimate destination, even when those destinations reside
        on the subnet to which the sender connects, but has no on-link
        prefix information.  Should the assumption be FALSE,
        communication would fail.  Even if the assumption holds, packets
        will traverse a sub-optimal path.
ToP   noToC   RFC2461 - Page 84
APPENDIX B: FUTURE EXTENSIONS

   Possible extensions for future study are:

    o Using dynamic timers to be able to adapt to links with widely
      varying delay.  Measuring round trip times, however, requires
      acknowledgments and sequence numbers in order to match received
      Neighbor Advertisements with the actual Neighbor Solicitation that
      triggered the advertisement.  Implementors wishing to experiment
      with such a facility could do so in a backwards-compatible way by
      defining a new option carrying the necessary information.  Nodes
      not understanding the option would simply ignore it.

    o Adding capabilities to facilitate the operation over links that
      currently require hosts to register with an address resolution
      server.  This could for instance enable routers to ask hosts to
      send them periodic unsolicited advertisements.  Once again this
      can be added using a new option sent in the Router Advertisements.

    o Adding additional procedures for links where asymmetric and non-
      transitive reachability is part of normal operations.  Such
      procedures might allow hosts and routers to find usable paths on,
      e.g., radio links.
ToP   noToC   RFC2461 - Page 85
APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE

   This appendix contains a summary of the rules specified in Sections
   7.2 and 7.3.  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.

   When performing address resolution and Neighbor Unreachability
   Detection the following state transitions apply using the conceptual
   model:

State           Event                   Action                New state

-               Packet to send.         Create entry.         INCOMPLETE
                                        Send multicast NS.
                                        Start retransmit timer

INCOMPLETE      Retransmit timeout,     Retransmit NS         INCOMPLETE
                less than N             Start retransmit timer
                retransmissions.

INCOMPLETE      Retransmit timeout,     Discard entry         -
                N or more               Send ICMP error
                retransmissions.

INCOMPLETE      NA, Solicited=0,        Record link-layer     STALE
                Override=any            address.  Send queued
                                        packets.

INCOMPLETE      NA, Solicited=1,        Record link-layer     REACHABLE
                Override=any            address.  Send queued
                                        packets.

!INCOMPLETE     NA, Solicited=1,        -                     REACHABLE
                Override=0
                Same link-layer
                address as cached.

REACHABLE       NA, Solicited=1,        -                     STALE
                Override=0
                Different link-layer
                address than cached.

STALE or PROBE  NA, Solicited=1,        -                     unchanged
                Override=0
                Different link-layer
                address than cached.
ToP   noToC   RFC2461 - Page 86
!INCOMPLETE     NA, Solicited=1,        Record link-layer     REACHABLE
                Override=1              address (if
                                        different).

!INCOMPLETE     NA, Solicited=0,        -                     unchanged
                Override=0

!INCOMPLETE     NA, Solicited=0,        -                     unchanged
                Override=1
                Same link-layer
                address as cached.

!INCOMPLETE     NA, Solicited=0,        Record link-layer     STALE
                Override=1              address.
                Different link-layer
                address than cached.

!INCOMPLETE     upper-layer reachability  -                   REACHABLE
                confirmation

REACHABLE       timeout, more than      -                     STALE
                N seconds since
                reachability confirm.

STALE           Sending packet          Start delay timer     DELAY

DELAY           Delay timeout           Send unicast NS probe PROBE
                                        Start retransmit timer

PROBE           Retransmit timeout,     Retransmit NS         PROBE
                less than N
                retransmissions.

PROBE           Retransmit timeout,     Discard entry         -
                N or more
                retransmissions.
ToP   noToC   RFC2461 - Page 87
   The state transitions for receiving unsolicited information other
   than Neighbor Advertisement messages apply to either the source of
   the packet (for Neighbor Solicitation, Router Solicitation, and
   Router Advertisement messages) or the target address (for Redirect
   messages) as follows:

State           Event                   Action                New state

-               NS, RS, RA, Redirect    Create entry.         STALE

INCOMPLETE      NS, RS, RA, Redirect    Record link-layer     STALE
                                        address.  Send queued
                                        packets.

!INCOMPLETE     NS, RS, RA, Redirect    Update link-layer     STALE
                Different link-layer    address
                address than cached.

!INCOMPLETE     NS, RS, RA, Redirect    -                     unchanged
                Same link-layer
                address as cached.
ToP   noToC   RFC2461 - Page 88
APPENDIX D: SUMMARY OF ISROUTER RULES

   This appendix presents a summary of the rules for maintaining the
   IsRouter flag as specified in this document.

   The background for these rules is that the ND messages contain,
   either implicitly or explicitly, information that indicates whether
   or not the sender (or Target Address) is a host or a router.  The
   following assumptions are used:

    - The sender of a Router Solicitation is implicitly assumed to be a
      host since there is no need for routers to send such messages.

    - The sender of a Router Advertisement is implicitly assumed to be a
      router.

    - Neighbor Solicitation messages do not contain either an implicit
      or explicit indication about the sender.  Both hosts and routers
      send such messages.

      - Neighbor Advertisement messages contain an explicit "IsRouter
      flag", the R-bit.

    - The target of the redirect, when the target differs from the
      destination address in the packet being redirected, is implicitly
      assumed to be a router.  This is a natural assumption since that
      node is expected to be able to forward the packets towards the
      destination.

    - The target of the redirect, when the target is the same as the
      destination, does not carry any host vs. router information.  All
      that is known is that the destination (i.e. target) is on-link but
      it could be either a host or a router.

   The rules for setting the IsRouter flag are based on the information
   content above.  If an ND message contains explicit or implicit
   information the receipt of the message will cause the IsRouter flag
   to be updated.  But when there is no host vs. router information in
   the ND message the receipt of the message MUST NOT cause a change to
   the IsRouter state.  When the receipt of such a message causes a
   Neighbor Cache entry to be created this document specifies that the
   IsRouter flag be set to FALSE.  There is greater potential for
   mischief when a node incorrectly thinks a host is a router, than the
   other way around.  In these cases a subsequent Neighbor Advertisement
   or Router Advertisement message will set the correct IsRouter value.
ToP   noToC   RFC2461 - Page 89
APPENDIX E: IMPLEMENTATION ISSUES

Appendix E.1: Reachability confirmations

   Neighbor Unreachability Detection requires explicit confirmation that
   a forward-path is functioning properly.  To avoid the need for
   Neighbor Solicitation probe messages, upper layer protocols should
   provide such an indication when the cost of doing so is small.
   Reliable connection-oriented protocols such as TCP are generally
   aware when the forward-path is working.  When TCP sends (or receives)
   data, for instance, it updates its window sequence numbers, sets and
   cancels retransmit timers, etc.  Specific scenarios that usually
   indicate a properly functioning forward-path include:

    - Receipt of an acknowledgement that covers a sequence number (e.g.,
      data) not previously acknowledged indicates that the forward path
      was working at the time the data was sent.

    - Completion of the initial three-way handshake is a special case of
      the previous rule; although no data is sent during the handshake,
      the SYN flags are counted as data from the sequence number
      perspective.  This applies to both the SYN+ACK for the active open
      the ACK of that packet on the passively opening peer.

    - Receipt of new data (i.e., data not previously received) indicates
      that the forward-path was working at the time an acknowledgement
      was sent that advanced the peer's send window that allowed the new
      data to be sent.

   To minimize the cost of communicating reachability information
   between the TCP and IP layers, an implementation may wish to rate-
   limit the reachability confirmations its sends IP.  One possibility
   is to process reachability only every few packets.  For example, one
   might update reachability information once per round trip time, if an
   implementation only has one round trip timer per connection.  For
   those implementations that cache Destination Cache entries within
   control blocks, it may be possible to update the Neighbor Cache entry
   directly (i.e., without an expensive lookup) once the TCP packet has
   been demultiplexed to its corresponding control block.  For other
   implementation it may be possible to piggyback the reachability
   confirmation on the next packet submitted to IP assuming that the
   implementation guards against the piggybacked confirmation becoming
   stale when no packets are sent to IP for an extended period of time.

   TCP must also guard against thinking "stale" information indicates
   current reachability.  For example, new data received 30 minutes
   after a window has opened up does not constitute a confirmation that
   the path is currently working.  In merely indicates that 30 minutes
ToP   noToC   RFC2461 - Page 90
   ago the window update reached the peer i.e. the path was working at
   that point in time.  An implementation must also take into account
   TCP zero-window probes that are sent even if the path is broken and
   the window update did not reach the peer.

   For UDP based applications (RPC, DNS) it is relatively simple to make
   the client send reachability confirmations when the response packet
   is received.  It is more difficult and in some cases impossible for
   the server to generate such confirmations since there is no flow
   control, i.e., the server can not determine whether a received
   request indicates that a previous response reached the client.

   Note that an implementation can not use negative upper-layer advise
   as a replacement for the Neighbor Unreachability Detection algorithm.
   Negative advise (e.g. from TCP when there are excessive
   retransmissions) could serve as a hint that the forward path from the
   sender of the data might not be working.  But it would fail to detect
   when the path from the receiver of the data is not functioning
   causing, none of the acknowledgement packets to reach the sender.
ToP   noToC   RFC2461 - Page 91
APPENDIX F: CHANGES SINCE RFC 1970

    o Removed all references to the IPv6 priority field.

    o Replaced definition of solicited node multicast address with a
      reference to the [ADDR-ARCH] specification.  That specification
      says that "the solicited-node multicast address is formed by
      taking the low-order 24 bits of the address (unicast or anycast)
      and appending those bits to the prefix FF02:0:0:0:0:1:FF00::/104".

    o Updated the references section to list (new) RFC numbers.

    o Updated the text in section 7.2.5 and the tables in appendix C to
      have the receipt of an NS message update the state of an existing
      neighbor cache entry only if the link-layer address is different
      than the recorded link-layer address.

    o Added an explicit check in section 7.1.1 so that received NS
      messages from an unsolicited address must be sent the solicited-
      node multicast address; if sent to unicast destination, silently
      discard.

    o Added a requirement in section 6.2.1 that Lifetimes be
      configurable in either of two ways: as a fixed value that doesn't
      change over time, or one that decrements in real time.

    o Added text in section 6.2.7 to relax the consistency checks on
      prefix lifetimes when the lifetimes are configured to decrement in
      real time.  This is needed to avoid false alarms due to link
      propagation delay and lack of synchronized clocks.

    o Added text to section 6.3.4 to point out that [ADDRCONF] might
      ignore short lifetimes but that Neighbor Discovery does not ignore
      short prefix lifetimes.

    o Clarified the rules for RS and NS packets with an unspecified
      source address. Such packets MUST NOT include source link-layer
      address option; verified by receivers.

    o Clarified in section 7.2.3 that addresses for which the node
      proxies are acceptable in NS messages.  Previously the text only
      mentioned unicast and anycast addresses assigned to the interface
      (i.e., wasn't clear that proxy addresses were allowed).

    o Tightened up ambiguities an inconsistencies regarding when to set
      the IsRouter flag in Neighbor Cache entries.  Added an appendix to
      summarize these rules.
ToP   noToC   RFC2461 - Page 92
    o Added a section on renumbering considerations to clarify how long
      prefixes have to be advertised when the lifetime(s) are reduced.

    o Added additional text to the rules in section 7 for the NS/NA
      packets used for NUD probes so that the Link-Layer Address options
      can be omitted from these packets in certain cases without causing
      an infinite NS "recursion". Specifically, added text that permits
      the Link-Layer address to be omitted in unicast solicitations
      (i.e., MAY language).

    o Changed the default AdvValidLifetime from infinity to 30 days.

    o Changed the constant "576" to "1280" in places where its context
      was that of the minimum sized IP packet that all links must be
      able to carry.
ToP   noToC   RFC2461 - Page 93
Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.