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

Versions: 00 01 02

Network Working Group                                        W A Simpson
Internet Draft                                                Daydreamer
expires in six months                                       October 1994


                 IPv6 Neighbor Discovery -- Processing
               draft-simpson-ipv6-discov-process-00.txt



Status of this Memo

   This document is a submission to the IPng Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the ipng@sunroof.eng.sun.com mailing list.

   Distribution of this memo is unlimited.

   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 not appropriate to use Internet Drafts as
   reference material, or to cite them other than as a ``working draft''
   or ``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).


Abstract

   This document discusses the techniques for identification of and
   forwarding to adjacent IPv6 nodes, including Next Hop Determination
   and Router Discovery.










Simpson                  expires in six months                  [Page i]


DRAFT                   IPv6 Neighbor Discovery             October 1994


1.  Introduction

   This document describes how to process ICMP Neighbor Discovery
   messages

   -  to determine the availability of other IPv6 nodes as demand for
      communication occurs;

   -  to detect the presence of available IPv6 routers;

   -  to learn the appropriate media address for sending to its
      neighbors;

   -  and to self-configure using the Cluster prefix(es) for the link.

   The design requirements are more completely described in [D-sign].     |
   The ICMP packet formats are described in [D-form].



2.  Sending Datagrams

   The IPv6 node chooses the next hop for each datagram sent.  If the     |
   Destination can be readily determined to be on an attached link, the   |
   datagram is sent directly to the Destination.  Otherwise, it is sent
   to a router.



2.1.  Constants

      GENERAL_SOLICITATION_INTERVAL        3 seconds



2.2.  Hop Cache                                                           |

   To efficiently send a series of datagrams to the same Destination,     |
   each node MUST keep a cache of prior decisions, indexed by             |
   Destination.  The node uses the following basic algorithm on this      |
   cache to send a datagram:

   (a)   If the cache contains no information for a particular            |
         Destination, a determination is made where to send the
         datagram.  This is described in the "Next Hop Decision" section
         which follows.                                                   |

   (b)   When the cache contains information for a particular             |



Simpson                  expires in six months                  [Page 1]


DRAFT                   IPv6 Neighbor Discovery             October 1994


         Destination, the cache entry might point directly to the         |
         Destination, or to a router which handles the Destination.

   (c)   The cache entry contains the media address to be used to send    |
         the datagram.  It also contains other information which records  |
         previous experience related to the Destination.                  |

   (d)   When the Destination is determined to be accessible through a    |
         router, the cache entry for the router is used to send the
         datagram.  The router cache entry might be duplicated in the     |
         Hop Cache, or a system of pointers could be used.  In any case,  |
         the Hop Cache entry for the Destination MUST have the same       |
         LifeTime as the cache entry for the router.                      *

   Each Hop Cache entry needs to include the following items:             |

   (1)  LifeTime
   (2)  Next-hop interface (when a node is multi-homed)
   (3)  Next-hop media address
   (4)  Destination IPv6 Address
   (5)  Destination Cluster-prefix size
   (6)  Source IPv6 Address                                               |
   (7)  Flow Label
   (8)  Path Maximum Transmission Unit                                    |
   (9)  Path Round Trip Time                                              |

   While scanning or making changes to the Hop Cache entries, whenever    |
   the LifeTime expires in any entry that was created as a result of a
   received advertisement, that entry is discarded.

   Field (4) MAY be the full IPv6 Address of the Destination, or the      |
   Cluster which includes the Destination.  This is determined by the
   Cluster-prefix size in (5).

   Field (7) SHOULD be included, as it is related to the Source in (6).   |

   DISCUSSION:
      Each Hop Cache entry defines the end-points of an internetwork      |
      path.  Although the connecting path may change dynamically in an
      arbitrary way, the transmission characteristics of the path tend
      to remain approximately constant over a time period longer than a
      single typical host-host transport connection.  Therefore, a Hop    |
      Cache entry is a natural place to cache data on the properties of
      the path.

      Examples of such properties might be the maximum unfragmented
      datagram size, or the average round-trip delay measured by a
      transport protocol.  This data will generally be both gathered and



Simpson                  expires in six months                  [Page 2]


DRAFT                   IPv6 Neighbor Discovery             October 1994


      used by a higher layer protocol (that is, by TCP or by an
      application using UDP).  Experiments are currently in progress on
      caching path properties in this manner.

      There is no consensus on whether the Hop Cache should be keyed on   |
      destinations alone, or allow both node and Cluster addresses.
      Those who favor the use of only node identifiers argue that:

      (1)   Redirect messages will generally result in entries keyed on
            nodes.  The simplest and most general scheme would be to
            only use node identifiers.

      (2)   The internetwork layer may not always know the prefix-size
            for a Cluster address in a complex environment.

      (3)   The use of only node identifiers may allow the Internet
            architecture to be more easily extended in the future
            without any change to the hosts.

      The opposing view is that allowing a mixture of destination nodes   |
      and clusters in the Hop Cache:

      (1)   Saves memory space.

      (2)   Leads to a simpler data structure, easily combining the
            cache with the tables of default and static routes.

      (3)   Provides a more useful place to cache path properties.

      IMPLEMENTATION:
         The cache needs to be large enough to include entries for the
         maximum number of destinations that may be in use at one time.

         A Hop Cache entry may also include control information used to   |
         choose an entry for replacement.  This might take the form of a
         "recently used" bit, a use count, or a last-used timestamp, for
         example.  It is recommended that it include the time of last
         modification of the entry, for diagnostic purposes.

         An implementation may wish to reduce the overhead of scanning    |
         the Hop Cache for every datagram to be transmitted.  This may
         be accomplished with a hash table to speed the lookup, or by
         giving a connection-oriented transport protocol a "hint", or
         temporary handle on the appropriate cache entry, to be passed
         to the IP layer with each subsequent datagram.

         A static route is typically a particular preset mapping for      |
         Destination or Cluster into a particular next-hop router.  It



Simpson                  expires in six months                  [Page 3]


DRAFT                   IPv6 Neighbor Discovery             October 1994


         might also depend on the Type-of-Service.  Static routes would
         be setup by system administrators to override the normal
         automatic routing mechanism, and handle exceptional situations.
         However, any static routing information is a potential source
         of failure as configurations change or equipment fails.

         Although the Hop Cache, the lists of default routers, and a      |
         table of static routes are described as conceptually distinct,
         in practice they may be combined into a single "routing table"
         data structure.



2.3.  Next Hop Decision

   To decide if the destination is on an attached link, the following
   algorithm MUST be used:

   (a)   For a multicast destination, simply pass the datagram to the
         link-layer for any indicated interface(s).

   (b)   If no Router Advertisements have been heard, then the            |
         Destination is assumed to be on an attached link.  For each      |
         interface, the Destination is located as described in the
         "Media Address Determination" section which follows.

   (c)   If one or more Router Advertisements have been heard, the        |
         Routing-Information extension Cluster-bit indicates whether the  |
         Cluster-prefix is confined to a single link.  The Destination    |
         is compared against the advertised Cluster-prefix.  When there   |
         is an exact match, then the Destination is assumed to be on      |
         that specific link.  The Destination is located as described in  |
         the "Media Address Determination" section which follows.         |

   (d)   If one or more Router Advertisements have been heard, but the    |
         Cluster-bit is not set, or the Destination does not exactly      |
         match the advertised Cluster-prefixes, then the datagram is
         sent to a single preferred router, as described in the "Router
         Selection" section which follows.                                |

   (e)   For a multi-homed node, when one or more Router Advertisements
         have been heard on some interfaces, but no Router
         Advertisements have been heard on other interfaces, the          |
         datagram is duplicated, and sent to both the preferred router    |
         and all those interfaces without routers for which a peer        |
         entity is unknown.                                               |

         This allows a node to continue operation in the presence of



Simpson                  expires in six months                  [Page 4]


DRAFT                   IPv6 Neighbor Discovery             October 1994


         private or partitioned links.  The correct interface will be
         learned through the advertisements of the target node.

   Every host MUST operate correctly in a minimal environment.  For
   example, if the host insists on finding at least one router to
   initialize, the host will be unable to operate on an isolated link.



2.4.  Media Address Determination

   When the media address for a destination is unknown, the following
   procedure is used:

   (a)   If the interface has no broadcast capability (a point-to-point   |
         link), and the peer entity is unknown, the datagram is sent on
         that interface.  No media address is needed.                     |

   (b)   If a virtual interface has no broadcast capability (a Frame-
         Relay or X.25 link), the datagram is duplicated on each virtual
         circuit for which there is no known peer entity, as if they
         were each a separate point-to-point interface on a multi-homed
         node.  The media address used is determined by the virtual       |
         circuit setup.                                                   |

   (c)   If an interface has no multicast capability, the datagram is
         sent as a link-layer broadcast.  Note that the IPv6 Destination
         is unchanged.                                                    |

   (d)   For an interface with multicast capability, the datagram is
         sent as a link-layer multicast.  Note that the IPv6 Destination
         is unchanged.

         The link-layer multicast address used is the exclusive-or of
         every octet of the IPv6 Destination, added to the base
         Solicited-Nodes multicast.  This distributes the processing
         load among 1/256 of the nodes, even when the nodes are not
         attached to a prefix routed link.                                |

   When there is no entry in the Hop Cache, a General Solicitation is     |
   sent immediately following the datagram, utilizing the same IPv6       |
   Destination as the datagram.  The same link-layer addressing rules of  |
   (a) to (d) apply.  A Hop Cache entry is added with a LifeTime of       |
   GENERAL_SOLICITATION_INTERVAL, to inhibit sending of repeated          |
   solicitations.                                                         |

   When there is already an entry in the Hop Cache for an unknown media
   address, no further solicitations are sent until the cache entry



Simpson                  expires in six months                  [Page 5]


DRAFT                   IPv6 Neighbor Discovery             October 1994


   expires.                                                               |

   On receipt of a unicast datagram from a unicast, broadcast or
   multicast media address, if the IPv6 Destination does not match any
   IPv6 IPv6 Address of the node, the datagram is silently discarded.

   On receipt of a General Solicitation, the target node sends a General
   Advertisement.

   On receipt of a General Advertisement, all nodes which have a Hop      |
   Cache entry for the Source update the cache entry with the current
   LifeTime and Media Address, and any other pertinent field values
   implemented.



2.5.  Router Selection

   To decide which router to send a datagram, the following procedure is
   used:

   (a)   Cluster-prefixes are learned from the Routing-Information
         extension of Router Advertisements.  The prefix-size is the
         number of valid bits in the Cluster-prefix.

   (b)   The Source field of the datagram is compared to the list of      |
         Cluster-prefixes in the Router List.

   (c)   If a Cluster-prefix exactly matches the Source prefix extracted
         by the same prefix-size, then that router is one of the
         preferred routers for that Source.  The node selects the
         highest preference value of those matching routers.

   (d)   If there are no matching Cluster-prefixes, then there is no
         preferred router for the Source.  The node selects the highest
         preference value among all routers.

   (e)   If that router is not the best next-hop to the Destination,      |
         that router will forward the datagram to the best next-hop, and  |
         return a Local Redirect message to the sending node.

   (f)   When the sending node receives a Local Redirect, it updates the  |
         next-hop in the appropriate Hop Cache entry, so that later       |
         datagrams to the same Destination will go directly to the best
         next-hop.

   Since the Cluster-prefix appropriate to the Destination address is
   generally not known, a Network Redirect message SHOULD be treated



Simpson                  expires in six months                  [Page 6]


DRAFT                   IPv6 Neighbor Discovery             October 1994


   identically to a Host Redirect message.  That is, the cache entry for
   the Destination (only) would be updated (or created when an entry for
   that node did not exist) for the new router.

   DISCUSSION:
      This recommendation is to protect against routers that erroneously
      send Network Redirects for a prefix routed link, in violation of
      the router requirements.  (Do we still have the Network
      Redirect???)



2.6.  Dead Node Detection

   The internetwork-layer MUST be able to detect the failure of a node    |
   that is listed in its Hop Cache.

   Each cache entry has a LifeTime, which is obtained through the
   Solicitation and Advertisement messages.  When an entry expires, the   |
   routing availability of the Destination MUST be redetermined as if no
   prior entry had existed.

   Negative "advice" from other layers, such as excessive
   retransmissions by a transport-layer protocol, or a down indication
   from a link-layer, SHOULD be used to invalidate a cache entry.

   Positive "advice" from other layers MUST NOT extend the LifeTime of a
   cache entry.

   ICMP Echo "pings" MUST NOT be used to actively check a cache entry.





















Simpson                  expires in six months                  [Page 7]


DRAFT                   IPv6 Neighbor Discovery             October 1994


3.  Router Solicitation

   Every IPv6 node MUST implement Router Solicitation.

   When any node starts up, it MUST send the Router Solicitation to
   prompt the advertisement of neighboring routers.

   If (and only if) no advertisements from neighboring routers are
   forthcoming, the node MAY retransmit the Router Solicitation a small
   number of times, but then MUST desist from sending more
   solicitations.

   Any routers that subsequently start up, or that were not discovered
   because of packet loss or temporary link partitioning, are eventually
   discovered by reception of their periodic (unsolicited)
   advertisements.  Links that suffer high packet loss rates or frequent
   partitioning are accommodated by increasing the rate of router
   advertisements, rather than increasing the number of solicitations
   that hosts are permitted to send.



3.1.  Constants

      MAX_SOLICITATIONS                    3 transmissions

      MAX_SOLICITATION_DELAY               1 second

      ROUTER_SOLICITATION_INTERVAL         3 seconds



3.2.  Implementation Details

   A IPv6 node is required to transmit up to MAX_SOLICITATIONS messages
   from any of its 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.

   -  A router has its forwarding capability turned off by system
      management.

   If a node chooses to send a solicitation after one of the above
   events, it should delay transmission for a random amount of time
   between 0 and MAX_SOLICITATION_DELAY.  This serves to alleviate



Simpson                  expires in six months                  [Page 8]


DRAFT                   IPv6 Neighbor Discovery             October 1994


   congestion when many nodes start up on a link at the same time, such
   as might happen after recovery from a power failure.

   It is recommended that nodes include some unique value (such as one
   of their interface or link-layer identifiers or 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.

   The small number of retransmissions of a solicitation, which are
   permitted if no advertisement is received, should be sent at
   intervals of ROUTER_SOLICITATION_INTERVAL seconds without further
   randomization.

   Upon receiving a valid Router Advertisement subsequent to one of the
   above events, the node MUST NOT send any solicitation on that
   interface (even if no solicitation has been sent yet) until the next
   time one of the above events occurs.



3.3.  Validity Check

   A non-router MUST silently discard any received Router Solicitation
   messages.

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

   -  Version number is correct.

   -  ICMP Checksum is correct.

   -  ICMP length (derived from the payload length) is 16 or more
      octets.

   -  For interfaces which are not point-to-point links, the Media-
      Access extension MUST be present.

   The IPv6 Source may have any unicast value, including Unknown (zero).

   If the IPv6 Source does not match one of the router's own IPv6
   Addresses on the arrival interface, under the Cluster-prefix
   associated with that IPv6 Address, the sender may be considered a
   Mobile Node.  The location of every reachable Mobile Node is
   maintained separately within the router.



Simpson                  expires in six months                  [Page 9]


DRAFT                   IPv6 Neighbor Discovery             October 1994


4.  Sending Router Advertisements

   Every IPv6 router MUST implement Router Advertisements.

   The router advertisements include such important information as a
   Media Address for the router, other Cluster-prefixes directly
   accessible through the router, and neighboring routers heard.

   Identification

      Each router advertisement includes one or more IPv6 Address
      fields.  These indicate the IPv6 Addresses which are presently in
      use for the router.

   Prefix Size

      Each advertised IPv6 Address has an associated prefix-size.  The
      value ranges from 0 to 126, and indicates the number of bits in
      the Identifier which define the Cluster-prefix for the link.  A
      value of zero indicates an end-point IPv6 Address.  When the value
      is not zero, the IPv6 Address may be used to discern Cluster-
      prefix mapping.

      If all advertised prefix-size values are zero, then prefix routing
      is not in use on that link.

   Preference

      Each advertised IPv6 Address has an associated preference.  This
      is used by a host to choose a default router for the first-hop,
      when the host has not yet been redirected or configured to use a
      specific router for a particular Destination.                       |

      The host is expected to choose from those routers that have the
      highest preference level for the best Cluster-prefix match.  When
      there is no match, or prefix routing is not in use, the preference
      value is used alone.

      An administrator can configure router preference levels to
      encourage or discourage the use of particular routers as the
      default first-hop.  The use of separate preferences per Cluster-
      prefix allows the choice of different routers for each prefix,
      when there are multiple prefixes in use for the same link.  This
      may be useful where multiple organizations share resources.

      The preference value is not the same as the "metric" used in many
      routing protocols.  It is used only by hosts in determining the
      default first-hop, rather than by routers in choosing a link for



Simpson                  expires in six months                 [Page 10]


DRAFT                   IPv6 Neighbor Discovery             October 1994


      transit traffic.  The values are not additive.  The range of
      values is smaller, and a higher value indicates a higher
      preference.

      It should be understood that preference levels learned from router
      advertisements do not affect any node's cached route entries.  For
      example, if a node has been redirected to use a particular router   |
      to reach a specific Destination, it continues to use that router    |
      for that Destination, even if it discovers another router with a
      higher preference level.  Preference levels influence the choice
      of router only for a Destination for which there is no cached or    |
      configured route, or whose cached route points to a router that is
      subsequently determined to be unreachable.



4.1.  Constants

      MAX_INITIAL_ADVERTISEMENTS           3 transmissions

      MAX_INITIAL_ADVERT_INTERVAL         16 seconds

      MAX_RESPONSE_DELAY                   2 seconds



4.2.  Configuration

   A router MUST allow the following variables to be configured by
   system management.  Default values are specified which make it
   unnecessary to re-configure these variables in most cases.

   For each interface:

   MaxAdvertisementInterval

      The maximum time (in seconds) allowed between sending router
      advertisements from the interface.  Must be no less than 4 seconds
      and no greater than 1800 seconds.

      Default: 600 seconds

   MinAdvertisementInterval

      The minimum time (in seconds) allowed between sending unsolicited
      router advertisements from the interface.  Must be no less than 1
      second and no greater than MaxAdvertisementInterval.




Simpson                  expires in six months                 [Page 11]


DRAFT                   IPv6 Neighbor Discovery             October 1994


      Default: 0.75 * MaxAdvertisementInterval

   AdvertisementLifetime

      The value (in seconds) to be placed in the Lifetime field of
      router advertisements sent from the interface.  Must be no less
      than MaxAdvertisementInterval and no greater than 9000 seconds.

      Default: 3 * MaxAdvertisementInterval


   For each of the IPv6 Addresses of each interface:

   Advertise

      A flag indicating whether or not the IPv6 Address is to be
      advertised.

      Default: TRUE

   PreferenceLevel

      The preferability of the interface as a default router choice,
      relative to other router interfaces serving the same Cluster-
      prefix on the same link.

      Values are in the range 0 to 255.  Higher values mean more
      preferable.  The minimum value zero is reserved to indicate that
      the IPv6 Address, even though it may be advertised, is not to be
      used by neighboring hosts as a default router address.  The
      maximum value 255 is reserved to indicate that the preference was
      locally configured, and not learned through advertisments.

      Default: 128

   It is useful to configure an IPv6 Address with a preference level of
   zero (rather than simply setting its Advertise flag to FALSE) when
   advertisements are being used for "black hole" detection.  In
   particular, a router that is to be used to reach only specific
   destinations could advertise a preference level of zero (so that
   neighboring hosts will not use it as a default router for reaching
   arbitrary destinations) and a non-zero lifetime (so that neighboring
   hosts that have been redirected or configured to use it can detect
   its failure by timing out the reception of its advertisements).

   DISCUSSION:

      It has been suggested that, when the preference level of an IPv6



Simpson                  expires in six months                 [Page 12]


DRAFT                   IPv6 Neighbor Discovery             October 1994


      Address has not been explicitly configured, a router could set it
      according to the metric of the router's "default route" (if it has
      one), rather than defaulting as suggested above.  Thus, a router
      with a better metric for its default route would advertise a
      higher preference level for its IPv6 Address.  (Note that routing
      metrics that are encoded such that "lower is better" would have to
      be inverted before being used as preference levels in router
      advertisement messages.) Such a strategy might reduce the amount
      of redirect traffic on some links by making it more likely that
      the host's first choice for reaching an arbitrary destination is
      also the best choice.

      On the other hand, redirect traffic is rarely a significant load
      on a link, and there are some cases where such a strategy would
      result in more redirect traffic (on links from which the most
      frequently chosen destinations are best reached via routers other
      than the one with the best default route).  Also, since the
      routing algorithms learn of neighboring routers from the
      advertisements, and the default routes are learned from the
      routing algorithms, the calculated preference may be unstable from
      time to time.  This document makes no recommendation concerning
      this issue, and implementors are free to try such a strategy, as
      long as they also support static configuration of preference
      levels as specified above.



4.3.  Implementation Details

   The term "advertising interface" refers to any functioning and
   enabled interface that has at least one IPv6 Address whose configured
   Advertise flag is TRUE.

   From each advertising interface, the router MUST transmit periodic
   Advertisements.

   CONTROVERSIAL:

      A router MAY proxy for the identifers of other nodes, using the
      Other-Identifier extension.  This SHOULD only be used when the
      router is translating to another internetwork protocol format.

   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 an
   advertisement is sent from an interface, that interface's timer is



Simpson                  expires in six months                 [Page 13]


DRAFT                   IPv6 Neighbor Discovery             October 1994


   reset to a uniformly-distributed random value between the configured
   MinAdvertisementInterval and MaxAdvertisementInterval.  Expiration of
   the timer causes the next advertisement to be sent, and a new random
   value to be chosen.

   It is recommended that routers include some unique value (such as one
   of their interface 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_ADVERTISEMENTS), if the randomly chosen interval is
   greater than MAX_INITIAL_ADVERT_INTERVAL, the timer should be set to
   MAX_INITIAL_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.

   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 it has one or more IPv6 Addresses whose Advertise flag is
      TRUE,

   -  enabling IPv6 forwarding capability (changing the node from a host
      to a router), when the interface has one or more IPv6 Addresses
      whose Advertise flag is TRUE,

   -  setting the Advertise flag of one or more of the interface's IPv6
      Addresses to TRUE (or adding a new IPv6 Address with a TRUE
      Advertise flag), when previously the interface had no IPv6 Address
      whose Advertise flag was 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_ADVERT_INTERVAL.  In the case of a host becoming a
   router, the node must also join the all-routers multicast group on
   all interfaces on which the router supports 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:




Simpson                  expires in six months                 [Page 14]


DRAFT                   IPv6 Neighbor Discovery             October 1994


   -  shutting down the node,

   -  administratively disabling the interface,

   -  disabling IPv6 forwarding capability (changing the node from a
      router to a host),

   -  setting the Advertise flags of all of the interface's IPv6
      Addresses to FALSE.

   In such cases, the router MUST transmit a final multicast
   advertisement on the interface, identical to its previous
   transmission, but with a Lifetime field of zero.  In the case of a
   router becoming a host, the node must also depart from the all-
   routers multicast group on all interfaces on which the router
   supports multicast (whether or not they had been advertising
   interfaces).

   When the Advertise flag of one or more of an interface's IPv6
   Addresses are set to FALSE by system management, but there remain
   other IPv6 Addresses on that interface whose Advertise flags are
   TRUE, the router SHOULD send a single multicast advertisement
   containing only those IPv6 Addresses whose Advertise flags were set
   to FALSE, with a Lifetime field of zero.

   In addition to the periodic unsolicited advertisements, a router MUST
   send advertisements in response to valid Router Advertisements or
   Router Solicitations received on any of its advertising interfaces.
   If the advertisement or solicitation does not contain any System-
   Heard extension, and the time since the previous advertisement is
   greater than MAX_INITIAL_ADVERT_INTERVAL, the router MUST multicast
   an advertisement from that interface.

   Whenever these response advertisements are sent, the advertisement
   MUST be delayed for a small random interval not greater than
   MAX_RESPONSE_DELAY, in order to prevent synchronization with other
   responding routers, and to allow multiple closely-spaced
   solicitations to be answered with a single advertisement.  The
   interface's interval timer is reset to a new random value, as with
   unsolicited advertisements.



4.4.  Validity Check

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




Simpson                  expires in six months                 [Page 15]


DRAFT                   IPv6 Neighbor Discovery             October 1994


   -  Version is correct.

   -  ICMP Checksum is correct.

   -  ICMP length (derived from the payload length) is 16 or more
      octets.

   -  At least one Routing-Information extension MUST be present.

   -  For interfaces which are not point-to-point links, the Media-
      Access extension MUST be present.








































Simpson                  expires in six months                 [Page 16]


DRAFT                   IPv6 Neighbor Discovery             October 1994


5.  Processing Router Advertisements

   Each router saves the information contained in the advertisements, in
   order to respond to future requests.  Any other action on receipt of
   such messages by a router (for example, as part of a "peer discovery"
   process) is beyond the scope of this document.

   Each host saves the information contained in the advertisements, in
   order to determine the next-hop when sending datagrams.  Hop
   determination is elaborated in the "Sending Datagrams" chapter.



5.1.  Configuration

5.1.1.  Router List

   Host Requirements -- Communication Layers [1], Section 3.3.1.6,
   specifies that each host must support a configurable list of default
   routers.  The purpose of the Router Advertisement messages is to
   eliminate the need to configure that list.

   Each entry in the list contains (at least) the following configurable
   variables:

   RouterAddress

      An IPv6 Address of a default router.

      Default: (none)

   Prefix Size

      Each router entry has an associated prefix-size.  The value ranges
      from 0 to 126, and indicates the number of bits in the IPv6
      Address which define the Cluster-prefix for the link.  A value of
      zero indicates an end-point IPv6 Address.  When the value is not
      zero, the IPv6 Address may be used to discern Cluster-prefix
      mapping.

      If all associated prefix-size values are zero, then prefix routing
      is not in use on that link.

      Default: 0

   PreferenceLevel

      The preferability of the RouterAddress as a default router choice,



Simpson                  expires in six months                 [Page 17]


DRAFT                   IPv6 Neighbor Discovery             October 1994


      relative to other router interfaces serving the same Cluster-
      prefix on the same link.  Host Requirements does not specify how
      this value is to be encoded.

      The values used here are defined as in Router Advertisements.
      Values are in the range 0 to 255.  Higher values mean more
      preferable.  The minimum value zero is reserved to indicate that
      the IPv6 Address, even though it may be advertised, is not to be
      used by neighboring hosts as a default router address.  The
      maximum value 255 is reserved to indicate that the preference was
      locally configured, and not learned through advertisments.

      Default: 255

   Default routers and preference levels SHOULD NOT be configured
   manually.  On links for which router discovery is administratively
   disabled, it MAY continue to be necessary to configure the default     |
   Router List in each host.



5.1.2.  Address List

   Each node requires at least one IPv6 Address.

   Each IPv6 Address is bound to zero or more interfaces.

   Each entry in the list contains (at least) the following configurable
   variables:

   IPv6 Address

      The IPv6 Address which is presently in use for the node.

      Default: None

   Prefix Size

      Each IPv6 Address entry bound to a link interface has an
      associated prefix-size.  The value ranges from 0 to 126, and
      indicates the number of bits in the IPv6 Address which define the
      Cluster-prefix for the link.  A value of zero indicates an end-
      point IPv6 Address.  When the value is not zero, the IPv6 Address
      may be used to discern Cluster-prefix mapping.

      If all associated prefix-size values are zero, then prefix routing
      is not in use on that link.




Simpson                  expires in six months                 [Page 18]


DRAFT                   IPv6 Neighbor Discovery             October 1994


      Default: 0

   LifeTime

      The value (in seconds) for the time that the IPv6 Address is
      associated with an interface.

      Default: 0

   The Cluster-prefix(es) for a host interface SHOULD NOT be configured
   manually.

   The Cluster-prefix(es) for a router interface SHOULD be configured
   manually, until such time in the future that an automatic algorithm
   is developed.



5.2.  Implementation Details

   To process an Router Advertisement, the node scans the list of
   extensions in it.



5.2.1.  Media-Access

   If a Media-Access extension is present, the Router List is updated     |
   with the information.  The Media-Access extension MAY appear anywhere
   in the list of extensions, but is most likely at the beginning or
   end.



5.2.2.  Change-Identifier

   Change-Identifier extensions MUST preceed Routing-Information
   extensions.

   -  If the prefix-size is zero, the IPv6 Address indicates the change
      of a single node, without affecting other nodes on that link.

   -  If the prefix-size is not zero, the IPv6 Address indicates the
      change of Cluster-prefix for all nodes on that link.

   -  The IPv6 Address and prefix-size are compared against any IPv6
      Addresses defined for the node.  If there is a match, a new IPv6
      Address is associated with the node.



Simpson                  expires in six months                 [Page 19]


DRAFT                   IPv6 Neighbor Discovery             October 1994


   -  If the new IPv6 Address is not already present in the receiving
      interface list, a new entry is added to the list, containing the
      IPv6 Address, prefix-size, and the Lifetime value from the
      advertisement.

   -  If the new IPv6 Address is already present in the receiving
      interface list as a result of a previously-received advertisement,
      its LifeTime is reset to the value in the newly-received
      advertisement.

   -  If the new IPv6 Address is already present in the receiving
      interface list as a result of static configuration, no change is
      made.  There is no LifeTime associated with a configured IPv6
      Address.

      The node MUST continue to accept datagrams destined for the old
      IPv6 Address, until such time as all stimulus for maintaining the
      old IPv6 Address has expired.  This implies that the node will
      maintain a LifeTime for most sources of IPv6 Addresses, such as
      DNS records and dynamic configuration.



5.2.3.  Routing-Information

   Routing-Information extensions MUST preceed Other-Identifier
   extensions.

   -  If the prefix-size is not zero, the IPv6 Address and prefix-size
      are compared against any IPv6 Addresses defined for the node.  If
      there is a match, the IPv6 Address is associated with the
      interface on which the message was received, and the prefix-size
      is set to the advertised prefix-size.

   -  If the IPv6 Address is not already present in the Router List, a    |
      new entry is added to the list, containing the IPv6 Address along
      with its accompanying preference level, and the Lifetime value
      from the advertisement.

   -  If the IPv6 Address is already present in the Router List as a      |
      result of a previously-received advertisement, its preference
      level is updated and its LifeTime is reset to the value in the
      newly-received advertisement.

   -  If the IPv6 Address is already present in the Router List as a      |
      result of static configuration, no change is made to its
      preference level.  There is no LifeTime associated with a
      configured IPv6 Address.



Simpson                  expires in six months                 [Page 20]


DRAFT                   IPv6 Neighbor Discovery             October 1994


         Note that any router IPv4 Address acquired from the "Gateway"
         subfield of the vendor extensions field of a BOOTP packet [11]
         are considered to be configured; they are assigned the default
         preference level of 255, and they do not have an associated
         LifeTime.

         Note further that any IPv6 Address found in the "giaddr" field
         of a BOOTP packet [3] identifies a BOOTP forwarder which is not
         necessarily a IPv6 router; such an IPv6 Address should not be
         installed in the default Router List.                            |

      To limit the storage needed for the default Router List, the host   |
      MAY choose not to store all of the router IPv6 Addresses
      discovered via advertisements.  The host SHOULD discard those IPv6
      Addresses with lower preference levels in favor of those with
      higher levels.

      It is desirable to retain more than one default router in the
      list; if the current choice of default router is discovered to be
      down, the host may immediately choose another default router
      without having to wait for the next advertisement to arrive.

      Any router IPv6 Address advertised with a preference level of zero
      is not to be used by the host as default router IPv6 Address.       |
      Such an IPv6 Address may be omitted from the default Router List,
      unless its LifeTime is being used as a "black-hole" detection
      mechanism.



5.2.4.  Other-Identifier

   The Other-Identifier extension is used to indicate IPv6 Addresses
   which have no effect on the interface Cluster-prefix.

   -  If the IPv6 Address is not already present in the Router List, a    |
      new entry is added to the list, containing the IPv6 Address, the
      preference level set to zero, and the Lifetime value from the
      advertisement.

   -  If the IPv6 Address is already present in the Router List as a      |
      result of a previously-received advertisement, and its preference
      level is zero, its LifeTime is reset to the value in the newly-
      received advertisement.

   -  If the IPv6 Address is already present in the Router List as a      |
      result of static configuration, no change is made to its
      preference level.  There is no LifeTime associated with a



Simpson                  expires in six months                 [Page 21]


DRAFT                   IPv6 Neighbor Discovery             October 1994


      configured IPv6 Address.

      To limit the storage needed for the default Router List, the host   |
      MAY choose not to store all of the other IPv6 Addresses discovered
      via advertisements.  The most preferred router is used for unknown
      IPv6 Addresses, and it will send a redirect when appropriate.



5.2.5.  System-Heard

   The use of the System-Heard extension is described in a future Mobile
   Discovery document.






































Simpson                  expires in six months                 [Page 22]


DRAFT                   IPv6 Neighbor Discovery             October 1994


A.  Configuration Summary

   Routers

      A router requires at least one IPv6 Address to be configured.

      For each interface, a prefix-size is assigned to each IPv6
      Address, unless automatic prefix discovery is in place.

         Note that this procedure minimizes the number of items to be
         configured, and possible configuration errors.

      Optionally, other values MAY be altered from their defaults, such
      as preference and advertisement lifetime.

      Optionally, routing protocols MAY require additional values to be
      configured, such as metric and priority.  Such functions are
      beyond the scope of this document.

   Hosts

      Most hosts need no prior configuration.

      A node attached to a multi-access media creates a local-use
      unicast address from the media address.

      A node attached to a point-to-point media (using the Point-to-
      Point Protocol [RFC-1661]) can be dynamically assigned either a
      global or local unicast address.

      Other nodes require configuration of an IPv6 Address, as described
      in the section "Address List".

      When a router is present, a local-use unicast address MAY be
      combined with a Cluster address learned from Router Advertisements
      to form a routable IPv6 Address.















Simpson                  expires in six months                 [Page 23]


DRAFT                   IPv6 Neighbor Discovery             October 1994


Security Considerations

   Security issues are not discussed in this memo.



Acknowledgements

   The document was initially composed of quotations from the RFC-1122
   "Requirements for Internet Hosts -- Communication Layers", and RFC-
   1256 "ICMP Router Discovery Messages".



Author's Address

   Questions about this memo can also be directed to:

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

      Bill.Simpson@um.cc.umich.edu
          bsimpson@MorningStar.com

























Simpson                  expires in six months                 [Page 24]

DRAFT                   IPv6 Neighbor Discovery             October 1994


                           Table of Contents


     1.     Introduction ..........................................    1

     2.     Sending Datagrams .....................................    1
        2.1       Constants .......................................    1
        2.2       Hop Cache .......................................    1
        2.3       Next Hop Decision ...............................    4
        2.4       Media Address Determination .....................    5
        2.5       Router Selection ................................    6
        2.6       Dead Node Detection .............................    7

     3.     Router Solicitation ...................................    8
        3.1       Constants .......................................    8
        3.2       Implementation Details ..........................    8
        3.3       Validity Check ..................................    9

     4.     Sending Router Advertisements .........................   10
        4.1       Constants .......................................   11
        4.2       Configuration ...................................   11
        4.3       Implementation Details ..........................   13
        4.4       Validity Check ..................................   15

     5.     Processing Router Advertisements ......................   17
        5.1       Configuration ...................................   17
           5.1.1  Router List .....................................   17
           5.1.2  Address List ....................................   18
        5.2       Implementation Details ..........................   19
           5.2.1  Media-Access ....................................   19
           5.2.2  Change-Identifier ...............................   19
           5.2.3  Routing-Information .............................   20
           5.2.4  Other-Identifier ................................   21
           5.2.5  System-Heard ....................................   22

     APPENDICES ...................................................   23

     A.     Configuration Summary .................................   23

     SECURITY CONSIDERATIONS ......................................   24

     ACKNOWLEDGEMENTS .............................................   24

     AUTHOR'S ADDRESS .............................................   24


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