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