[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 1970

INTERNET-DRAFT                                        Thomas Narten, IBM
June 7, 1995                             Erik Nordmark, Sun Microsystems
                                                 W A Simpson, Daydreamer



                        IPv6 Neighbor Discovery

                  <draft-ietf-ipngwg-discovery-00.txt>


Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet- Drafts
   Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

   Distribution of this memo is unlimited.

   This Internet Draft expires December 1, 1995.



Abstract

   This document specifies the Neighbor Discovery protocol for the IP
   Version 6 protocol.  IPv6 nodes on a single link use Neighbor
   Discovery to discover each other's presence and to determine each
   other's link-layer addresses.










draft-ietf-ipngwg-discovery-00.txt                              [Page 1]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


Contents

   Status of this Memo.......................................    1

   1.  INTRODUCTION..........................................    3

   2.  TERMINOLOGY...........................................    4

   3.  PROTOCOL OVERVIEW.....................................    7
      3.1.  Comparison with IPv4.............................   11
      3.2.  Supported Link Types.............................   12

   4.  CONCEPTUAL MODEL OF A HOST............................   13
      4.1.  Conceptual Data Structures.......................   13
      4.2.  Conceptual Sending Algorithm.....................   15
      4.3.  Garbage Collection and Timeout Requirements......   16

   5.  ROUTER AND PREFIX DISCOVERY...........................   17
      5.1.  Message Formats..................................   17
         5.1.1.  Router Solicitation Message Format..........   17
         5.1.2.  Router Advertisement Message Format.........   19
      5.2.  Router Specification.............................   20
         5.2.1.  Router Configuration Variables..............   21
         5.2.2.  Message Validation by Routers...............   22
         5.2.3.  Router Behavior.............................   23
         5.2.4.  Designated Addresses........................   26
      5.3.  Host Specification...............................   26
         5.3.1.  Host Configuration Variables................   26
         5.3.2.  Message Validation by Hosts.................   26
         5.3.3.  Host Behavior...............................   27

   6.  ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION   31
      6.1.  Message Formats..................................   31
         6.1.1.  Neighbor Solicitation Message Format........   31
         6.1.2.  Neighbor Advertisement Message Format.......   32
      6.2.  Address Resolution...............................   34
         6.2.1.  Message Validation by Nodes.................   34
         6.2.2.  Node Specification..........................   35
         6.2.3.  Sending Node Specification..................   35
         6.2.4.  Target Node Specification...................   37
         6.2.5.  Anticipated link-layer address changes......   38
         6.2.6.  Proxy Neighbor Advertisements...............   38
         6.2.7.  Anycast.....................................   39
      6.3.  Neighbor Unreachability Detection................   39
         6.3.1.  Reachability Confirmation...................   40
         6.3.2.  Node behavior...............................   41
         6.3.3.  Reachability State..........................   42
         6.3.4.  Algorithm...................................   43



draft-ietf-ipngwg-discovery-00.txt                              [Page 2]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


   7.  REDIRECT FUNCTION.....................................   44
      7.1.  Redirect Message Format..........................   44
      7.2.  Router Specification.............................   46
      7.3.  Host Specification...............................   47
         7.3.1.  Message Validation by Hosts.................   47
         7.3.2.  Host Behavior...............................   48

   8.  EXTENSIONS............................................   49
      8.1.  Source/Target Link-layer Address.................   51
      8.2.  Prefix Information...............................   52
      8.3.  Redirected Header................................   53
      8.4.  Suggested Hop Limit..............................   54
      8.5.  Neighbor Unreachability Detection Timer..........   54
      8.6.  MTU..............................................   55

   9.  MULTIHOMED HOSTS......................................   56

   10.  PROTOCOL CONSTANTS...................................   57

   11.  SECURITY CONSIDERATIONS..............................   57

   REFERENCES................................................   59

   AUTHORS' ADDRESSES........................................   60

   CHANGES SINCE PREVIOUS DOCUMENT...........................   61

   OPEN ISSUES...............................................   63






1.  INTRODUCTION

This specification defines the Neighbor Discovery (ND) protocol for the
IP Version 6 protocol.  Nodes (hosts and routers) use Neighbor Discovery
to determine the link-layer address for neighbors known to reside on
attached links and to quickly learn new link-layer addresses should
cached values become invalid.  Hosts also use Neighbor Discovery to find
neighboring routers that are willing to forward packets on their behalf.
Finally, nodes use the protocol to actively keep track of which
neighbors are reachable and which are not, and to detect changed link-
layer addresses.  Sending hosts also detect when routers fail and
actively search for functioning alternates.

This document is a new revision of the protocol specified in the two



draft-ietf-ipngwg-discovery-00.txt                              [Page 3]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


documents:
     <draft-simpson-ipv6-discov-formats-02.txt>, and
     <draft-simpson-ipv6-discov-process-02.txt>

The authors would like to acknowledge the contributions of (in
alphabetical order) Ran Atkinson, Scott Bradner, Stephen Deering, Robert
Hinden, Allison Mankin, Dan McDonald, and Sue Thomson.


2.  TERMINOLOGY

   node        - a device that implements IPv6.

   router      - a node that forwards IPv6 packets not explicitly
                 addressed to itself.

   host        - any node that is not a router.

   upper layer - a protocol layer immediately above IPv6.  Examples are
                 transport protocols such as TCP and UDP, control
                 protocols such as ICMP, routing protocols such as OSPF,
                 and internet or lower-layer protocols being "tunneled"
                 over (i.e., encapsulated in) IPv6 such as IPX,
                 AppleTalk, or IPv6 itself.

   link        - a communication facility or medium over which nodes can
                 communicate at the link layer, i.e., the layer
                 immediately below IPv6.  Examples are Ethernets (simple
                 or bridged); PPP links; X.25, Frame Relay, or ATM
                 networks; and internet (or higher) layer "tunnels",
                 such as tunnels over IPv4 or IPv6 itself.

   interface   - a node's attachment to a link.

   neighbors   - nodes attached to the same link.

   on-link     - a destination node that is a neighbor to the sender.  A
                 host considers a destination to be on-link if:
                   - it is covered by one of the link's prefixes, or
                   - a neighboring router specifies the destination as
                     the target of a Redirect message, or
                   - a Neighbor Advertisement message is received from
                     the address, or
                   - a Router Advertisement message is received from the
                     address.


   off-link    - the opposite of "on-link"; a destination node that is



draft-ietf-ipngwg-discovery-00.txt                              [Page 4]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


                 not a neighbor to the sender.

   address     - an IPv6-layer identifier for an interface or a set of
                 interfaces.

   designated address
               - one of an interface's assigned addresses on a router.
                 It is used as the source address in all Neighbor
                 Discovery messages sent from the interface, and
                 neighboring nodes use the address to uniquely identify
                 a router's interface.  The designated address should
                 only change infrequently.

   anycast address
               - an identifier for a set of interfaces (typically
                 belonging to different nodes).  A packet sent to an
                 anycast address is delivered to one of the interfaces
                 identified by that address (the "nearest" one,
                 according to the routing protocols' measure of
                 distance).  See [ADDR-ARCH].

   link-layer address
               - a link-layer identifier for an interface.  Examples are
                 IEEE 802 addresses for Ethernet links, E.164 addresses
                 for ISDN links.

   reachability
               - whether or not two IPv6 nodes can communicate with each
                 other.  For routers reachability means that packets
                 sent by a node's IPv6 layer are delivered to the
                 router's IPv6 layer, and the router is indeed
                 forwarding the packets (i.e. it has not been converted
                 to a host).  For hosts, reachability means that packets
                 sent by a node's IPv6 layer are delivered to the
                 neighbor host's IPv6 layer.  Note that reachability
                 only applies to the "forward" path from one neighbor to
                 another.

   packet      - an IPv6 header plus payload.

   link MTU    - the maximum transmission unit, i.e., maximum packet
                 size in octets, that can be conveyed in one piece over
                 a link.

   target      - a node about which address resolution information is
                 sought, or a node which is the new first-hop when being
                 redirected.




draft-ietf-ipngwg-discovery-00.txt                              [Page 5]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


   proxy       - a router that responds to Neighbor Discovery query
                 messages on behalf of another node.  For instance, a
                 router that is bound to an anycast address will respond
                 on behalf of the anycast address, and potentially a
                 router acting on behalf of a mobile node, that has
                 moved off-link, act as a proxy for the mobile node.


Different link layers have different properties.  The ones of concern to
Neighbor Discovery are:

   point-to-point - a link that has exactly two interfaces.

   multicast      - a link that supports some mechanism at the link
                    layer for sending packets to all (i.e. broadcast) or
                    a subset of all neighbors.  Multicast/broadcast can
                    be provided by a multitude of link layer mechanisms
                    such as the physical link layer itself (for example,
                    Ethernet), replicated unicast packets sent by the
                    link layer software, or multicast servers (such as
                    in ATM).

   non-broadcast multiple access (NBMA)
                  - a link with more than two neighbors that does not
                    support any form of multicast or broadcast (e.g.,
                    Frame Relay).

   shared media   - a link that allows direct communication among a
                    number of nodes, but the nodes do not all share the
                    same IP address prefix, and may not know which nodes
                    are on-link.  Examples are large (switched) public
                    data networks such as SMDS and B-ISDN.  Also known
                    as "large clouds".  See [SH-MEDIA].

   variable MTU   - a link that does not have a well-defined MTU.  For
                    example Token Ring (IEEE 802.5).

   asymmetric connectivity
                  - a link where non-reflexive and/or non-transitive
                    connectivity is part of normal operation.  (Non-
                    reflexive connectivity is when A can hear B but B
                    can't hear A.  Non-transitive connectivity is when A
                    can hear B, and B can hear C, but A can't hear C.)
                    Many radio links exhibit these properties.


Neighbor Discovery makes use of a number of different addresses defined
in [ADDR-ARCH], including:



draft-ietf-ipngwg-discovery-00.txt                              [Page 6]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


   all-nodes multicast address
               - the link scope address to reach all nodes.  FF02::1

   all-routers multicast address
               - the link scope address to reach all routers.  FF02::2

   all-hosts multicast address
               - the link scope address to reach all hosts.  FF02::3

   solicited-node multicast address
               - a multicast address that is computed as a function of
                 the solicited target's address.  The solicited-node
                 multicast address is formed by taking the bit-wise
                 exclusive-or of all octets in the IP address and
                 producing a hash value between 0 and 255.  The hash
                 value is appended to the 15-octet prefix FF02::07,
                 resulting in a multicast address in the range
                 FF02::0700 to FF02::07FF.  For example: the solicited
                 node multicast address corresponding to the IP address
                 4037::01:800:200E:8C6C is FF02::07B0.

   unspecified address
               - the address 0:0:0:0:0:0:0:0 .  It indicates the absence
                 of an address.  One example of its use is in the Source
                 Address field of any IPv6 packets sent by an
                 initializing host before it has learned its own
                 address.



3.  PROTOCOL OVERVIEW

This protocol solves a set of problems related to the interaction
between nodes attached to the same shared link.  It defines mechanisms
for solving each of the following problems:

    Router Discovery: How hosts locate routers that reside on an
               attached link.

    Prefix Discovery: How hosts discover the set of address prefixes
               that define which destinations are on-link for an
               attached link.  (Nodes use prefixes to distinguish
               destinations that reside on-link from those only
               reachable through a router.)

    Address Autoconfiguration: How nodes automatically configure an
               address for an interface.




draft-ietf-ipngwg-discovery-00.txt                              [Page 7]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


    Address Resolution: How nodes determine the link-layer address of a
               neighboring node given only the node's IP address.

    Next-hop determination: The algorithm for mapping an IP destination
               address into the IP address of the neighbor to which
               traffic for the destination should be sent.  The next-hop
               can be a router or the destination.

    Neighbor Unreachability Detection: How nodes determine that a
               neighbor is no longer reachable.  For neighbors used as
               routers, alternate default routers can be tried.  For
               both routers and hosts, Address Resolution can be
               performed again.

    Duplicate Address Detection: How a node detects if another node has
               been configured with the same address.

    Redirect:  How a router informs a host of a better first-hop node to
               reach a particular destination.

Neighbor Discovery defines five different ICMPv6 packet types: A pair of
Router Solicitation and Router Advertisement messages, a pair of
Neighbor Solicitation and Neighbor Advertisements messages, and a
Redirect message.  The messages serve the following purpose:

    Router Solicitation: When an interface becomes enabled, hosts may
               send out Router Solicitations that force routers to
               generate Router Advertisements immediately rather than at
               their next scheduled time.

    Router Advertisement: Routers advertise their presence together with
               various link parameters either periodically, or in
               response to an explicit Router Solicitation message.

    Neighbor Solicitation: Sent by a node to determine the link-layer
               address of a neighbor, or to verify that a neighbor is
               still reachable via a cached link-layer address.
               Neighbor Solicitations can also be used for Duplicate
               Address Detection.

    Neighbor Advertisement: A response to a Neighbor Solicitation
               message.  A node may also send unsolicited Neighbor
               Advertisements to announce a link-layer address change.

    Redirect:  Used by routers to inform hosts of a better first hop for
               a destination.

Each router periodically multicasts a Router Advertisement packet



draft-ietf-ipngwg-discovery-00.txt                              [Page 8]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


announcing its availability.  A host receives Router Advertisements from
all routers, building a prioritized list of routers that can be used as
defaults.  Routers generate Router Advertisements frequently enough that
hosts will learn of their presence within a few minutes, but not
frequently enough to rely on an absence of advertisements to detect
router failure; a separate Neighbor Unreachability Detection algorithm
handles this condition.

Router Advertisements contain a list of on-link prefixes.  Hosts use
advertised prefixes to build and maintain a list of current on-link
prefixes, which are used in deciding when a packet's destination is on-
link or behind a router.  Note that a destination can be on-link even
though it is not covered by any advertised prefixes.  In such cases a
router will send a Redirect informing the sender that the destination is
a neighbor.

Prefix information contained in Router Advertisement messages includes
additional information used by Address Autoconfiguration.  This allows
the routers to specify if hosts should use stateful (DHCPv6) or
autonomous (stateless) address configuration.  The Router Advertisement
messages also specify lifetimes for addresses that are configured using
autonomous address configuration.  The exact semantics and usage of the
address configuration-related information is specified in [ADDRCONF].

Address Resolution is accomplished by multicasting a Neighbor
Solicitation query asking the target node to return its link-layer
address.  Neighbor Solicitation messages are multicast to the
solicited-node multicast address corresponding to the target address.
The target returns its link-layer address in a unicast Neighbor
Advertisement message.  A single request-response pair of packets is
sufficient for both the initiator and the target to resolve each other's
link-layer addresses; the initiator includes its link-layer address in
the Neighbor Solicitation query.

Neighbor Solicitation messages can also be used to determine if another
node has been configured to use a particular address.  The use of
Neighbor Solicitation messages for Duplicate Address Detection is
specified in [ADDRCONF].

Neighbor Unreachability Detection requires positive confirmation that
packets sent to a neighbor are actually reaching that neighbor and being
processed properly by its IPv6 layer.  Neighbor Unreachability Detection
uses confirmation from two sources.  When possible, upper-layer
protocols provide a positive confirmation when a connection is making
"forward progress", that is, previously sent data is known to have been
delivered correctly (e.g., new acknowledgments were received recently).
When positive confirmation is not forthcoming through such "hints", a
node sends explicit unicast Neighbor Solicitation messages that solicit



draft-ietf-ipngwg-discovery-00.txt                              [Page 9]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


Neighbor Advertisement a reachability confirmation from the next hop.
To reduce unnecessary network traffic, probe messages are only sent to
neighbors to which the node is sending packets.

In addition to addressing the above general problems, Neighbor Discovery
also handles the following situations:

     Link-layer address change - A node that knows its link-layer
          address has changed can multicast a few Neighbor Advertisement
          packets to all nodes to quickly (but unreliably) update cached
          link-layer addresses that have become invalid.  The Neighbor
          Unreachability Detection algorithm ensures that all nodes will
          reliably discover the new address, though the delay will be
          somewhat longer.

     Proxy advertisements - A router willing to accept packets on behalf
          of a node that is unable to respond to Neighbor Solicitations
          can issue proxy Neighbor Advertisements.  Proxy advertising is
          currently only defined for use with anycast addresses, but
          could potentially also be used to handle mobile nodes that
          have moved off-link.  However, it is not intended as a general
          mechanism to handle nodes that e.g. do not implement this
          protocol.  Nodes are aware when a proxy is being used, and the
          protocol allows multiple proxies to serve the same target.
          When multiple advertisements are received, rules specify
          precedence and how to break ties.

     Anycast addresses - Anycast addresses identify one of a set of
          routers providing an equivalent service, and multiple routers
          on the same net may be configured to recognize the same
          Anycast address.  A Neighbor Advertisement for an Anycast
          address will, just like other proxy advertisement, contain a
          source IP address that differs from the target address, and
          nodes will process them in the same manner they process other
          proxy advertisements.

     Inbound load balancing - Nodes with replicated interfaces may want
          to load balance the reception of incoming packets across
          multiple network interfaces on the same link.  Routers may
          omit the source link-layer address from Router Advertisement
          packets, forcing neighbors to use Neighbor Solicitation
          messages to learn the link-layer addresses.  Returned Neighbor
          Advertisement messages can then contain different link-layer
          addresses dependent on who issued the query.







draft-ietf-ipngwg-discovery-00.txt                             [Page 10]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


3.1.  Comparison with IPv4

The IPv6 Neighbor Discovery protocol corresponds to a combination of the
IPv4 protocols ARP [ARP], ICMP Router Discovery [RDISC], and ICMP
Redirect [ICMPv4].  In IPv4 there is no generally agreed upon protocol
mechanism for Neighbor Unreachability Detection, all though the Hosts
Requirements [HR-CL] does specify some possible algorithms for Dead
Gateway Detection (which is a subset of Neighbor Unreachability
Detection).

The Neighbor Discovery protocol provides a multitude of improvements
over the IPv4 set of protocols:

     Router Discovery is part of the base; no need for hosts to "snoop"
     the routing protocols.

     Router advertisements carry link-layer address; no additional
     packet exchange is needed to resolve the router's link-layer
     address.

     Router advertisements carry prefixes for a link; no need to have
     some other mechanism to configure the "netmask".

     Router advertisements contain hooks for Address Autoconfiguration.

     By default, hosts learn all on-link prefixes from Router
     Advertisements.  However, routers may be configured to omit some or
     all prefixes from Router Advertisements.  In such cases hosts will
     assume that destinations are off-link and send traffic to routers
     by default.  A router can then issue redirects for on-link
     destinations as appropriate.  This mechanism may be useful with
     shared media links where hosts might not know all the on-link
     prefixes.

     Routers can advertise an MTU for hosts to use on the link; better
     handling of links without a well-defined MTU.

     Address Resolution uses multicast "spread" over 256 multicast
     addresses; greatly reduced Address Resolution related interrupts
     for nodes other than the target and generates no interrupts on
     non-IPv6 nodes.

     Redirects contain the link-layer address of the new first hop;
     separate Address Resolution is not needed upon receiving a
     redirect.

     Nodes assume the new next-hop target address in a Redirect is on-
     link making it possible to redirect to targets that do not share a



draft-ietf-ipngwg-discovery-00.txt                             [Page 11]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


     common address prefix with the sender.  This is an implementation
     of the XRedirect idea in [SH-MEDIA] and it simplifies some aspects
     of neighbor interaction on shared media.

     Neighbor Unreachability Detection is part of the base.  This
     significantly improves the robustness of packet delivery in the
     presence of failing routers and nodes that change their link-layer
     addresses.  For instance, it enables mobile nodes to move off-link
     without loosing any connectivity due to stale ARP caches.

     Placing address resolution at the ICMP layer makes the protocol
     more media-independent than ARP and makes it possible to use
     standard IPv6 authentication and security mechanisms as appropriate
     [IPv6-AUTH, IPv6-ESP].



3.2.  Supported Link Types

Neighbor Discovery supports links with different properties.  In the
presense of certain properties only a subset of the ND protocol is
available:

   point-to-point - Neighbor Discovery handles such links just like
                    multicast links.  (Multicast can be trivially
                    provided on point to point links.)

   multicast      - All aspects of Neighbor Discovery are available.

   non-broadcast multiple access (NBMA)
                  - The only Neighbor Discovery mechanism available on
                    these links is Redirect.

                    If the hosts support manual configuration of a list
                    of default routers the hosts can dynamically acquire
                    the link-layer addresses for their neighbors from
                    Redirect messages.

   shared media   - The Redirect message is modeled after the XRedirect
                    message in [SH-MEDIA] in order to simplify use of
                    the protocol on shared media links.

                    This specification does not address shared media
                    issues that only relate to routers, such as:

                     - How routers exchange reachability information on
                       a shared media link.




draft-ietf-ipngwg-discovery-00.txt                             [Page 12]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


                     - How a router determines the link-layer address of
                       a hosts, which it needs to send redirect messages
                       to the host.

                     - How a router determines that it is the first hop
                       router for a received packet.


                    The protocol is extensible (using extensions) so
                    that other solutions might be possible in the
                    future.

   variable MTU   - Neighbor Discovery allows the routers to specify a
                    MTU for the link.  This allows all nodes to use the
                    same MTU.  Note: It is not possible to have each
                    node use a different MTU (or Maximum Receive Unit)
                    due to multicast.

   asymmetric connectivity
                  - Neighbor Discovery detects the absence of symmetric
                    connectivity; a node avoids using a neighbor with
                    which it does not have symmetric connectivity.

                    The protocol can presumably be extended in the
                    future to find viable paths in environments that
                    lack reflexive and transitive connectivity.


4.  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 behavior is
consistent with the protocol specification.

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


4.1.  Conceptual Data Structures

Hosts will need to maintain the following pieces of information about an
interface:



draft-ietf-ipngwg-discovery-00.txt                             [Page 13]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


   Neighbor Cache - A set of entries about individual neighbors to which
                    traffic has been sent recently.  Entries are keyed
                    on the neighbor's IP address and contain such
                    information as its link-layer address, a flag
                    indicating whether the neighbor is a router or a
                    host (called "is_router" 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.  This includes the reachability state,
                    the number of unanswered probes, and the earliest
                    time the next probe can be sent.

   Next-Hop Cache - A set of entries for each destination to which
                    traffic has been sent recently.  The Next-Hop Cache
                    includes both on-link and off-link destinations and
                    provides a level of indirection into the Neighbor
                    Cache; the Next-Hop Cache maps a destination IP
                    address to the IP address of the next-hop neighbor.
                    Implementations may find it convenient to store
                    additional information not directly related to
                    Neighbor Discovery in next-hop 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 IP
                    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 delete prefixes that routers
                    stop advertising.

   Default Router List
                  - A list of routers, prioritized by preference, to
                    which packets may be sent.  Router list entries will
                    point to entries in the Neighbor Cache so that when
                    a router is being selected, routers known to be
                    reachable can be favored over those whose
                    reachability is suspect.  Each entry also has an
                    associated timer value (extracted from Router
                    Advertisements) used to delete entries that are not
                    longer advertised.

The Neighbor Cache contains information maintained by Neighbor
Unreachability Detection algorithm.  A key piece of information is a



draft-ietf-ipngwg-discovery-00.txt                             [Page 14]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


neighbor's reachability status which is described by one of three
values:

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

   PROBE       The neighbor is probably reachable, but the last explicit
               reachability confirmation was received long enough ago
               that verification is now actively sought.

   TRY_ALTERNATES
               Several attempts at verifying reachability have failed,
               and additional attempts at restoring communication are
               warranted.  If the neighbor is being used as a router,
               for example, an alternate router might be tried.
               Alternatively, if the neighbor is the destination,
               Address Resolution can be performed again to detect a
               potentially changed link-layer address.


4.2.  Conceptual Sending Algorithm

When sending a packet, a node uses a combination of the Next-Hop 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-level information about that
neighbor.

Next-hop determination operates as follows.  The sender examines the
Prefix List to determine whether the packet's destination is on- or
off-link.  If the destination is on-link the sender knows that the
next-hop address is the same as the packet's destination address.  If
the destination is off-link, the sender selects a router from the
Default Router List (following the rules described in Section 5.3.3).
If there are no routers on the Default Router List, 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 Next-Hop Cache.  When the sending node has
a packet to send, it first examines the Next-Hop Cache.  If no entry
exists for the destination, next-hop determination is invoked to create
a Next-Hop Cache entry.

Once the IP address of the next-hop node is known, the sender examines
the Neighbor Cache for link-level information about that neighbor.  If
no entry exists, the node creates one, sends a Neighbor Solicitation



draft-ietf-ipngwg-discovery-00.txt                             [Page 15]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


query, and queues the packet pending completion of Address Resolution.
When a Neighbor Advertisement response is received, the link-layer
addresses is entered in the Neighbor Cache entry and the queued packet
is transmitted.  This Address Resolution mechanism is described in
section 6.2.

Each time a Neighbor Cache entry is accessed to transmit a packet, the
sender checks Neighbor Unreachability Detection related information
according to the Neighbor Unreachability Detection algorithm (section
6.3).  This check might result in the sender transmitting a 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 Next-Hop 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 Next-Hop Cache entry.  In fact, it is often
beneficial to retain information, such as cached PMTU and round trip
timer values, that are kept in the Next-Hop Cache entry.


4.3.  Garbage Collection and Timeout Requirements

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

>From the perspective of correctness, there is no need to periodically
purge Next-Hop and Neighbor Cache entries.  Although stale information
can potentially remain in the cache indefinitely, the Neighbor
Unreachability Detection algorithm described in this document insures
that stale information is purged quickly if it is actually being used.

To limit the storage needed for the Next-Hop 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 amount of
Neighbor Discovery messages as discarded entries are rebuilt.  Garbage
collection that uses an LRU policy that only reclaims entries that have
not been used in some time (e.g, ten minutes or more) should be
adequate.




draft-ietf-ipngwg-discovery-00.txt                             [Page 16]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


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 doing so the node should
retain at least one entry in the Default Router List (and preferably
more than one) in order to maintain robust connectivity for off-link
destinations.

When removing an entry from the Default Router List or the Prefix List
there is no need to purge any entries from the Next-Hop or Neighbor
Caches.  Once again, Neighbor Unreachability Detection will effectively
purge any entries in these caches that have become stale.



5.  ROUTER AND PREFIX DISCOVERY

This section describes message formats, router behavior and host
behavior related to the Router Discovery portion of Neighbor Discovery.
Router Discovery is used to locate neighboring routers as well as learn
prefixes and configuration parameters related to address
autoconfiguration.

Prefix Discovery provides a mechanism through which hosts learn of
ranges of IP addresses that reside on-link and thus can be reached
directly without going through a router.  Routers advertise a set of
prefixes that cover those IP addresses that are on-link.  Prefix
discovery is logically separate from Router Discovery.  In practice,
prefix information is included in extension piggybacked on Router
Advertisement messages to reduce network traffic.

Address Autoconfiguration information is also logically separate from
Router Discovery.  To reduce network traffic, however, autoconfiguration
information is piggybacked on Router Discovery messages.  This document
does not define how autoconfiguration information is processed.  See
[ADDRCONF] for details.


5.1.  Message Formats


5.1.1.  Router Solicitation Message Format










draft-ietf-ipngwg-discovery-00.txt                             [Page 17]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Reserved                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Extensions ...
     +-+-+-+-+-+-+-+-+-+-+-+-

IPv6 Fields:

   Source Address
                  An IP address belonging to the interface from which
                  this message is sent.

   Destination Address
                  The all-routers multicast address.

   Hop Count      1

   Authentication Header
                  If a security association exists between the sender
                  and the destination the sender SHOULD include this
                  header.

IPv6 ICMP Fields:

   Type           133

   Code           0

   Checksum       The ICMPv6 checksum.  See [ICMPv6].

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

Extensions:

   Source link-layer address
                  The link-layer address for the sender.  SHOULD be
                  included on link layers that have addresses in order
                  for the router to be able to send a Router
                  Advertisement without having to resolve the host's
                  address.

   Future versions of this protocol may define new extension types.
   Receivers MUST skip over and ignore any extensions they do not
   recognize and continue processing the message.




draft-ietf-ipngwg-discovery-00.txt                             [Page 18]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


5.1.2.  Router Advertisement Message Format

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Preference  |M|O|  Reserved |     Lifetime-as-default       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Extensions ...
     +-+-+-+-+-+-+-+-+-+-+-+-

IPv6 Fields:

   Source Address
                  The interface's designated IP address.

   Destination Address
                  Either the Source Address of an invoking Router
                  Solicitation or the all-hosts multicast address.

   Hop Count      1

   Authentication Header
                  If a security association exists between the sender
                  and the destination the sender SHOULD include this
                  header.

IPv6 ICMP Fields:

   Type           134

   Code           0

   Checksum       The ICMPv6 checksum.  See [ICMPv6].

   Preference     8-bit unsigned integer.  The preference as a default
                  router.  Larger numbers indicate more preferable
                  routers.

   M              1-bit flag.  Use the administered (stateful) protocol
                  for address autoconfiguration.  The use of this flag
                  is described in [ADDRCONF].

   O              1-bit flag.  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



draft-ietf-ipngwg-discovery-00.txt                             [Page 19]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


                  by the sender and ignored by the receiver.

   Lifetime-as-default
                  16-bit unsigned integer.  The lifetime associated with
                  the default router in units of seconds.  The maximum
                  value corresponds to 18.2 hours.  This lifetime does
                  not apply to information contained in any extensions
                  in the message.  Extensions that need time limits for
                  their information include their own lifetime fields.

Extensions:

   Source link-layer address
                  The link-layer address for the router.  Only used on
                  link layers that have addresses.  A router MAY omit
                  this extension in order to enable inbound load sharing
                  across multiple link-layer addresses.

   Suggested hop limit
                  MAY be sent.

   Suggested Neighbor Unreachability Timer
                  MAY be sent.

   MTU            SHOULD be sent on links that do not have a well-
                  defined MTU.  MAY be sent on links with a well-
                  defined, standard MTU.

   Prefix Information
                  A router MAY include 0 or more Prefix Information
                  extensions.  These extensions specify the prefixes
                  that are on-link and also contain information specific
                  to automatic address configuration.  A router SHOULD
                  include all on-link prefixes on multicast links.  This
                  enables multihomed hosts to do optimal outgoing
                  interface selection for neighboring nodes.


   Future versions of this protocol may define new extension types.
   Receivers MUST skip over and ignore any extensions they do not
   recognize and continue processing the message.


5.2.  Router Specification







draft-ietf-ipngwg-discovery-00.txt                             [Page 20]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


5.2.1.  Router Configuration Variables

A router MUST allow for the following variables to be configured by
system management; default values are specified so as to make it
unnecessary to configure any of these variables in many cases.

For each multicast interface:
     MaxRtrAdvInterval
                    The maximum time allowed between sending multicast
                    Router Advertisements from the interface, in
                    seconds.  MUST be no less than 4 seconds and no
                    greater than 1800 seconds.

                    Default: 600 seconds

     MinRtrAdvInterval
                    The minimum time allowed between sending unsolicited
                    multicast Router Advertisements from the interface,
                    in seconds.  MUST be no less than 3 seconds and no
                    greater than MaxRtrAdvInterval.

                    Default: 0.75 * MaxRtrAdvInterval

     RtrAdvLifetime
                    The value to be placed in the Lifetime-as-default
                    field of Router Advertisements sent from the
                    interface, in seconds.  MUST be no less than
                    MaxRtrAdvInterval and no greater than 9000 seconds.

                    Default: 3 * MaxRtrAdvInterval

     PrefixList
                    A list of prefixes to be placed in Prefix
                    Information extensions in Router Advertisement
                    messages sent from the interface.

                    Default: The PrefixList contains all prefixes that
                    the router advertises via routing protocols as being
                    on the link on which the advertisement is sent.

                    Each prefix is associated with:

                       InvalidationLifetime
                                      The value to be placed in the
                                      Invalidation Lifetime in the
                                      Prefix Information extension, in
                                      seconds.




draft-ietf-ipngwg-discovery-00.txt                             [Page 21]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


                                      Default: 3600 seconds.

                       On-link flag   The value to be placed in the on-
                                      link flag in the Prefix
                                      Information extension.

                                      Default: true.

                    Note: [ADDRCONF] defines additional information
                    associated with the prefixes.

     AdvertiseDefault
                    A flag indicating whether or not the router should
                    advertise itself as a default router on the
                    interface.

                    Default: TRUE

     PreferenceLevel
                    The preferability of the router as a default router,
                    relative to other routers on the same link.  A 8-bit
                    unsigned integer, with higher values meaning more
                    preferable.

                    Default: 128

     Designated address
                    The address to be used as the source address in all
                    Neighbor Discovery messages sent on the interface.


Protocol constants are defined in section 10.


5.2.2.  Message Validation by Routers

A router MUST silently discard any received Router Solicitation messages
that do not satisfy the following validity checks:

   - ICMP Checksum is valid.

   - ICMP Code is 0.

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

   - if the message includes an Authentication Header, the message is
     correctly authenticated.




draft-ietf-ipngwg-discovery-00.txt                             [Page 22]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


   - all included extensions have a length that is greater then zero.


The contents of the Reserved field, and of any unrecognized extensions,
MUST be ignored.  Future, backward-compatible changes to the protocol
may specify the contents of the Reserved field or add new extensions;
backward-incompatible changes may use different Code values.

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

A router MAY silently discard any received Router Advertisement
messages.  It is recommended (but not required) that routers receive
Router Advertisements and check for different MTU extension values and
log a network management event when there is a mismatch.  Routers can
also examine the source address of Router Advertisements to determine
which of a neighboring routers addresses is its designated address.  Any
other action on reception of such messages by a router is beyond the
scope of this document.


5.2.3.  Router Behavior

A router MUST join the all-router multicast address on all multicast
capable interfaces.

The term "advertising interface" refers to any functioning and enabled
interface that has at least one IP address assigned to it.  From each
advertising interface, the router transmits periodic, multicast Router
Advertisements, containing the following values consistent with the
message format above:

   - In the Lifetime-as-default field: the interface's configured
     RtrAdvLifetime.

   - In the Preference field: the interface's configured
     PreferenceLevel.

   - In the O and M flags: see [ADDRCONF] for the settings of these
     flags.

   - In the extension fields:

     Source Link-Layer Address extension: link-layer address of the
          sending interface.  This extension MAY be omitted to
          facilitate in-bound load balancing on replicated interfaces.

     Prefix Information extensions: one Prefix Information extension for



draft-ietf-ipngwg-discovery-00.txt                             [Page 23]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


          each prefix listed in PrefixList.  The "on-link" flag in the
          extension SHOULD be set to the on-link flag in the PrefixList
          entry.  The Invalidation Lifetime in the extension is set to
          the InvalidationLifetime in the PrefixList entry.  The use of
          the "address configuration flag" and the Deprecation Lifetime
          in the Prefix Information extension is specied in [ADDRCONF].

The advertisements are not strictly periodic: the interval between
subsequent transmissions is randomized to reduce the probability of
synchronization with the advertisements from other routers on the same
link.  This is done by maintaining a separate transmission interval
timer for each advertising interface.  Each time a multicast
advertisement is sent from an interface, that interface's timer is reset
to a uniformly-distributed random value between the interface's
configured MinRtrAdvInterval and MaxRtrAdvInterval; expiration of the
timer causes the next advertisement to be sent from the interface, and a
new random value to be chosen.  (It is recommended that routers include
some unique value, such as one of their IP or link-layer addresses, in
the seed used to initialize their pseudo-random number generators.
Although the randomization range is configured in units of seconds, the
actual randomly-chosen values SHOULD not be in units of whole seconds,
but rather in units of the highest available timer resolution.)

For the first few advertisements sent from an interface (up to
MAX_INITIAL_RTR_ADVERTISEMENTS), if the randomly chosen interval is
greater than MAX_INITIAL_RTR_ADVERT_INTERVAL, the timer SHOULD be set to
MAX_INITIAL_RTR_ADVERT_INTERVAL instead.  Using this smaller interval
for the initial advertisements increases the likelihood of a router
being discovered quickly when it first becomes available, in the
presence of possible packet loss.

In addition to the periodic, unsolicited advertisements, a router sends
advertisements in response to valid solicitations received on any of its
advertising interfaces.  A router MAY choose to unicast the response
directly to the soliciting host's address, or multicast it to the all-
hosts address; in the latter case, the interface's interval timer is
reset to a new random value, as with unsolicited advertisements.  A
unicast response MAY be delayed, and a multicast response MUST be
delayed, for a small random interval not greater than
MAX_RTR_RESPONSE_DELAY, in order to prevent synchronization with other
responding routers, and to allow multiple, closely-spaced solicitations
to be answered with a single multicast advertisement.  While the router
is delaying a multicast response it SHOULD silently ignore any
additional solicitations, since it will multicast the response to all-
hosts.

When a router receives a Router Solicitation it records the source of
the packet as being a neighbor.  If the solicitation contains a Source



draft-ietf-ipngwg-discovery-00.txt                             [Page 24]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


Link-Layer Address extension the link-layer address is also recorded in
the Neighbor Cache while also setting the "is_router" flag to false in
the cache entry.

It should be noted that an interface may become an advertising interface
at times other than system startup, as a result of recovery from an
interface failure or through actions of system management such as:

   - enabling the interface, if it had been administratively disabled,
     and its AdvertiseDefault flag is TRUE, or

   - enabling IP forwarding capability (i.e., changing the system from
     being a host to being a router), when the interface's
     AdvertiseDefault flag is TRUE, or

   - changing the AdvertiseDefault flag from FALSE to TRUE.

In such cases the router MUST commence transmission of periodic
advertisements on the new advertising interface, limiting the first few
advertisements to intervals no greater than
MAX_INITIAL_RTR_ADVERT_INTERVAL.  In the case of a host becoming a
router, the system MUST also join the all-routers IP multicast group on
all interfaces on which the router supports IP multicast (whether or not
they are advertising interfaces).

An interface may also cease to be an advertising interface, through
actions of system management such as:

   - administratively disabling the interface, or

   - shutting down the system, or disabling the IP forwarding capability
     (i.e., changing the system from being a router to being a host), or

   - setting the AdvertiseDefault flag of the interface to FALSE.

In such cases the router SHOULD transmit a final multicast Router
Advertisement on the interface with a Lifetime-as-default field of zero.
In the case of a router becoming a host, the system MUST also depart
from the all-routers IP multicast group on all interfaces on which the
router supports IP multicast (whether or not they had been advertising
interfaces).  In addition, the host MUST insure that subsequent Neighbor
Advertisement messages sent from the interface contain a Code of 0 (i.e.
"not a router").

A router might want to send Router Advertisements without advertising
itself as being a default router.  For instance, a router might
advertise prefixes for address autoconfiguration while not wishing to
forward packets.  Such a router SHOULD set the Lifetime-as-default field



draft-ietf-ipngwg-discovery-00.txt                             [Page 25]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


to zero in its advertisements.


5.2.4.  Designated Addresses

Routers should take some care in selecting their designated address and
in handling any, hopefully infrequent, change of their designated
address.

The designated address SHOULD be one that changes infrequently over
time.  Nodes receiving Neighbor Discovery messages use the source
address to identify the sender.  If multiple packets from the same
neighbor contain different source addresses, nodes will assume they come
from different nodes, leading to undesirable behavior.  For example, a
node will ignore Redirect messages that are believed to have been sent
by a router other than the current first-hop router.

It is suggested that a link-local address be used as the designated
address since this address does not change when a site renumbers.

If a router needs to change its designated address for one of its
interfaces it SHOULD inform hosts of this change.  The router should
multicast a few Router Advertisements with lifetime-as-default set to
zero for the old designated address and also multicast a few Router
Advertisements for the new designated address.  The exact procedures
SHOULD be the same as when an interface ceases to being an advertising
interface, and when an interface becomes an advertising interface,
respectively.

A router MUST be able to determine the designated 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 designated
address.  This requires that routing protocols exchange designated
addresses.


5.3.  Host Specification


5.3.1.  Host Configuration Variables

None.


5.3.2.  Message Validation by Hosts

A host MUST silently discard any received Router Advertisement messages
that do not satisfy the following validity checks:



draft-ietf-ipngwg-discovery-00.txt                             [Page 26]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


   - ICMP Checksum is valid.

   - ICMP Code is 0.

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

   - if the message includes an Authentication Header, the message is
     correctly authenticated.

   - all included extensions have a length that is greater then zero.


The contents of the Reserved field, and of any unrecognized extensions,
MUST be ignored.  Future, backward-compatible changes to the protocol
may specify the contents of the Reserved field or add new extensions;
backward-incompatible changes may use different Code values.

An advertisement that passes the validity checks is called a "valid
advertisement".

A host MUST silently discard any received Router Solicitation messages.


5.3.3.  Host Behavior

The host joins the all-host multicast address on all multicast capable
interfaces.

A host MUST NOT send a Router Advertisement message at any time.

To process a valid Router Advertisement, a host extracts the source
address of the packet and does the following:

   - If the address is not already present in the host's Default Router
     List, a new entry is added to the list.  The entry's preference
     level is copied from the Preference field and a timer is started
     initialized to the advertisement's Lifetime-as-default field.

   - If the address is already present in the host's Default Router List
     as a result of a previously-received advertisement, its preference
     level is updated and its timer is reset to the Lifetime-as-default
     value in the newly-received advertisement.

   - If the received Lifetime-as-default value is zero the entry is
     timed out immediately.


After updating the Default Router List, the Router Advertisement MUST be



draft-ietf-ipngwg-discovery-00.txt                             [Page 27]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


scanned for valid extensions.  If the advertisement contains a source
link-layer address extension the link-layer address MUST be recorded in
the Neighbor Cache entry for the router and the "is_router" flag in the
Neighbor Cache entry be set to true.  This flag is used by Neighbor
Unreachability Detection to determine when a router changes to being a
host (i.e. no longer capable of forwarding packets).

For each Prefix Information extension that has the "on-link" (L) flag
set, the host does the following:

   - If the prefix is not already present in the Prefix List, create a
     new entry for the prefix and initialize its invalidation timer to
     the Invalidation Lifetime value in the Prefix Information
     extension.

   - If the prefix is already present in the host's Prefix List as the
     result of a previously-received advertisement, reset its
     invalidation timer to the Invalidation Lifetime value in the Prefix
     Information extension.

   - If the received Invalidation Lifetime value is zero the prefix is
     timed out immediately.


Whenever the invalidation timer expires for a Prefix List entry, that
entry is discarded.  No existing Next-Hop Cache entries are affected,
however.

Whenever a timer expires for an entry in the Default Router List, that
entry is discarded.  Any entries in the Next-Hop Cache going through
that router will continue to be used.  Neighbor Unreachability Detection
will purge them if appropriate.

To limit the storage needed for the Default Router List, a host MAY
choose not to store all of the router addresses discovered via
advertisements.  If so, the host SHOULD discard those addresses with
lower preference levels in favor of those with higher levels.  In any
case, a host SHOULD retain more than one default router address in the
list so that, if the current choice of default router is discovered to
be down, the host can immediately select another default router, without
having to wait for the next advertisement to arrive.

Preference levels learned from advertisements do not affect any of the
host's cached route entries.  For example, if the host has been
redirected to use a particular router address to reach a specific IP
destination, it continues to use that router address for that
destination, even if it discovers another router address with a higher
preference level.  Preference levels influence the choice of router only
draft-ietf-ipngwg-discovery-00.txt                             [Page 28]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


for an IP destination for which there is no Next-Hop Cache entry, or
whose Next-Hop Cache entry points to a router that is subsequently
discovered to be unreachable.

The algorithm for selecting a router depends in part on whether or not a
router is known to be reachable.  The exact details of how a node keeps
track of a neighbor's reachability status are covered in Section 6.3.
The algorithm for selecting a default router is invoked only when a
Next-Hop Cache entry is incomplete or when communication through an
existing router appears to be failing.  Under normal conditions, a
router would be selected the first time traffic is sent to a
destination, with subsequent traffic for that destination using the same
router as indicated in the Next-Hop Cache.  The policy for selecting
routers from the Default Router List is as follows:

  1) Examine router entries one at a time by iterating through the list
     in preference order, starting with the highest preference router.
     For each examined entry in the list:

       a) If the status of the Neighbor Cache entry for the router is
          REACHABLE or PROBE, select this router.  Otherwise, continue
          to the next step.

       b) If the recorded status of the neighboring router is
          TRY_ALTERNATES, the router MUST NOT be selected for use.
          However, the Neighbor Unreachability Detection mechanism (see
          section 6.3) SHOULD be invoked to send a (rate limited) probe
          to the router in order to solicit a reachability confirmation.

  2) If the entire router list is scanned in 1) without finding an
     acceptable candidate, the host MAY either send an ICMP Destination
     Unreachable error (as specified in [ICMPv6], or it MAY assume that
     the destination is on-link.  The latter is likely to result in
     invoking Address Resolution for the destination, which may in turn
     result in generating an ICMP Address Unreachable error if the
     destination fails to respond to repeated Neighbor Solicitation
     messages.

The above algorithm has a number of desirable properties.  First, higher
preference routers that are known to be reachable are favored over those
having lower preferences.  However, higher preference routers are not
favored to the point that routers considered to be unreachable continue
to be chosen when other candidates are available.  Second, when all
routers on the default list are considered unreachable, all candidate
routers are probed.  Finally, when higher-preference routers are
unreachable, but lower-preference routers are reachable, the higher-
preference routers are still periodically probed, and they will become
candidates for selection as soon as they become reachable again.



draft-ietf-ipngwg-discovery-00.txt                             [Page 29]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


A host is permitted (but not required) to transmit up to
MAX_RTR_SOLICITATIONS Router Solicitation messages from any of its
multicast interfaces after any of the following events:

   - The interface is initialized at system startup time.

   - The interface is reinitialized after a temporary interface failure
     or after being temporarily disabled by system management.

   - The system changes from being a router to being a host, by having
     its IP forwarding capability turned off by system management.

   - The host is re-attached to a link after being detached for some
     time.

The IP destination address of the solicitations is the all-routers
multicast address.  The IP source address contains one of the
interface's addresses.  The Source Link-Layer Address extension is set
to the host's link-layer address.

If a host does choose to send a solicitation after one of the above
events, it SHOULD delay that transmission for a random amount of time
between 0 and MAX_RTR_SOLICITATION_DELAY.  This serves to alleviate
congestion when many hosts start up on a link at the same time, such as
might happen after recovery from a power failure.  (It is recommended
that hosts include some unique value, such as one of their IP or link-
layer addresses, in the seed used to initialize their pseudo-random
number generators.  Although the randomization range is specified in
units of seconds, the actual randomly-chosen value SHOULD not be in
units of whole seconds, but rather in units of the highest available
timer resolution.)

A host MAY also choose to further postpone its solicitations, subsequent
to one of the above events, until the first time it needs to use a
default router.

Upon receiving a valid advertisement the host MUST desist from sending
any solicitations on that interface (even if none have been sent yet),
until the next time one of the above events occurs.  The small number of
retransmissions of a solicitation, which are permitted if no such
advertisement is received, SHOULD be sent at intervals of
RTR_SOLICITATION_INTERVAL seconds, without randomization.









draft-ietf-ipngwg-discovery-00.txt                             [Page 30]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


6.  ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION

This section describes the set of functionality related to the Neighbor
Solicitation and Neighbor Advertisement messages and includes
descriptions of the Address Resolution and the Neighbor Unreachability
Detection algorithms.

These messages are also used for Duplicate Address Detection as
specified by [ADDRCONF].  In particular, Duplicate Address Detection
uses the unspecified address as the Source Address in Neighbor
Solicitations to prompt a node with a duplicate address to multicast the
Neighbor Advertisement.


6.1.  Message Formats


6.1.1.  Neighbor Solicitation Message Format

Nodes send Neighbor Solicitations to request the link-layer address of a
target node while 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.


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                       Target Address                          +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Extensions ...
     +-+-+-+-+-+-+-+-+-+-+-+-

IPv6 Fields:

   Source Address
                  An IP address belonging to the interface from which
                  this message is sent.  If the sender is a router, the
                  address MUST be the interface's designated address.  A



draft-ietf-ipngwg-discovery-00.txt                             [Page 31]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


                  node MAY also use the unspecified address before it
                  has determined that its addresses are unique.

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

   Hop Count      1

   Authentication Header
                  If a security association exists between the sender
                  and the destination the sender SHOULD include this
                  header.

IPv6 ICMP Fields:

   Type           135

   Code
                  0              If the sender is a host.
                  1              If the sender is a router.

   Checksum       The ICMPv6 checksum.  See [ICMPv6].

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

   Target Address The IP address of the target of the invoking
                  solicitation or, for an unsolicited advertisement

Extensions:

   Source link-layer address
                  The link-layer address for the sender.  MUST be
                  included on link layers that have addresses.

   Future versions of this protocol may define new extension types.
   Receivers MUST skip over and ignore any extensions they do not
   recognize and continue processing the message.



6.1.2.  Neighbor Advertisement Message Format

A node MUST send a Neighbor Advertisement in response to a Neighbor
Solicitation for an IP addresses assigned to the receiving interface.
In addition a node MAY send an unsolicited multicast Neighbor



draft-ietf-ipngwg-discovery-00.txt                             [Page 32]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


Advertisement when the node knows that its link-layer address has
changed.


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                       Target Address                          +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Extensions ...
     +-+-+-+-+-+-+-+-+-+-+-+-

IPv6 Fields:

   Source Address
                  An IP address belonging to the interface from which
                  this message is sent.  The source address MUST be the
                  same as the target address for a non-proxy response.
                  The source address MUST be the interface's designated
                  address for a proxy response.

   Destination Address
                  Either the Source Address of an invoking Neighbor
                  Solicitation, or the all-nodes multicast address.  If
                  the source solicitation is the unspecified address the
                  advertisement MUST be multicast to all-nodes.

   Hop Count      1

   Authentication Header
                  If a security association exists between the sender
                  and the destination the sender SHOULD include this
                  header.

IPv6 ICMP Fields:

   Type           136

   Code
                  0              If the sender is a host.



draft-ietf-ipngwg-discovery-00.txt                             [Page 33]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


                  1              If the sender is a router.

   Checksum       The ICMPv6 checksum.  See [ICMPv6].

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

   Target Address The address from 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.

Extensions:

   Target link-layer address
                  The link-layer address for the target.  MUST be
                  included on link layers that have addresses.

   Future versions of this protocol may define new extension types.
   Receivers MUST skip over and ignore any extensions they do not
   recognize and continue processing the message.


6.2.  Address Resolution

Address Resolution provides the mechanism through which nodes determine
the link-layer address of their neighbors.


6.2.1.  Message Validation by Nodes

A node MUST silently discard any received Neighbor Solicitation or
Advertisement messages that do not satisfy the following validity
checks:

   - ICMP Checksum is valid.

   - ICMP Code is 0 or 1.

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

   - if the message includes an Authentication Header, the message is
     correctly authenticated.

   - all included extensions have a length that is greater then zero.


The contents of the Reserved field, and of any unrecognized extensions,



draft-ietf-ipngwg-discovery-00.txt                             [Page 34]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


MUST be ignored.  Future, backward-compatible changes to the protocol
may specify the contents of the Reserved field or add new extensions;
backward-incompatible changes may use different Code values.

Neighbor Solicitations and Advertisements that passes the validity
checks are called "valid solicitations" and "valid advertisements",
respectively.


6.2.2.  Node Specification

When a multicast-capable interface is initialized the node MUST join the
all-nodes multicast address on that interface, as well as the
solicited-node multicast address corresponding to each of the IP
addresses assigned to the interface.


6.2.3.  Sending Node Specification

When a node has a packet to send, but does not know the next-hop's
link-layer address, the sender performs address resolution by
transmitting a Neighbor Solicitation message targeted at the neighbor
and queuing the packet.  The message MUST be sent to the solicited-node
multicast address corresponding to the target address.

The sender MUST include its link-layer address (if it has one) in the
solicitation as a Source Link-Layer Address extension, so that the
receiver discovers the sender's link-layer address without the need for
an additional packet exchange.

While waiting for address resolution to complete, the sender MUST
maintain a small queue containing packets waiting for address resolution
to complete.  The queue MUST hold at least one packet, and MAY contain
more.  However, the number of queued packets per neighbor SHOULD be
limited to some small value.  When a queue overflows, the new arrival
SHOULD replace the oldest entry.  Once address resolution completes, all
queued packets SHOULD be transmitted.

While awaiting for address resolution to complete, the sender MUST
rate-limit the sending of further Neighbor Solicitations to the neighbor
to at most one solicitation every RESOLVE_RETRANS_TIMER seconds.  This
constraint applies even if the sender has new packets to send to the
neighbor at a higher rate.

In order to be able to generate ICMP Address Unreachable errors, the
sender SHOULD retransmit the solicitation every RESOLVE_RETRANS_TIMER
seconds until either an advertisement is received from the target or the
solicitation has been retransmitted UNREACHABLE_THRESHOLD times.



draft-ietf-ipngwg-discovery-00.txt                             [Page 35]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


If no Neighbor Advertisement is received after sending
UNREACHABLE_THRESHOLD unanswered solicitations, the sender SHOULD
generate an ICMP unreachable error with code 3 (Address Unreachable) for
each packet queued for the neighbor.  The error messages are constructed
as all ICMP errors (see [ICMPv6]) and sent errors to the sources of the
queued packets.  Generating ICMP errors when address resolution fails
provides more precise diagnostics to administrators which is the intent
of the Address Unreachable code in [ICMPv6].

When a valid unicast Neighbor Advertisement is received, and there is a
Neighbor Cache entry for the target which contains no link-layer
address, the node records the link-layer address in the Neighbor Cache
entry and also sends any packet that have been queued for the neighbor.
Furthermore, the node MUST set the "is_router" flag in the Neighbor
Cache entry based on the Code field in the advertisement.  If the
"is_router" flag was previously set but the advertisement has Code set
to 0 the node MUST follow the rules in section 6.3.2 to handle the case
when a router becomes a host.

Multiple unicast Neighbor Advertisements can be received in response to
a query.  In such cases one or more of the advertisements is a proxy
advertisement.  Proxy advertisements are identified by having differing
source and target addresses.  A node MUST give preference to non-proxy
responses over proxy responses and, among multiple proxy responses, a
node MUST prefer the first proxy response.  This is accomplished by
applying the following rules while processing received advertisements:

   - if no link-layer address has been previously recorded, install the
     one contained in the advertisement.

   - if a link-layer address has already been recorded, and the
     advertisement is not a proxy advertisement, install the address
     contained in the advertisement.

   - otherwise ignore the advertisement


A node MAY occasionally multicast unsolicited Neighbor Advertisement
announcing a link-layer address change.  A node that receives an
multicast Neighbor Advertisement does the following:

   - It MUST silently ignore a proxy multicast Neighbor Advertisement.

   - If the node does not have a Neighbor Cache  entry for the target of
     the advertisement, it SHOULD silently discard the message.
     Accepting such multicast advertisements would result in occupying a
     cache entry with information about a neighbor that might never be
     used.



draft-ietf-ipngwg-discovery-00.txt                             [Page 36]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


   - If the node does have a Neighbor Cache entry for the target, it
     SHOULD copy the link-layer address information contained in the
     advertisement's Source Link-Layer Address extension into the
     corresponding Neighbor Cache entry.

   - The node MUST not treat the receipt of a multicast advertisement as
     a confirmation that the neighbor is REACHABLE (as defined in
     Section 4.1).  See section 6.3.1.



6.2.4.  Target Node Specification

When a node receives a valid Neighbor Solicitation, it compares the
query's Target Address against the IP addresses belonging to the
incoming interface.  If the node is a router it MUST also compare the
Target Address against the set of anycast addresses (and potentially
other addresses) for which it is providing proxy services.  If no match
is found the node is not the target of the query and it MUST silently
ignore the solicitation.

If the node is the target of the solicitation, it first ensures that it
has an up-to-date neighbor cache for the Source Address of the
solicitation.  If no entry is found one is created and its link-layer
address is copied from the Source Link-Layer Address extension in the
message.  If an entry already exists its link-layer address is updated
to match the address in the Source Link-Layer Address extension.  In
either case , the node MUST set the "is_router" flag in the Neighbor
Cache entry based on the Code field in the solicitation.  If the
"is_router" flag was previously set but the advertisement has Code set
to 0 the node MUST follow the rules in section 6.3.2 to handle the case
when a router becomes a host.

If the source of the solicitation is the unspecified address, the target
MUST multicast an advertisement to the all-nodes address.  Otherwise,
the target MUST send a unicast Neighbor Advertisement to the address
copied from the IP Source Address of the Neighbor Solicitation.  In both
cases the Target Address is copied from the solicitation message to the
advertisement and the Target Link-Layer Address extension is filled with
the node's link-layer address on the link.  If the node is not providing
proxy services for the targeted address, the IP Source Address MUST be
set to the address in the Target Address field (which is one of the IP
addresses belonging to the interface).  This guarantees that the
receiver can identify the Neighbor Advertisement as being a non-proxy
advertisement.

If the node is providing proxy services for the target the IP Source
Address MUST be set the interface's designated address (which is



draft-ietf-ipngwg-discovery-00.txt                             [Page 37]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


different than the Target Address).  This allows the receiver to
recognize the message as a proxy advertisement.

A node MUST NOT send unicast Neighbor Advertisement except in response
to a Neighbor Solicitation, in order to avoid confusing the Neighbor
Unreachability Detection algorithm.


6.2.5.  Anticipated link-layer address changes

In some cases a node may be able to determine that its link-layer
address has changed (e.g., hot-swap of an interface card) and may wish
to inform its neighbors of the new link-layer address quickly.  In such
cases a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT Neighbor
Advertisement messages to the all-nodes multicast address.  These
advertisements MUST be separated by at least
MIN_NEIGHBOR_ADVERT_INTERVAL seconds.

The Target Address field in the multicast advertisement is set to the IP
address of the interface and the Target Link-Layer Address extension is
filled with the new link-layer address.  The IP Source Address MUST
match the address in the Target Address field of the solicitation.

A node that has multiple IP addresses assigned to an interface MAY
multicast a separate Neighbor Advertisement for each address.

A proxy MUST NOT multicast Neighbor Advertisements when its link-layer
changes.  (It is anticipated that multiple routers will proxy for the
same addresses and allowing multicast advertisement could result in
excessive multicast traffic.)

Note that multicasting Neighbor Advertisements does not reliably update
caches in all nodes (the advertisements might not be received by all
nodes) and should only be viewed as a optimization to quickly update the
caches in most neighbors.  The Neighbor Unreachability Detection
algorithm will ensure that neighbors reliably update the cached link-
layer address when they attempt to communicate with the node.


6.2.6.  Proxy Neighbor Advertisements

Under limited circumstances, a router MAY proxy for one ore more other
nodes, that is, through Neighbor Advertisements indicate that it is
willing to accept packets not explicitly addressed to itself.  For
example, a router may accept packets addressed to one of its configured
anycast addresses, or a router might potentially accept packets on
behalf of a mobile node that has moved off-link.  The address being
served is called a "proxee" in this section.



draft-ietf-ipngwg-discovery-00.txt                             [Page 38]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


A proxy MUST join the solicited-node multicast address(es) that
correspond to the proxee's IP address(es).

All proxy Neighbor Advertisement messages MUST be tagged as being proxy
messages; the advertisement's Source Address MUST differ from its Target
Address (e.g., the proxee).  In practice, this requirement poses no
special burden.  By definition, the advertisement's source address MUST
be the designated address of the interface on which the advertisement is
sent, which will be different than any proxee address.




6.2.7.  Anycast

An anycast address can not be syntactically distinguished from other
unicast addresses.  This section shows how the rules defined above "do
the right thing" for anycast addresses.

When a router responds to a Neighbor Solicitation for an anycast
address, it by definition responds with a proxy Neighbor Advertisement.
Anycast address are not permitted to appear as the source address in an
IP packet, guaranteeing that the advertisement's source and target
addresses differ.

A node might receive multiple Neighbor Advertisements in response to a
Neighbor Solicitation for an anycast address when multiple neighbors are
configured to recognize the anycast address.  The precedence rules in
section 6.2.3 will make the node select the first advertisement (i.e.
the fastest or lightest loaded router) as current binding for the
anycast address.

The use of Neighbor Unreachability Detection ensures that a node quickly
detects when the current binding for the anycast address has gone stale
e.g. due to a router no longer belonging to the anycast address.


6.3.  Neighbor Unreachability Detection

Communication to or through a neighbor may fail for numerous reasons at
any time, including hardware failure, hot-swap of an interface card, a
mobile node moving off-link, etc.  If the destination has failed, no
recovery is possible and communication fails.  On the other hand, if it
is the path that has failed, recovery may be possible.  Thus, a node
actively tracks the reachability "state" for the neighbors to which it
is sending packets.

Neighbor Unreachability Detection is used for all paths between



draft-ietf-ipngwg-discovery-00.txt                             [Page 39]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


neighboring nodes, including host-to-host, host-to-router, and router-
to-host communication.  When a path to a neighbor appears to be failing,
the specific recovery attempt depends on how the neighbor is being used.
For example, appropriate recovery procedures when using the neighbor as
a router differ from those appropriate for the case where the neighbor
is the destination.


6.3.1.  Reachability Confirmation

A neighbor is considered reachable if the node has recently received a
confirmation that packets sent to the neighbor are received by its IPv6
layer.  Positive confirmation can be gathered in two ways: hints from
upper layer protocols that indicate a connection is making "forward
progress", or receipt of a unicast Neighbor Advertisement message that
is a response to an explicit Neighbor Solicitation probe.

A connection makes "forward progress" if the packets received from a
remote peer can only be arriving if recent packets sent to that peer are
actually reaching it.  For example, receipt of a (new) acknowledgement
indicates that previously sent data reached the peer.  Likewise, the
arrival of a new (non-duplicate) packet indicates that earlier
acknowledgements are being delivered to the remote peer.  If packets are
reaching the peer the packets must also be reaching the sender's next-
hop neighbor, thus "forward progress" is a confirmation that the next-
hop neighbor is reachable.  When available, this upper-layer information
SHOULD be used.

In some cases (e.g, UDP-based protocols and routers forwarding packets
to hosts) such reachability information is not available from upper-
layer protocols.  When no hints are available and a node is sending
packets to a neighbor, the node actively probes the neighbor using
Neighbor Solicitation messages to verify that the forward path is still
working.

The receipt of a unicast Neighbor Advertisement that is a response to
such a Neighbor Solicitation probe serves as a reachability
confirmation, since all unicast advertisements are sent in response to a
solicitation.  A received multicast Neighbor Advertisement MUST NOT be
treated as a reachability confirmation since it is likely to be
unsolicited.  Receipt of unsolicited advertisements only confirm the
one-way path from the neighbor to the recipient node.  In contrast,
Neighbor Unreachability Detection requires that a path be working from
the node to the neighbor.  An advertisement sent in response to an
explicit solicitation confirms that a path is working in both
directions; the solicitation reached the neighbor, prompting it to
generate an advertisement, and the advertisement reached the querying
node.



draft-ietf-ipngwg-discovery-00.txt                             [Page 40]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


6.3.2.  Node behavior

Neighbor Unreachability Detection operates in parallel with the sending
of packets to a neighbor.  While reasserting a neighbor's reachability,
a node continues sending packets to that neighbor using the cached
link-layer address.

A neighbor is considered REACHABLE if a reachability confirmation was
received less than REACHABLE_TIME seconds ago.  Packets sent to a
REACHABLE neighbor require no special action.

Neighbors with PROBE or TRY_ALTERNATES status are actively probed to
ascertain their reachability status.  Neighbor Solicitation probe
messages are sent only on demand; only when a packet is being sent to
that neighbor.  When no traffic is sent to a neighbor, no probes are
sent to it, regardless of the neighbors reachability state.

When a REACHABLE Neighbor Cache entry is referenced after REACHABLE_TIME
seconds have passed since the last reachability confirmation was
received, its status should be changed to PROBE but no probe should be
sent.  Any probing is deferred for an additional DELAY_FIRST_PROBE_TIME
seconds; an optimization that gives the upper-layer protocol additional
time to provide a reachability confirmation in those cases where
REACHABLE_TIME seconds have passed since the last confirmation due to
lack of recent traffic.  Without this optimization the opening of a TCP
connection after a traffic lull would initiate probes even though the
subsequent three-way handshake would provide a reachability confirmation
almost immediately.

Probe messages are rate limited.  Consecutive probe messages to the same
neighbor MUST be separated by a delay of at least REACHABLE_RETRANS_TIME
seconds.  The actual inter-probe delay depends on the traffic pattern;
probe MUST be sent when a packet is sent to the neighbor and
REACHABLE_RETRANS_TIME seconds has passed since sending the previous
probe.

Probe messages sent while in PROBE status are unicast to the neighbor
using the cached link-layer address.  Probes that are sent in
TRY_ALTERNATES state are multicast to the solicited-node address just
like regular Neighbor Solicitations are when resolving the link-layer
address.

After CONSECUTIVE_UNICAST_PROBES probes have been sent without receiving
any reachability confirmation, the neighbor state should be changed from
PROBE status to TRY_ALTERNATES and the node should attempt to find an
alternate path.  This is accomplished by discarding the cached link-
layer address and invoking the next-hop determination procedure
(described in Section 4.2) for the packet.  If the next-hop is being



draft-ietf-ipngwg-discovery-00.txt                             [Page 41]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


used as a router, performing the next-hop calculation may result in
selecting another default router.  If the destination was thought to be
on-link, but the set of on-link prefixes has changed, recalculating the
next-hop may result in a switch to a router.  In other cases the next-
hop determination might find that the neighbor is still presumed to be
on-link in which case the regular Address Resolution mechanism will be
invoked; that mechanism will then multicast Neighbor Solicitations to
the neighbor.

If a packet is about to be sent to a neighbor whose status is already
TRY_ALTERNATES, the packet should not be sent.  Instead the next-hop
determination should be invoked for the destination in order to select a
different next-hop as above.  This case occurs when multiple Next-Hop
Cache entries refer to the same Neighbor Cache entry and the use of one
of the next-hop entries has previously resulted in transitioning to
TRY_ALTERNATES status.  In this case other next-hops using the same
neighbor should attempt to find an alternate path immediately when
sending the next packet.

In addition to being used when sending packets to a neighbor, Neighbor
Unreachability Detection is also invoked by the default router selection
policy in section 5.3.3 to send a probe message without actually sending
a data packet.  In this case the reachability status is TRY_ALTERNATES
and the node should multicast a Neighbor Solicitation to the solicited-
node address as an attempt to receive a reachability confirmation for
the default router.

To detect a router that switches from being a router to being a host
(e.g, by having its IP forwarding capability turned off by system
management), a node MUST compare the Code field of all received Neighbor
Advertisement messages with the "is_router" flag recorded in the
Neighbor Cache entry.  When a node detects that a neighbor has changed
from being a router to being a host, the node MUST remove that router
from the Default Router List and update the Next-Hop Cache so that all
entries using that neighbor as a router switch to another router.  Note
that a router may not be listed in the Default Router List, but still
have Next-Hop Cache entries using it, if a host was redirected to it.

An algorithmic specification of the above mechanism is presented in
section 6.3.4.


6.3.3.  Reachability State

For the purpose of describing the Neighbor Unreachability Detection
algorithm, this document uses the following state-related variables for
each neighbor:




draft-ietf-ipngwg-discovery-00.txt                             [Page 42]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


   - the number of consecutive unanswered Neighbor Solicitation probes.

   - a "time-of-next-event" event timer that specifies when some action
     must be taken.  Note that in contrast to timers used by e.g.
     transport protocols for scheduling retransmissions, this timer does
     not trigger event processing at the time at which it expires.
     Instead, it is examined only when a packet is being transmitted to
     the neighbor.  This on-demand event processing can be implemented
     by comparing the current time with the time-of-next-event whenever
     a neighbor entry is referenced while sending a packet.

   - a status variable that take one of the values REACHABLE, PROBE, or
     TRY_ALTERNATES as defined informally in section 4.1.  This variable
     is primarily used to add clarity to the specification.  An
     implementation might only need to keep track the number of
     unanswered probes and the time-of-next-event timer; they can be
     made to implicitly define the current status.


A node MUST track the above state on a per-neighbor basis.  In
particular, a node MUST maintain a single Neighbor Cache entry for a
router even though many Next-Hop Cache entries might refer to the same
router, in order to avoid redundant probing of the router.


6.3.4.  Algorithm

When a node is confirmed reachable, its status is set to REACHABLE, its
time-of-next-event is set to the current time plus REACHABLE_TIME and
the count of consecutive unanswered probes is set to -1.

All other actions in Neighbor Unreachability Detection take place when
sending or attempting to send packets to the neighbor.  Note that no
actions are triggered by an explicit timeout.

Whenever a packet is sent to a neighbor, the current time is compared to
the time-of-next-event.  If the time-of-next-event exceeds the current
time, the node performs the following actions based on the current
state:

  1) If the status is REACHABLE, change the status to PROBE, set the
     number of unanswered probes to 0, set time-of-next-event to current
     time plus DELAY_FIRST_PROBE_TIME, and send the packet.  No probe is
     sent.  This is the optimization that defers the sending of any
     probe until the upper-layer has had a reasonable time to provide a
     reachability confirmation.

  2) If the status is PROBE and less than CONSECUTIVE_UNICAST_PROBES



draft-ietf-ipngwg-discovery-00.txt                             [Page 43]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


     have been sent, send a unicast Neighbor Solicitation to the cached
     link-layer address, increment the number of probes, and send the
     packet.  Set time-of-next-event to current time plus
     REACHABLE_RETRANS_TIME.  This ensures that the next probe will not
     be sent until at least REACHABLE_RETRANS_TIME seconds have elapsed,
     rate-limiting consecutive probe messages for the neighbor to at
     most one message every REACHABLE_RETRANS_TIME seconds.

  3) If the status is PROBE and CONSECUTIVE_UNICAST_PROBES have been
     sent, the neighbor is likely to be unreachable.  Change the status
     to TRY_ALTERNATES, discard the cached link-layer address, and
     perform next-hop determination for the destination.  The packet is
     then sent using the (potentially different) next hop that resulted
     from the next-hop determination.


In addition, when sending a packet the reachability state of the
neighbor SHOULD be always checked, independently of the time-of-next-
event, to be able to quickly perform next-hop determination when the
status is TRY_ALTERNATES.  When status is TRY_ALTERNATES a next-hop
determination is always performed and the packet is then sent using the
determined next-hop.


If the Neighbor Unreachability Detection is invoked from the default
router selection policy (section 5.3.3) this check should be performed:

  - If the status is TRY_ALTERNATES and time-of-next-event is exceeds
     the current time, then multicast a probe to the solicited-node
     multicast address corresponding to the neighbor's address,
     increment the number of probes, and set time-of-next-event to the
     current time plus DEFAULT_RTR_PROBE_INTERVAL.  This will solicit a
     default router for a reachability confirmation at most every
     DEFAULT_RTR_PROBE_INTERVAL while a different, known to be
     reachable, default router is selected by the default router
     selection policy.



7.  REDIRECT FUNCTION

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


7.1.  Redirect Message Format

A Redirect packet is sent from a router to a host to inform the host of



draft-ietf-ipngwg-discovery-00.txt                             [Page 44]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


a better first-hop node on the path to a destination.

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                       Target Address                          +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                     Destination Address                       +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Extensions ...
     +-+-+-+-+-+-+-+-+-+-+-+-

IPv6 Fields:

   Source Address
                  The designated IP address of the interface from which
                  this message is sent.

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

   Hop Count      1

   Authentication Header
                  If a security association exists between the sender
                  and the destination the sender SHOULD include this
                  header.

IPv6 ICMP Fields:

   Type           5

   Code



draft-ietf-ipngwg-discovery-00.txt                             [Page 45]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


                  0              If the target is a host.
                  1              If the target is a router.

   Checksum       The ICMPv6 checksum.  See [ICMPv6].

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

   Target Address An IP address of the node to which traffic for the
                  Destination SHOULD be sent.  When the target is a
                  router this MUST be the router's designated address on
                  the link.  This is required so that hosts can uniquely
                  identify the routers by their designated address.

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

Extensions:

   Target link-layer address
                  The link-layer address for the target.  It SHOULD be
                  included on link layers that have addresses, if known.

   Redirected Header
                  As much as possible of the IPv6 packet that triggered
                  the sending of the Redirect without making the
                  redirect packet exceed 576 octets.

   Future versions of this protocol may define new extension types.
   Receivers MUST skip over and ignore any extensions they do not
   recognize and continue processing the message.


7.2.  Router Specification

A router SHOULD send a redirect message, subject to rate limiting,
whenever it forwards a packet in which:

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

   - after consulting its routing table, the router forwards the packet
     to a node residing on the same link as the packet's source, and

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

   - the packet is not source routed through the router.  A packet is
draft-ietf-ipngwg-discovery-00.txt                             [Page 46]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


     source routed through the router if, when the packet is received by
     the router, it contains the IPv6 route header and the router's
     address is in the Destination Address field.


The transmitted redirect packet contains, consistent with the above
message format:

   - In the ICMP Code field: set to 0 if the target is a host and 1 if
     it is a router.

   - In the Target Address field: the address to which subsequent
     packets for the destination SHOULD be sent.  If the target is a
     router this MUST be set to the target's designated address on the
     link.

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

   - In the extension fields:

     Target Link-Layer Address extension: link-layer address of the
          target, if known.

     Redirected Header:  as much of the forwarded packet as can fit
          without the redirect packet exceeding 576 octets in size.

A router MUST limit the rate of Redirect messages 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.
Examples of how to implement such a rate-limiting function are in
[ICMPv6].

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


7.3.  Host Specification


7.3.1.  Message Validation by Hosts

A host MUST silently discard any received Redirect messages that do not
satisfy the following validity checks:

   - ICMP Checksum is valid.

   - ICMP Code is 0 or 1.



draft-ietf-ipngwg-discovery-00.txt                             [Page 47]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


   - 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 destination.

   - the Target Address of the redirect is not a multicast address.

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

   - if the message includes an Authentication Header, the message is
     correctly authenticated.

   - all included extensions have a length that is greater then zero.


The contents of the Reserved field, and of any unrecognized extensions
MUST be ignored.  Future, backward-compatible changes to the protocol
may specify the contents of the Reserved field or add new extensions;
backward-incompatible changes may use different Code values.

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.

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


7.3.2.  Host Behavior

A host receiving a valid redirect SHOULD update its routing information
accordingly.  When a redirect is received the host updates the Next-Hop
Cache entry for the destination to point to the target.  If no Next-Hop
Cache entry exists for the destination such an entry is created.

If the redirect contains a Target Link-Layer Address extension the host
either creates or updates the Neighbor Cache entry for the target.  The
link-layer address in the Neighbor Cache entry MUST be copied from the
Target Link-Layer Address extension.  In addition, if the Code in the
redirect is set to 1 the "is_router" flag is set to true in the Neighbor
Cache entry.  Otherwise the "is_router" flag SHOULD be set to false.

A host MAY ignore a Redirect message that does not have an IPv6
Authentication header.

A host MUST NOT send Redirect messages.






draft-ietf-ipngwg-discovery-00.txt                             [Page 48]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


8.  EXTENSIONS

Extensions provide a mechanism to encode variable length as well as
optional pieces of information in the different ND packets.

Extensions can also be used to add additional functionality to ND.
Examples of potential future functionality is better support for links
with asymmetric connectivity and better support for NBMA links that use
"address resolution servers" in IPv4.

In order to ensure this extensibility all nodes MUST skip over any
extensions they do not recognize in received ND packets and continue
processing the packet.  However, the extensions specified in this
document MUST be implemented by all implementations.

The current set of extensions are defined in order to allow receivers to
process multiple extensions in the same packet independently of each
other.  In order to maintain these properties future extensions SHOULD
follow the simple rule:

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

This constraint allows receivers to process extensions independently
(e.g., an implementation can choose to process the Prefix Information
extension in a Router Advertisement message in a user-space process
while the link-layer address in the same message is recorded by the
kernel).

The constraint can also be useful should we ever need to send more
extensions then can fit in a single packet; multiple packets can carry
subsets of the extensions without any change in semantics.

When multiple extensions are present in a Neighbor Discovery packet,
they may appear in any order; receivers MUST be prepared to process them
independently of their order.

Senders MAY send a subset of extensions in different packets.  For
instance, if the prefix Invalidation Lifetime is high it might not be
necessary to include the Prefix Information extension in every Router
Advertisement.  In addition, different routers might send different sets
of extensions.  Thus, a receiver MUST NOT associate any action with the
absence of an extension 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.




draft-ietf-ipngwg-discovery-00.txt                             [Page 49]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


All extensions have a length that is a multiple of 8 octets.  This makes
it simple to ensure appropriate alignment without any "pad" extensions.
The fields in the extensions, as well as the fields in the ND packets,
are defined to align on their natural boundaries (e.g. a 16-bit field is
aligned on a 16-bit boundary) except the 128-bit IP addresses/prefixes
which are aligned on a 64-bit boundary.

The link-layer address field contains an octet string thus it is only
aligned on an 8-bit boundary.

All extensions are of the form:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Extension   |    Length     |              ...              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                              ...                              ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fields:

   Extension      8-bit identifier of the type of extension.  The
                  extensions defined in this document are:

                        Extension Name                        Extension

                     Source Link-Layer Address                    1
                     Target Link-Layer Address                    2
                     Prefix Information                           3
                     Redirected Header                            4
                     Suggested Hop Limit                          5
                     Neighbor Unreachability Detection Timer      6
                     MTU                                          7

   Length         8-bit unsigned integer.  The length of the extension
                  in units of 8 octets.  The value 0 is invalid.  Nodes
                  MUST silently discard an ND packet that contains an
                  extension with length zero.

The size of an ND packet including the IP header is limited to the link
MTU (which is at least 576 octets).  When adding extensions to an ND
packet a node MUST NOT exceed the link MTU.  This is handled in a packet
specific manner.

The only ND packets that currently can exceed the link MTU are Router
Advertisements and Redirects; the former due a large number of Prefix
Information extensions and the latter due to the Redirected Header
extension.




draft-ietf-ipngwg-discovery-00.txt                             [Page 50]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


If there are more Prefix Information extensions than can fit in a single
Router Advertisement packet the router MUST send multiple separate
advertisements that each contain a subset of the set of prefixes.

In a Redirect packet the amount of data included in the Redirected
Header MUST be limited so that the packet does not exceed 576 octets.


8.1.  Source/Target Link-layer Address

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Extension   |    Length     |            Family             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Addr. Length  |    Link-Layer Address ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Fields:

   Extension
                  1 for Source Link-layer Address
                  2 for Target Link-layer Address

   Length         The length of the extension in units of 8 octets.  For
                  example, the length with IEEE 802 addresses is 2.

   Family         The link-layer Address Family Number.  Up-to-date
                  values are specified in the most recent "Assigned
                  Numbers RFC" [RFC-1700].

   Addr. Length   The length of the actual link-layer address.  The unit
                  for this length depends on the Address Family.

                  The address length field is in units of octets except
                  for those families for which it is in the unit of
                  nibbles (4-bits):
                     E.163
                     E.164 (SMDS, Frame Relay, B-ISDN)
                     F.69 (Telex)
                     X.121 (X.25, Frame Relay)

   Link-Layer Address
                  The variable length link-layer address.  The Link-
                  Layer Address is always specified in Canonical order.

                  The content of this field beyond the length specified
                  by the address length field is unspecified and MUST be
                  ignored by the receiver.




draft-ietf-ipngwg-discovery-00.txt                             [Page 51]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


Description
                  The Source Link-Layer address extension 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 extension contains the
                  link-layer address of the target.  It is used in in
                  Neighbor Advertisement and Redirect packets.


8.2.  Prefix Information

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Extension   |    Length     | Prefix Length |L|A| Reserved1 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Invalidation Lifetime                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Deprecation Lifetime                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved2                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                            Prefix                             +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fields:

   Extension      3

   Length         3

   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.

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




draft-ietf-ipngwg-discovery-00.txt                             [Page 52]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


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

   Invalidation Lifetime
                  32-bit unsigned integer.  The lifetime of the prefix
                  in seconds for the purpose of on-link determination.
                  This lifetime is also used by [ADDRCONF].

   Deprecation Lifetime
                  32 bits reserved for automatic address configuration.
                  See [ADDRCONF].

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

   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.

Description
                  The Prefix Information extension is only used in
                  Router Advertisement packets.  It provide hosts with
                  on-link prefixes and prefixes for Address
                  Autoconfiguration.


8.3.  Redirected Header

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Extension   |    Length     |            Reserved           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                     IPv6 header + data                        ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fields:

   Extension      4

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

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

   IPv6 header + data



draft-ietf-ipngwg-discovery-00.txt                             [Page 53]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


                  The original packet truncated to ensure that the size
                  of the redirect message does not exceed 576 octets.

Description
                  The Redirected Header extension MUST be included in
                  Redirect packets.


8.4.  Suggested Hop Limit

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Extension   |    Length     |     Hops      |    Reserved   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fields:

   Extension      5

   Length         1

   Hops           8-bit unsigned integer.  The suggested hop limit.

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

Description
                  The Suggested Hop Limit extension MAY be included in
                  Router Advertisement packets.

                  Hosts SHOULD handle this extension by computing the
                  default Hop Limit as the maximum of all received
                  Suggested Hop Limit extensions while ignoring those
                  received from routers that have been timed out from
                  the Default Router List.


8.5.  Neighbor Unreachability Detection Timer

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Extension   |    Length     |     Timer     |    Reserved   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fields:




draft-ietf-ipngwg-discovery-00.txt                             [Page 54]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


   Extension      6

   Length         1

   Timer          8-bit unsigned integer.  The suggested Neighbor
                  Unreachability Detection timer in seconds.

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

Description
                  The Suggested Neighbor Unreachability Timer extension
                  MAY be included in Router Advertisement packets.

                  Hosts SHOULD handle this extension by computing the
                  REACHABLE_TIME as the minimum of all received
                  Suggested Neighbor Unreachability Timers while
                  ignoring those received from routers that have been
                  timed out from the Default Router List.

                  If no Suggested Neighbor Unreachability Timer
                  extension has been received (e.g. due to no routers on
                  the link) the node MUST use the protocol constant
                  defined in section 10.




8.6.  MTU

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Extension   |    Length     |              MTU              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fields:

   Extension      7

   Length         1

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

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




draft-ietf-ipngwg-discovery-00.txt                             [Page 55]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


Description
                  The MTU extension SHOULD be included in Router
                  Advertisement packets when the link has no well-known
                  MTU and it MAY be included on links with a well-known
                  MTU.

                  Hosts that operate on a link that does not have a
                  well-defined MTU MUST handle this extension by
                  computing the MTU of the link as the minimum of
                  received MTU extensions while ignoring those received
                  from routers that have been timed out from the Default
                  Router List.




9.  MULTIHOMED HOSTS

There are some special Neighbor Discovery rules and constraints that
apply only to hosts that have multiple interfaces.  Note that this
section explicitly does not attempt to define the operation of
multihomed hosts.  It serves merely to point out some ND issues for
multihomed hosts.

If a multihomed host hears no Router Advertisements at all (i.e. on none
of its interfaces) the host can not determine which interface to use
when sending packets.  (A host with only one interface would assume that
all destinations are on-link in this case.) Therefore multihomed hosts
require that they can receive Router Advertisement on at least one of
their interfaces.  The exception to this is when the multihomed host is
manually configured with the on-link prefixes for its interfaces.

If a multihomed host hears routers on a subset of its interfaces it will
not send packets out any of the interfaces that do not have a router
since it will not have received any prefixes for those links.  Once
again, the exception to this is when the multihomed host is manually
configured with the on-link prefixes for the links that have no routers.

If a multihomed host hears no Prefix Information extensions from its
routers it will not be able to make optimal interface selection when
communicating with neighbors; without the prefixes the host can not tell
which nodes are neighbors on which interfaces.  It is recommended, and
on multicast links required, that routers always advertise the on-link
prefixes for the benefit of multihomed hosts.
draft-ietf-ipngwg-discovery-00.txt                             [Page 56]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


10.  PROTOCOL CONSTANTS

Router constants:
         MAX_INITIAL_RTR_ADVERT_INTERVAL  16 seconds

         MAX_INITIAL_RTR_ADVERTISEMENTS    3 transmissions

         MAX_RTR_RESPONSE_DELAY            2 seconds

Host constants:

         MAX_RTR_SOLICITATION_DELAY        1 second

         RTR_SOLICITATION_INTERVAL         3 seconds

         MAX_RTR_SOLICITATIONS             3 transmissions

Node constants:

        RESOLVE_RETRANS_TIMER              1 second

        UNREACHABLE_THRESHOLD             10 transmissions

        MAX_NEIGHBOR_ADVERTISEMENTS        3 transmissions

        MIN_NEIGHBOR_ADVERT_INTERVAL      16 seconds

        REACHABLE_TIME                    30 seconds

        REACHABLE_RETRANS_TIME             1 second

        DEFAULT_RTR_PROBE_INTERVAL         4 seconds

        DELAY_FIRST_PROBE_TIME             4 seconds

        CONSECUTIVE_UNICAST_PROBES         4 transmissions


Additional protocol constants are defined with the message formats in
Section 5.1, 6.1, and 7.1.

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


11.  SECURITY CONSIDERATIONS

The Neighbor Discovery protocol packet exchanges can be authenticated



draft-ietf-ipngwg-discovery-00.txt                             [Page 57]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


using the IPv6 Authentication Header [IPv6-AUTH].

It MUST 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.

The trust model for redirects is based only trusting a redirect received
from the current first hop node.  It is natural to trust the routers on
the link.  If a host has been redirected to another host (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.

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


































draft-ietf-ipngwg-discovery-00.txt                             [Page 58]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


REFERENCES


  [ADDRCONF]  S. Thomson, "IPv6 Address Autoconfiguration", Internet
          Draft.

  [ADDR-ARCH]  S. Deering, R. Hinden, Editors, "IP Version 6 Addressing
          Architecture", Internet Draft.

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

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

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

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

  [ICMPv6]  A. Conta, and S. Deering, "ICMP for the Internet Protocol
          Version 6 (IPv6)", Internet Draft.

  [IPv6]  S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6
          (IPv6) Specification", Internet Draft.

  [IPv6-SA] R. Atkinson.  IPv6 Security Architecture.  Internet Draft,
          March 1995.

  [IPv6-AUTH] R. Atkinson.  IPv6 Authentication Header.  Internet Draft,
          March 1995.

  [IPv6-ESP] R. Atkinson.  IPv6 Encapsulating Security Payload.
          Internet Draft, February 1995.

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

  [SH-MEDIA] R. Braden, J. Postel, Y. Rekhter, "Internet Architecture
          Extensions for Shared Media", RFC 1620, May 1994.










draft-ietf-ipngwg-discovery-00.txt                             [Page 59]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


AUTHORS' ADDRESSES

     Erik Nordmark                Thomas Narten
     Sun Microsystems, Inc.       IBM Corporation
     2550 Garcia Ave              P.O. Box 12195
     Mt. View, CA 94041           Research Triangle Park, NC 27709-2195
     USA                          USA

     phone: +1 415 336 2788       phone: +1 919 254 7798
     fax:   +1 415 336 6015       fax:   +1 919 254 4027
     email: nordmark@sun.com      email: narten@vnet.ibm.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






























draft-ietf-ipngwg-discovery-00.txt                             [Page 60]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


CHANGES SINCE PREVIOUS DOCUMENT


     This version of the "IPv6 Neighbor Discovery" includes several
     changes from the previous version documented in:

          <draft-simpson-ipv6-discov-formats-02.txt>, and
          <draft-simpson-ipv6-discov-process-02.txt>

     The changes agreed to at working group meetings at Xerox Parc and
     at Danvers IETF:
          o Renamed the Media-Access extension to be the Link-Layer
            Address extension.

          o Use of different extensions for addresses that refer to the
            sender of the packet and the receiver instead of using the
            Known-Identifier extension for both.

          o Changed the processing of General/Neighbor Solicitation in
            order to achieve 2 packet exchange just like ARP.

          o Removed the Node-Heard extension.

     Other changes:
          o Merged the processing and format documents into a single
            document with an extensive introduction to the protocol.

          o Aligned the document with [ADDRCONF].  In particular this
            implied the removal of the Change-Identifier extension.

          o Off-link prefixes are not advertized in Router
            Advertisements (no simple routing protocol).  This removes
            the need for a preference in the Prefix Information
            extension.

          o Specified a more detailed Neighbor Unreachability Detection
            algorithm (used to be called Dead Node Detection).

          o Removed the lifetime field from Neighbor Advertisements.
            The protocol uses Neighbor Unreachability Detection to time
            out state created by Neighbor Advertisements.

          o Removed the Maximum Receive Unit fields from packets since
            per-node MTU (or MRU) links do not work with multicast.
            Instead routers send an MTU extension in order to handle
            links that do not have a well-defined MTU.

          o Changed alignment mechanisms for extensions.  All extensions



draft-ietf-ipngwg-discovery-00.txt                             [Page 61]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


            are a multiple of 8 octets.  Thus there is no longer a need
            for pad extensions.

          o Added support for anycast addresses.

          o Removed the ability to redirect prefixes to simplify host
            processing.

          o Removed lingering mobility support (Mobility-Support
            extension and Remote Redirect message.)

          o All messages have separate ICMP types.  Redirect type is now
            in the error range (<128) and the others in the information
            range (>=128)

          o Moved fixed-length fields that are always present in a
            particular type of packet into the fixed header.

          o Renamed "General" Solicitation/Advertisement to "Neighbor"
            Solicitation/Advertisement.

          o Changed the default Router Advertisement period from 30
            seconds to 600 seconds; same value as in RFC-1256.  This
            change is possible since Neighbor Unreachability Detection
            will detect unreachable routers and switch a reachable
            router independent of the frequency of the Router
            Advertisements.

          o Specified rules for when a node should generate ICMP address
            unreachable errors due to Address Resolution failures.





















draft-ietf-ipngwg-discovery-00.txt                             [Page 62]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


OPEN ISSUES

Misc issues:

 - The protocol currently recommends (SHOULD) that nodes generate ICMP
   Address Unreachable errors when Address Resolution fails.  The
   protocol requires that nodes retransmit Neighbor Solicitations in
   order to be able to generate such ICMP errors.  ARP does not require
   retransmission of ARP requests.

   Is the utility of such errors high enough to warrant the use of a
   retransmission timer?  Tools like 'ping' would report "Address
   Unreachable" errors instead of no response and end users would
   possibly see "Address Unreachable" errors rather than "timed out".
   In some cases applications might be able to try alternate addresses
   more quickly during connection opens.  The latter may become more
   important as addresses come and go more quickly.


(Designated) addresses:

 - ND requires that routers know the designed address for all other
   routers attached to the same link.  Is this a reasonable requirement?
   What mechanism can routers use to learn this designated address from
   their peers?  (routing protocols?, receiving Router Advertisements?)

 - Should we require that the source addresses of all Neighbor Discovery
   packets be link-local?  Link-local source addresses provides an extra
   level of robustness by preventing off-link nodes from generating
   bogus ND packets (assuming that routers don't forward packets with a
   link-local source address).  This is more of an issue in v6 than v4
   because v6 depends on ND messages to decide which destinations are
   on-link.  Such a requirement would assume that link-local addresses
   exist on all types of links.

 - Can we assume that a booting node will always be able construct a
   link-local address before it sends out a Router Solicitation packet?
   Routers ignore Router Solicitations from the unspecified IP address.

 - Should we change the solicited-node multicast address range from
   FF02::0700-FF02::07FF to FF02::0100-FF02::01FF?  Why was "07"
   selected?


Support for redundant (replicated) interfaces:

 - Nodes can have redundant interfaces on the same link; how quickly
   does a neighbor have to be able to switch from using the link-layer



draft-ietf-ipngwg-discovery-00.txt                             [Page 63]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


   address of a faulty interface to another interface?  The current
   specification has a separate mechanism that is only used to speed up
   this case: The use of multicast Neighbor Advertisements.

   Can we just make NUD aggressive enough to detect the link layer
   address change, and remove the extra mechanism?

   The Neighbor Unreachability Detection as currently specified will
   detect the link-layer address change but the switch over time is
   probably on the order of 1 minute.


NUD issues:

 - Is the Neighbor Unreachability Detection algorithm simple enough?  Is
   the description understandable?

 - Currently only routers use designated addresses as source.  If hosts
   have multiple addresses the NUD algorithm will treat each address as
   a separate neighbor, potentially causing redundant NUD probes.

   Should NA messages we changed to list all of a node's addresses so
   that hosts can keep track of the "equivalence class" of addresses
   that correspond to a single neighbor?

 - How long should we retain the link-layer address after consecutive
   probes go unanswered?  Should we keep the address when going to the
   TRY_ALTERNATES status in order to continue sending packets to the
   link-layer address even though explicit probes are not generating the
   desired reachability confirmation?

 - What are the good values for various thresholds and timers that are
   used by NUD?  Do some of these values have to be dynamic and/or
   settable by parameters in Router Advertisements in order to handle
   links with widely varying bandwidth and propagation delay?


ND support for mobility:

 - What base level support does the (yet to be defined) mobility scheme
   require from ND, if any?  In particular, what support is needed to
   handle mobiles that move off-link?

   This specification suggests using proxy Neighbor Advertisements for
   mobile nodes that move off-link since the proxy mechanism is very
   simple to implement in the hosts and it is already needed to support
   anycast addresses.




draft-ietf-ipngwg-discovery-00.txt                             [Page 64]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


   There is concern that proxy responses are hard to trust i.e. to make
   secure using authentication.  An alternate model, which appears to be
   more complex, is to require that hosts switch to sending packets to a
   default router after Address Resolution and Neighbor Unreachability
   Detection fails.

   There are two key differences between using a multicast Neighbor
   Solicitation with a proxy response and just sending the packet to one
   of the default routers:
    - The latter requires that the routers maintain a well-synchronized
      distributed database since any router might receive a packet for
      any mobile.  In the former scheme is it possible to partition the
      database; each router can support a subset of the mobiles and
      respond to solicitations for those nodes.
    - The latter requires that all default routers participate in the
      mobility handling i.e. the distributed database.  Even though we
      want all routers to be capable of acting as "home agents" an
      administrator might only enable this in a subset of the routers on
      the link.  One reason for using a subset is that it presumably
      would reduce the database synchronization traffic.

   If all default routers on a link MUST participate in the mobility
   support you don't have to add any complexity to the hosts.  However,
   this might not be a realistic assumption.

   Without this assumption, if you want the host to send to a default
   router after a NUD failure for an on-link destination the host has to
   be able to somehow handle default routers that are not in sync with
   the mobility database.  This means that the host probably has to
   ignore (for some time after the NUD failure) a redirect that tells it
   that the destination is on-link and instead try a different default
   router.

   An alternative would be for hosts to know which default routers are
   "mobility aware" and only used those routers after a NUD failure.

 - How quickly does a node have to detect that a mobile neighbor has
   moved off-link?  Can we just use NUD, as the protocol currently does,
   to detect this or do we need faster mechanisms?  The Neighbor
   Unreachability Detection will detect the link-layer address change
   but the switch over time is probably on the order of 1 minute.

   Does mobility require a ND mechanism for mobile nodes to send a
   message that in effect says "I'm leaving the link, use the following
   agent instead"?

   Should the protocol allow multicast Neighbor Advertisement as an
   unreliable way of updating neighbors when a mobile has moved off-



draft-ietf-ipngwg-discovery-00.txt                             [Page 65]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


   link?  This adds complexity and traffic especially when nodes have
   multiple IP addresses per interface.


NBMA/ATM link support:

 - What additional support or additional text, if any, should the
   document contain about address resolution servers? (as used on ATM
   and SMDS; RFC-1577)

   One solution that is supported by ND as specified is to

   1) manually configure a Default Router List (which includes
      configuring the link-layer addresses of the routers), and

   2) not configure any on-link prefixes.

   This will make hosts send to the default routers and get redirected.
   The manually configured default routers could be the AR servers
   (which would redirect to the "real" routers), or every router could
   contain AR server functionality.

   The protocol as currently specified does not support the "inverse
   ARP" functionality in RFC 1577, which is used for

    - AR servers determining the IP addresses of the hosts, and

    - determining the peer's IP addresses on PVCs.

   A protocol extension could presumably be made either to have hosts
   periodically unicast NA to each default router on such networks, or
   allow unicast NS for the unspecified address.  Do we want to address
   this issue?  Should it be addressed in this document or can it be
   handled in a future document?

 - How should ND specify ATM link-layer addresses that consist of an
   E.164 address plus an NSAP address?  This is one of the address
   formats supported by RFC-1577.  Is this form of address likely to
   ever be used?


Packet format issues:

 - The extensions for MTU, NUD timer and hop-limit are not very space
   efficient.  Should they be merged into a single extension?  Should
   they be placed in the fixed part of the Router Advertisement packet?
   Both changes assume that we define a designated value for
   "unspecified" (e.g. 0) when the routers have nothing to say.



draft-ietf-ipngwg-discovery-00.txt                             [Page 66]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


 - The protocol specifies that Code = 0/1 is used in Neighbor
   Solicitation, Neighbor Advertisement, and Redirect messages to allow
   the receiver of the packet determine if the source (or redirection
   target in the case of a redirect) is a router or a host.  This is
   strictly speaking only necessary in the Neighbor Advertisement
   message.  The information is used by Neighbor Unreachability
   Detection to detect when a router has been converted to a host.
   Should the Code 0/1 distinction only be used in Neighbor
   Advertisements?

 - How should link-layer addresses be encoded in the link-layer address
   extensions, in particular the addresses that consist of a string of
   decimal digits?  (Such as E.164 addresses.)  The current
   specification states that the family value implicitly defines whether
   the address length is in the unit of nibbles or bytes.  Alternatives
   are:

    - Have an explicit flag that specifies "length is in nibbles" vs.
      "length is in bytes".

    - Always use nibbles as the unit (e.g. an IEEE 802 address would be
      12 nibbles long).

    - Require that the decimal digit strings be encoded as one digit per
      byte (instead of BCD encoding) to force everything to be in units
      of bytes.



Other protocol processing issues:

 - San Jose IETF resulted in millisecond granularity for lifetimes in
   order to match SNMP timer values.  The February WG meeting at Xerox
   Parc resulted in extending them from 16 to 32 bits.  What do we want
   to do?

   The current proposal has a 32-bit invalidation lifetime in seconds
   for prefixes and a 32-bit deprecation lifetime which is only used by
   [ADDRCONF].

 - Power failure scenario: Should the protocol require that routers
   multicast delayed Router Advertisements in response to Router
   Solicitations in order to reduce the number of Router Advertisements
   when all hosts boot during a short time interval?  The current
   specification says "MAY".

 - Changes in advertised prefixes: Routers might want to send out
   immediate advertisements when the set of advertised prefixes changes.



draft-ietf-ipngwg-discovery-00.txt                             [Page 67]


INTERNET-DRAFT          IPv6 Neighbor Discovery                 May 1995


   Should the protocol allow this and, if so, what are the time
   constraints?  (how frequently can this be done, etc)


Security issues:

 - Proxy Neighbor Advertisements do not fit the trust model.  Even if
   they are authenticated it is not possible for a host to determine if
   the router has authority to proxy for the target.  We might be able
   to fix this by requiring that only routers (on the Default Router
   List) be allowed to send proxy responses.

 - What is the trust model for anycast addresses i.e. how does a node
   know that a neighbor can claim to offer the anycast service?

 - Should the authentication requirements be higher for Redirect
   messages than for other ND messages?  Redirects can easily be used
   for denial of service attacks.

 - Should ND somehow prefer authenticated packets over non-authenticated
   packets? (e.g. Neighbor Advertisements for the same target)

 - What is the trust model for Router Advertisements i.e. in the
   presence of authentication how does a host now which neighbors are
   authorized to send Router Advertisements?


























draft-ietf-ipngwg-discovery-00.txt                             [Page 68]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/