Network Working Group W A Simpson Internet Draft Daydreamer expires in six months February 1995 IPv6 Neighbor Discovery -- Processing draft-simpson-ipv6-discov-process-02.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) munnari.oz.au (Pacific Rim) Abstract This document discusses the implementation 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 February 1995 1. Introduction This document describes how to - determine the availability of other IPv6 nodes as demand for communication occurs; - detect the presence of available IPv6 routers; - learn the appropriate link address for sending to its neighbors; | - and redirect traffic where appropriate. The design requirements are more completely described in [D-Sign]. The ICMP packet formats are described in [D-Form]. This document contains only that information which is particularly relevant to IPv6 Neighbor Discovery, or that differs from IPv4 techniques. Other IPv6 documents should be consulted for further details. 2. Link-Layers This document anticipates that link-layer material will be covered in a separate Link Layer Requirements document. Specific link-layer protocol implementation details are beyond the scope of this document. 2.1. Addresses | For multi-access links, every node requires a unique address on the | link. | When multi-homed hosts are present, every link address MUST be unique | over all such attached links. | The same link address MAY be used by the same node on multiple links. | 2.2. Address Resolution Protocol (ARP) ARP [RFC-826] is no longer used for IPv6. Simpson expires in six months [Page 1] DRAFT IPv6 Neighbor Discovery February 1995 2.3. Trailers Because ARP is no longer used for IPv6, trailer encapsulation [RFC- 893] MUST NOT be used. 2.4. Maximum Transmission Unit (MTU) The MTU is a internetwork-layer indication of the maximum datagram size which can be sent on an interface. This does not include link- layer encapsulation and framing, but includes padding which can be | added by the link-layer for small frames. Many link-layer protocols define a maximum frame size that may be sent. In such cases, a node MUST NOT allow a datagram to be sent which would require frames larger than those allowed by the link- layer protocol. The MTU of each logical interface MUST be configurable, as limited by | the link-layer frame size. However, a node MUST be able to receive a packet as large as the maximum frame size, even if that is larger than the currently configured MTU. 2.5. Maximum Receive Unit (MRU) The MRU is a internetwork-layer indication of maximum datagram size that can be received by a peer. This does not include link-layer encapsulation and framing, but includes padding which can be added by | the link-layer for small frames. Some link-layer protocols [RFC-1661] define a mechanism for adjusting the maximum frame size. In addition, this protocol provides the advertisement of an MRU independently of the link-layer. When the advertised MRU of a peer node is less than the configured link MTU, that MRU MUST be maintained on a per peer basis. 2.6. Incoming Interface On receipt of a link-layer unicast, broadcast or multicast packet, | the node MAY check against a list of valid link addresses. If the | packet passes the link-layer, then internetwork-layer will ensure the | validity of the datagram. Simpson expires in six months [Page 2] DRAFT IPv6 Neighbor Discovery February 1995 For each received packet, the link-layer MUST pass the following information to the internetwork-layer: (1) the datagram itself. (2) the length of the data portion of the link-layer frame, | including padding (not including encapsulation and framing). (3) the identity of the physical interface from which the datagram was received. (4) the classification of the received destination link-layer address as unicast or multicast (including broadcast). | In addition, the link-layer SHOULD provide: (5) the source link-layer address, if any. RATIONALE: This section is included because other parts of this document require specific information to be passed across this layer boundary. Although every different medium typically has a different address format, the broadcast and multicast addresses are an important special case. Some link adapters check only a coarse grained hash or suffix of the link destination. It is the responsiblity of the interface implementation to prevent leaking. See also "Processing Datagrams". The source link address might be required in some implementations to map an essentially transient link-layer address (such as, a Frame-Relay DLCI) to the more stable family link address (that is, | E.164). 2.7. Outgoing Interface For each transmitted packet, the internetwork-layer MUST pass the following information to the link-layer: (1) the datagram itself. (2) the length of the datagram. Simpson expires in six months [Page 3] DRAFT IPv6 Neighbor Discovery February 1995 (3) the destination physical interface. (4) the destination link-layer address, if any. In addition, the internetwork-layer SHOULD provide: (5) the link-layer priority value. The link-layer MUST notify the internetwork-layer if the packet to be transmitted causes a link-layer precedence-related error. 2.8. Unreachable The link-layer MUST NOT report a Destination Unreachable error to the internetwork-layer solely because there is no Hop Cache entry for a particular Destination. Simpson expires in six months [Page 4] DRAFT IPv6 Neighbor Discovery February 1995 3. Sending Datagrams For outgoing datagrams, the internetwork-layer: (1) sets any fields not set by the transport-layer. (2) chooses the interface and next hop. (3) fragments the datagram if necessary, when intentional fragmentation is configured. (4) passes the packet(s) to the appropriate link-layer interface. 3.1. Choosing a Source Address When a node sends a datagram, the IPv6 Source MUST be one of its own IPv6 Unicast Addresses (not an IPv6 Cluster or Multicast Address). NOTE: | This process is essentially the same as choosing the next hop (see | "Next Hop Decision"). Implementors might be able to combine the | two functions. | If the datagram is sent in response to a received datagram, the Destination from that datagram SHOULD be used as the Source for the response (unless it was an IPv6 Unspecified, Cluster or Multicast | Address). An application MUST be able to explicitly specify the Source for initiating a connection or a request. If the Source to be used is unknown, a Source MUST be selected by the internetwork-layer. (a) When no Router Advertisements have been heard, the Destination is assumed to be on an attached link. The Source is chosen from an IPv6 Unicast Address which is bound to any interface. (b) When one or more Router Advertisements have been heard, the Router List is examined. If the Destination exactly matches the Primary Identifier of a router, a Prefix-Information entension, or an Known-Identifier | extension, then the Source is chosen from the interface on Simpson expires in six months [Page 5] DRAFT IPv6 Neighbor Discovery February 1995 which the advertisement was received. (c) The Destination is compared against the routing-prefixes | configured for each interface, or learned from Prefix- | Information and Known-Identifier extensions. If the Destination exactly matches one of the routing-prefixes, | then the Source is chosen from the indicated interface. (d) If the Destination does not match any routing-prefixes, then | the Source is chosen from the interface of the most preferred | router, as described in the "Router Selection" section which follows. When more than one IPv6 Unicast Address meets the criteria, the | Source chosen SHOULD have the longest bit-wise prefix match with the Destination. Other selection preferences are implementation dependent. * 3.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 cache entry MUST include the link address (if any) to be used to | send the datagram. This entry might point directly to the | Destination, or to a router which forwards to the Destination. It MAY contain other information which records previous experience related to the Destination. 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. * 3.3. Next Hop Decision The next hop is chosen based on the IPv6 Destination. If the | Destination can be readily determined to be on an attached link, the datagram is sent directly to the Destination. * To determine the next hop, the following algorithm is used: | Simpson expires in six months [Page 6] DRAFT IPv6 Neighbor Discovery February 1995 (a) If the Destination is the IPv6 Loopback Address, or an IPv6 Multicast Address with scope intra-node, process as an incoming datagram. (b) If the Destination is another scope of IPv6 Multicast Address, simply pass the datagram to the link-layer for any indicated interface(s). | This requires that multicast datagrams are registered on a per | interface basis. Other aspects of multicast routing are beyond | the scope of this document. (c) When no Router Advertisements have been heard, the Destination is assumed to be on an attached link. The datagram is duplicated for each interface. Each interface | separately solicits the Destination location, as described in "Sending General Solicitations". The correct interface will be | learned when the Hop Cache is updated through the future | advertisements of the target node. (d) When one or more Router Advertisements have been heard, the Router List is examined. If the Destination exactly matches the Primary Identifier of a router, a Prefix-Information entension, or an Known-Identifier | extension, then the datagram is sent directly to the indicated router (using the Media-Access extension provided, if any). (e) The Destination is compared against the routing-prefixes | configured for each interface, or learned from Prefix- | Information and Known-Identifier extensions. There is a | Contiguous-bit which indicates whether the routing-prefix is | confined to a single link [D-Form]. If the Destination exactly matches one of the routing-prefixes, | and the Contiguous-bit is set, then the Destination is assumed to be on that specific link. For that interface, the Destination is located as described in "Sending General Solicitations". (f) If the Destination exactly matches one of the routing-prefixes, | but the Contiguous-bit is not set, then the datagram is sent directly to the indicated router (using the Media-Access extension provided, if any). (g) If the Destination does not match any routing-prefixes, then | the datagram is sent to a single preferred router, as described Simpson expires in six months [Page 7] DRAFT IPv6 Neighbor Discovery February 1995 in the "Router Selection" section which follows. For a node with multiple interfaces, 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 as described above. It is sent to the most preferred | router, and also to all those interfaces without routers for which a peer entity is unknown. This allows a node to continue operation in the presence of private or partitioned links. * 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. 3.4. Router Selection The router is chosen based on the IPv6 Source. To decide which | router to send a datagram, the following procedure is used: (a) routing-prefixes are learned from the Prefix-Information | extension of Router Advertisements. The Prefix_Size is the | number of valid bits in the routing-prefix. (b) The Source is compared to the list of routing-prefixes in the | Router List. (c) If a routing-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 among those matching routers. (d) If there are no matching routing-prefixes, or the Source is the | Unknown Address, then there is no preferred router for the Source. The node selects the highest preference value among all routers found on all interfaces. (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. See "Sending Local Redirects". (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. See "Processing Local Redirects". Simpson expires in six months [Page 8] DRAFT IPv6 Neighbor Discovery February 1995 When the Destination is determined to be accessible through a router, a separate entry is created in the Hop Cache for that Destination, and the cache entry for the router is used to send the datagram. The Router List 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. | Once a Hop Cache entry has been added for a Destination, it is not | affected by future Router Advertisements from new routers, or changes | in Prefix-Information extensions. Only a Local Redirect changes the | Hop Cache. | RATIONALE: | In a multiple router environment, this permits a saturated router | to dynamically lower its preferences or reduce its number of | advertised Prefix-Information extentions, in order to better share | the load, without dumping its entire load on another router. 3.5. Static Routes | A static route is typically a particular preset mapping for a Destination IPv6 Unicast or Cluster Address. Static routes would be | installed by administrators to override the normal automatic routing mechanism, and to handle exceptional situations. However, any static routing information is a potential source of failure as configurations change or equipment fails. Each such static route MUST be overridden by Local Redirects for the LifeTime indicated. Otherwise, every datagram sent will result in a repeated Redirect message. 3.6. Dead Node Detection Routers periodically advertise their availability. The advertisement | frequency is always greater than the LifeTime of the advertisement. | When the LifeTime of a Router Advertisement expires, the router is | presumed dead, and that Router List entry is immediately removed. | All dependent Hop Cache Destinations are also removed. RATIONALE: | The exact constraints on the timeliness of "black hole" detection | may vary somewhat depending on the nature of the node's mission, | Simpson expires in six months [Page 9] DRAFT IPv6 Neighbor Discovery February 1995 but a node generally needs to detect a failed first-hop router | quickly enough that transport-layer connections will not break | before an alternate router can be selected. | Hosts do not periodically advertise. Therefore, when the LifeTime of | a General Advertisement expires, it is retained for an implementation | dependent period of time. This retention time MAY be a reasonably | large value, to avoid excessive multicast probes for that Destination | when a node only occasionally communicates with a given peer node. | The retention time SHOULD NOT be arbitrarily large or infinite, to | avoid losses and delays after an extended idle period when the link | address of the Destination has changed. | NOTE: | This does not preclude purging of a cache entry prior to the | expiration of its LifeTime or retention time, such as when the | implementation has insufficient storage. | When a datagram is to be sent, but the Hop Cache entry has expired | and is retained, the datagram is sent using the last known link | address. It is immediately followed by a General Solicitation, which | is unicast to the Destination. The Hop Cache LifeTime is updated as | described in "Sending General Solicitations". | When an entry is purged, 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 interface, SHOULD be used to purge a cache entry. | Positive "advice" from other layers, such as returning acknowledgements from a transport-layer protocol, MUST NOT extend the LifeTime of a cache entry. Promiscuous observation of link-layer or internetwork-layer Source fields MUST NOT extend the LifeTime of a cache entry. ICMP Echo "pings" by the internetowrk-layer MUST NOT be used to | actively check a cache entry. RATIONALE: If the cache has timed out, the node does not re-solicit until it | has a datagram to send. Queuing is avoided when any former link address is known. | Passing advice from other layers of the protocol stack complicates Simpson expires in six months [Page 10] DRAFT IPv6 Neighbor Discovery February 1995 the interfaces between the layers, but it is the preferred approach. The detection mechanism must not cause unacceptable load on the node, on congested links, or on first-hop router(s). | Using other layer information to shorten, but not to lengthen, the | cache LifeTime ensures that failed nodes are found quickly. | Assuming that the configured LifeTime results in a light load on | the network, then there is not much to be gained by lengthening | the period. | Packets arriving from a particular link-layer address are evidence that the system at this address is alive. However, turning this information into advice requires mapping the link-layer address | into an internetwork-layer address, and then checking that address | against the entries in the Hop Cache. This is probably prohibitively inefficient. Positive advice that is given for every datagram received could cause unacceptable overhead in the implementation. Ping scales poorly. Simpson expires in six months [Page 11] DRAFT IPv6 Neighbor Discovery February 1995 4. Processing Datagrams For incoming datagrams, the internetwork-layer: (1) verifies that the datagram is correctly formatted for the IP version. (2) verifies that it is destined to the local host. (3) processes subsequent headers and options. (4) reassembles the datagram as necessary. (5) passes the final payload to the appropriate transport-layer protocol module. 4.1. Address List Each interface requires at least one IPv6 Address. Each IPv6 Address is bound to at most one interface. Each interface contains (at least) the following configurable variables: Address The IPv6 Unicast Address which is presently in use for the interface. Default: None Prefix_Size Each Address entry bound to a link interface has an associated Prefix_Size. The value ranges from 0 to 127, and indicates the number of bits in the Address which define the routing-prefix for | the link. When the value is not zero, the Address may be used to discern | routing-prefix mapping. If all associated Prefix_Size values are zero, then prefix routing is not in use on that link. Default: 0 Simpson expires in six months [Page 12] DRAFT IPv6 Neighbor Discovery February 1995 LifeTime The value for the time that the Address is associated with an interface. Default: infinity The routing-prefix(es) for a host interface SHOULD NOT be configured | manually. The routing-prefix(es) for a router interface SHOULD be configured | manually, until such time in the future that an automatic algorithm is developed. 4.2. Details An incoming datagram is destined for the node when the IPv6 Destination is: (1) (one of) the IPv6 Unicast Address(es) on any interface of the node. A host MUST NOT discard an incoming datagram whose Destination does not correspond to the logical interface through which it is received. (2) an IPv6 Cluster Address which corresponds to the incoming | interface, and which matches the Prefix_Size. (3) an IPv6 Multicast group of which the host is a member on the incoming interface. A host MUST silently discard any IPv6 datagram which is not destined for itself. A router MUST silently discard any IPv6 unicast datagram which is not destined for itself, and that has arrived with a link-layer broadcast or multicast indication. Other unicast, cluster and multicast routing details are beyond the scope of this document. All nodes MUST silently discard any IPv6 datagram containing an invalid IPv6 Source, such as an IPv6 Cluster or Multicast Address. This validation could be done in either the internetwork-layer, or by each protocol in the transport-layer. RATIONALE: Simpson expires in six months [Page 13] DRAFT IPv6 Neighbor Discovery February 1995 A mis-addressed datagram might be caused by a link-layer broadcast of a unicast datagram, or by any node that is confused or mis- configured. All nodes are required to check for a link-layer broadcast or multicast, as well as an internetwork-layer address. This is necessary to prevent propagation of mis-addressed datagrams, which can result in broadcast storms. An architectural goal for hosts is to allow addresses to be featureless numbers, avoiding algorithms that required a knowledge of the format. Otherwise, any future change in the format or interpretation of addresses will require host software changes. However, validation of IPv6 Cluster and Multicast Addresses violates this goal. This is mitigated by the need to explicitly learn or join these groups. Simpson expires in six months [Page 14] DRAFT IPv6 Neighbor Discovery February 1995 5. Sending General Solicitations Every IPv6 node MUST implement General Solicitations. The General Solicitation is used by any node to determine both the reachability and the link-layer information of a neighboring node. | 5.1. Configuration * A node SHOULD 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: General_Solicitation_Interval The value to be placed in the Lifetime field of the Hop Cache entry for General Solicitations sent from the interface. MUST | NOT be less than 1 second, and SHOULD NOT be greater than 10 seconds. Default: 3 seconds 5.2. Details A node is required to transmit a single General Solicitation, at the | times specified in "Next Hop Decision" and "Dead Node Detection". Whenever a solicitation is sent, a Hop Cache entry is added or | updated with a LifeTime of General_Solicitation_Interval. No further solicitations are sent until this Hop Cache entry expires. | RATIONALE: This mechanism prevents flooding (repeating a solicitation at a high rate). The General_Solicitation_Interval is chosen to allow sufficient round trip time for low bandwidth or congested links, and response time for heavily loaded nodes. A LifeTime this short could create noticeable overhead traffic on a link with large number of nodes. Therefore, it may be necessary to configure busy routers or active servers with a longer Simpson expires in six months [Page 15] DRAFT IPv6 Neighbor Discovery February 1995 General_Solicitation_Interval. The following method is used to send the solicitation: | (a)If the interface and link address are known from an expired Hop | Cache entry, the General Solicitation is sent using the retained | link address. | (b) If the interface has no broadcast capability (a point-to-point link), and the peer entity is unknown (no advertisements received), the General Solicitation is sent on that interface. | No link address is needed. | (c) If a virtual interface has no broadcast capability (a Frame- Relay or X.25 link), the General Solicitation 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 node with multiple physical interfaces. The link address used | is determined by the virtual circuit setup. | (d) If an interface has no multicast capability, the General Solicitation is sent as a link-layer broadcast. The IPv6 Destination is unchanged. | (e) For an interface with multicast capability, the General Solicitation is sent as a link-layer multicast. The IPv6 | Destination is used to calculate the appropriate multicast. The solicitation is not delayed. | Upon receiving a valid advertisement (of any kind) from the target * Destination, the node MUST NOT send any solicitation on that interface (even if no solicitation has been sent yet) until the advertisement LifeTime expires. RATIONALE: This serves to alleviate congestion when many nodes start up on a link at the same time, such as might happen after recovery from a power failure, or the periodic Hop Cache refresh of a large number of clients sharing a server. When the link address is unknown, the original datagram SHOULD be held | (rather than discarded) until a valid advertisement is received. When * additional datagrams for the same Destination are received, the most * recent are saved, and earlier datagrams MAY be discarded. When the Hop Cache entry expires while waiting for an advertisement, any | held datagrams MUST be discarded, and the entry is purged. Simpson expires in six months [Page 16] DRAFT IPv6 Neighbor Discovery February 1995 RATIONALE: Failure to follow this recommendation causes the first packet of every exchange to be lost. Although transport-layer protocols can generally cope with packet loss by retransmission, packet loss does impact performance. For example, loss of a TCP open request causes the initial round-trip time estimate to be inflated. UDP applications, such as the Domain Name System, are more seriously affected. | Purging the link address after failure to receive a response ensures | that changes in link address are detected. | Repeating solicitations after failure to receive a response, without | waiting for renewed transport-layer stimulus, can cause congestive | collapse. Simpson expires in six months [Page 17] DRAFT IPv6 Neighbor Discovery February 1995 6. Processing General Solicitations Every IPv6 node MUST process General Solicitations. All IPv6 nodes MUST accept the calculated Solicited-Nodes IPv6 Multicast Address for every address bound to every interface. This is calculated by starting with the exclusive-or of each byte of the target IPv6 Unicast Address, then adding the result to the base | Solicited-Nodes multicast (FFxx::0700). For example, to calculate the destination value for target A::B:C, | the exclusive-or is D. The calculated destination would be | FFxx::070D. On receipt of a valid General Solicitation, the target node sends a General Advertisement, using the extension information provided. 6.1. Validity All nodes MUST silently discard any received General Solicitation messages that do not satisfy the following validity checks: - IPv6 Version is correct. - IPv6 Source is a Unicast Address, is not the Unspecified Address, and is not a Cluster or Multicast Address. - When an Authentication Header is present, it is correct. | - ICMP Checksum is correct. - ICMP length (derived from the payload length) is 8 or more octets. - The Known-Identifier extension indicates one of the IPv6 Unicast | Addresses which is bound to any interface of the node. - For interfaces which are not point-to-point links, the Media- Access extension is present. 6.2. Details The solicitation has no LifeTime. The extension information is used only for returning the advertisement, and then discarded. Simpson expires in six months [Page 18] DRAFT IPv6 Neighbor Discovery February 1995 No new Hop Cache entry is added, and any existing entry is not updated. RATIONALE: At the time of solicitation, the extension information might not be complete. For example, the initial solicitation will not contain the Node-Heard for the target, and the target will not be assured that the path to the sender is complete. This also helps stagger solicitations. To process a General Solicitation, the node scans the list of extensions in it. 6.2.1. Media-Access If a Media-Access extension is present, the information MAY be used to return the General Advertisement directly to the solicitor. The Media-Access extension MAY appear anywhere in the list of extensions, but is most likely at the beginning or end. 6.2.2. Node-Heard The absence of the Node-Heard extension serves as an indication that the solicitor has not yet heard any Router Advertisement. The General Advertisement MUST be sent directly to the solicitor. If a Node-Heard extension is present which indicates that the solicitor has previously heard the node, it is confirmation of contact in those cases where the routing-prefix is not entirely | confined to the link. The General Advertisement MAY be sent directly to the solicitor. Simpson expires in six months [Page 19] DRAFT IPv6 Neighbor Discovery February 1995 7. Sending General Advertisements Every IPv6 node MUST implement General Advertisements. A General Advertisement is sent in response to a General | Solicitation, or to expire a previous Advertisement. 7.1. Constants GENERAL_ADVERTISEMENT_COUNT 4 entries 7.2. Configuration A node SHOULD 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: Advertisement_LifeTime The value to be placed in the Lifetime field of General Advertisements sent from the interface. The value MAY be | reduced on a case by case basis for demand critical | applications operating in a low delay environment. Default: 600 seconds 7.3. Details The IPv6 Source specified in the solicitation is used as the IPv6 Destination in the advertisement, except under the following conditions: (a) When the number of current Hop Cache entries (exclusive of static routes and router list entries) is GENERAL_ADVERTISEMENT_COUNT or more. (b) When one or more Router Advertisements have been heard, and the | Source does not match any routing-prefixes configured for an interface, or learned from Prefix-Information extensions. | Simpson expires in six months [Page 20] DRAFT IPv6 Neighbor Discovery February 1995 (c) When the Source exactly matches one of the routing-prefixes, | but the Contiguous-bit is not set. In these cases, the advertisement is sent to the All-Nodes IPv6 Multicast Address (FF02::1). The scope is intra-link. RATIONALE: The decision to multicast an advertisement to all nodes, instead of repeating a unicast to each successive soliciting node, is a balance between disturbing a large number of nodes at the internetwork-layer against a greater amount of traffic. Assuming that each node communicates with every neighbor, the discovery traffic increases at the rate of 2n*n nodes. When most nodes communicate only with a server, a multicast advertisement reduces the traffic to 2n. The multicast advertisements could be particularly disruptive when they interrupt the sleep mode of a battery powered device. However, the device might already have been disrupted by the solicitation when the link has broadcast and not multicast capability. Also, it is precisely those devices which are most likely to be deployed on bandwidth-limited links, where a reduction of traffic is most important. In addition, roaming nodes which experience multipath and half- link conditions use the multicast advertisement to learn whether a direct contact is possible. Simpson expires in six months [Page 21] DRAFT IPv6 Neighbor Discovery February 1995 8. Processing General Advertisements Every IPv6 node MUST process General Advertisements. All IPv6 nodes MUST accept the All-Nodes IPv6 Multicast Address (FFxx::1) on every interface. On receipt of a valid General Advertisement, all nodes which have a Hop Cache entry for the Source update the cache entry with the | current LifeTime and link address, and any other pertinent field values implemented. 8.1. Validity All nodes MUST silently discard any received General Advertisement messages that do not satisfy the following validity checks: - IPv6 Version is correct. - IPv6 Source is a Unicast Address, is not the Unspecified Address, and is not a Cluster or Multicast Address. - When an Authentication Header is present, it 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 is present. 8.2. Details To process a General Advertisement, the node scans the list of extensions in it. 8.2.1. Media-Access If a Media-Access extension is present, the Hop Cache 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. | Simpson expires in six months [Page 22] DRAFT IPv6 Neighbor Discovery February 1995 When an unsolicited advertisement is received, this extension MUST | NOT be compared with the current contents of the Hop Cache, since the | advertisement might have been sent from another interface. 8.2.2. Known-Identifier | The Known-Identifier extension is used to indicate IPv6 Addresses | bound to other interfaces of the node, or other IPv6 addresses on the same interface which are not subsumed by the same routing-prefix. | Each Known-Identifier MAY be used to add or update another Hop Cache | entry. 8.2.3. Node-Heard If a Node-Heard extension is present which indicates that the advertiser has previously heard the node, it is confirmation of contact in those cases where the routing-prefix is not entirely | confined to the link. If the Quality specified is not zero, but is less than the Quality for some other router Node-Heard extension, the Hop Cache entry MAY be updated to point to that router instead. A Routing Header can be used to direct datagrams along the more reliable path. Simpson expires in six months [Page 23] DRAFT IPv6 Neighbor Discovery February 1995 9. Sending Router Solicitations Every IPv6 node MUST implement Router Solicitations. When any node initializes, 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 nodes are permitted to send. 9.1. Constants MAX_SOLICITATIONS 3 transmissions MAX_SOLICITATION_DELAY 2 seconds | 9.2. Configuration A node SHOULD 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: Router_Solicitation_Interval The value to be used for repeated Router Solicitations sent from the interface. MUST NOT be less than 2 * MAX_SOLICITATION_DELAY, and SHOULD NOT be greater than 10 seconds. Default: 6 seconds | Simpson expires in six months [Page 24] DRAFT IPv6 Neighbor Discovery February 1995 9.3. Details A 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 for that interface turned off by system management. If a node chooses to send a solicitation after one of the above events, it MUST delay transmission for a random amount of time | between 0 and MAX_SOLICITATION_DELAY. 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 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. | RATIONALE: | This serves to alleviate congestion when many nodes start up on a | link at the same time, such as might happen after recovery from a | power failure. Simpson expires in six months [Page 25] DRAFT IPv6 Neighbor Discovery February 1995 10. Processing Router Solicitations | Every IPv6 router MUST process Router Solicitations. All IPv6 routers MUST accept the All-Routers IPv6 Multicast Address (FFxx::2) on every interface for which forwarding is enabled. On receipt of a valid Router Solicitation, the target router sends a Router Advertisement. If the IPv6 Source does not match one of the router's own IPv6 Cluster Addresses on the arrival interface, by matching the | associated routing-prefix, the sender is considered a Mobile Node. The location of every reachable Mobile Node is maintained separately within the router. 10.1. Validity 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: - IPv6 Version is correct. - IPv6 Source is the Unspecified Address, or an IPv6 Unicast Address, but is not a Cluster or Multicast Address. - When an Authentication Header is present, it is correct. | - ICMP Checksum is correct. - ICMP length (derived from the payload length) is 8 or more octets. - For interfaces which are not point-to-point links, the Media- Access extension is present. 10.2. Details To process a Router Solicitation, the node scans the list of extensions in it. Simpson expires in six months [Page 26] DRAFT IPv6 Neighbor Discovery February 1995 10.2.1. Media-Access If a Media-Access extension is present, the information MAY be used to return the Router Advertisement directly to the solicitor. The Media-Access extension MAY appear anywhere in the list of extensions, but is most likely at the beginning or end. 10.2.2. Node-Heard The absence of the Node-Heard extension serves as an indication that the solicitor has not yet heard any Router Advertisement. The Router Advertisement MUST be sent promptly, at the accelerated initial rate. If a Node-Heard extension is present which indicates that the solicitor has previously heard the node, it is confirmation of contact in those cases where the routing-prefix is not entirely | confined to the link. Simpson expires in six months [Page 27] DRAFT IPv6 Neighbor Discovery February 1995 11. Sending Router Advertisements Every IPv6 router MUST implement Router Advertisements. A Router Advertisement is sent periodically, and also in response to a Router Solicitation. 11.1. Constants MAX_INITIAL_ADVERTISEMENTS 3 transmissions MAX_INITIAL_ADVERT_INTERVAL 10 seconds MAX_ADVERTISEMENT_DELAY 1 second | 11.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: Minimum_Advertisement_Interval The minimum time allowed between sending unsolicited Router Advertisements from the interface. MUST NOT be less than | MAX_ADVERTISEMENT_DELAY. Default: 30 seconds | Maximum_Advertisement_Interval The maximum time allowed between sending Router Advertisements from the interface. MUST NOT be less than | Minimum_Advertisement_Interval. Default: 1.50 * Minimum_Advertisement_Interval Advertisement_LifeTime The value to be placed in the Lifetime field of Router Advertisements sent from the interface. MUST NOT be less than Maximum_Advertisement_Interval, and SHOULD NOT be greater than | Simpson expires in six months [Page 28] DRAFT IPv6 Neighbor Discovery February 1995 600 seconds (10 minutes). Default: 3 * Maximum_Advertisement_Interval For each of the IPv6 Unicast or Cluster Addresses of each interface: Advertise A flag indicating whether or not the IPv6 Address is to be advertised. Default: TRUE Preference The preferability of the interface as a default router choice, relative to other router interfaces serving the same routing- | 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 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. Simpson expires in six months [Page 29] DRAFT IPv6 Neighbor Discovery February 1995 (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. 11.3. 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 Router Advertisements. 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 reset to a uniformly-distributed random value between the configured Minimum_Advertisement_Interval and Maximum_Advertisement_Interval. Expiration of the timer causes the next advertisement to be sent, and a new random value to be chosen. 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 Simpson expires in six months [Page 30] DRAFT IPv6 Neighbor Discovery February 1995 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 accept the All-Routers IPv6 Multicast Address 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: - 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 of zero. In the case of a router becoming a host, the node MUST also drop the All-Routers IPv6 Multicast Address 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 Simpson expires in six months [Page 31] DRAFT IPv6 Neighbor Discovery February 1995 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 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 received advertisement or solicitation does not contain any Node-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 node MUST delay transmission for a random amount of time between 0 and | MAX_ADVERTISEMENT_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. 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. Simpson expires in six months [Page 32] DRAFT IPv6 Neighbor Discovery February 1995 12. Processing Router Advertisements Every IPv6 node MUST process Router Advertisements. All IPv6 nodes MUST accept the All-Nodes IPv6 Multicast Address (FFxx::1) on every interface. 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 "Sending Datagrams". 12.1. Validity All nodes MUST silently discard any received Router Advertisement messages that do not satisfy the following validity checks: - IPv6 Version is correct. - IPv6 Source is a Unicast Address, is not the Unspecified Address, and is not a Cluster or Multicast Address. - When an Authentication Header is present, it is correct. | - ICMP Checksum is correct. - ICMP length (derived from the payload length) is 16 or more octets. - At least one Prefix-Information extension is present. | - For interfaces which are not point-to-point links, the Media- Access extension is present. 12.2. 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. Simpson expires in six months [Page 33] DRAFT IPv6 Neighbor Discovery February 1995 Each entry in the list contains (at least) the following configurable variables: Router_Identifier An IPv6 Unicast Address of a default router. Default: (none) Prefix_Size Each router entry has an associated Prefix_Size. The value ranges from 0 to 127, and indicates the number of bits in the IPv6 Address which define the routing-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 routing-prefix | mapping. If all associated Prefix_Size values are zero, then prefix routing is not in use on that link. Default: 0 Preference The preferability of the Router_Identifier as a default router choice, relative to other router interfaces serving the same | routing-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. NOTES: Any router IPv4 Address acquired from the "Gateway" subfield of the vendor extensions field of a BOOTP packet [RFC- BOOTP?11] are considered to be configured; they are assigned the Simpson expires in six months [Page 34] DRAFT IPv6 Neighbor Discovery February 1995 default preference level of 255, and they do not have an associated LifeTime. Any IPv4 Address found in the "giaddr" field of a BOOTP packet [RFC-BOOTP?3] identifies a BOOTP forwarder which is not necessarily a router; an entry SHOULD NOT be installed in the default Router List. 12.3. Details To process a Router Advertisement, the node scans the list of extensions in it. 12.3.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. 12.3.2. Change-Identifier This extension gives advance indication that an address or prefix will no longer be routable. Applications SHOULD cease to accept new connections with the old value. Existing connections SHOULD issue a Remote Redirect. Change-Identifier extensions MUST preceed Prefix-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 routing-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 Remote Redirect MAY be sent to correspondents to inform them of the change. The node MUST continue to accept datagrams destined for the old IPv6 Simpson expires in six months [Page 35] DRAFT IPv6 Neighbor Discovery February 1995 Address(es), until such time as all stimulus for maintaining the entry has expired. This implies that the node will maintain a LifeTime for most sources of IPv6 Addresses, such as DNS records and dynamic configuration. 12.3.3. Prefix-Information | Prefix-Information extensions MUST preceed Known-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. 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. Simpson expires in six months [Page 36] DRAFT IPv6 Neighbor Discovery February 1995 12.3.4. Known-Identifier | The Known-Identifier extension is used to indicate IPv6 Addresses | bound to other interfaces of the router, or other IPv6 Addresses on the same interface which are not subsumed by the same routing-prefix. | - If the IPv6 Address is not already present in the Router List, a new entry MAY be added, 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 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 Destinations, and it will send a redirect when appropriate. 12.3.5. Node-Heard As in a General or Router Solicitation, the absence of the Node-Heard extension serves as an indication that the router has not yet heard any other Router Advertisement. If the Quality specified is not zero, but is less than the Quality for some other router Node-Heard extension, the Hop Cache entry MAY be updated to point to that router instead. A Routing Header can be used to direct datagrams along the more reliable path. Simpson expires in six months [Page 37] DRAFT IPv6 Neighbor Discovery February 1995 13. Sending Local Redirects Every IPv6 router MUST implement Local Redirect. A router sends a Local Redirect when it receives datagrams for which that router is not the best next-hop to the Destination. The router will forward the datagram to the best next-hop, and return a Local Redirect message to the sending node. A host SHOULD NOT send a Local Redirect. 14. Processing Local Redirects Every IPv6 host MUST process Local Redirects. | On receipt of a valid Local Redirect, a host MUST update its Hop Cache. | Every IPv6 router which is participating in a routing protocol MUST | ignore Local Redirects. 14.1. Validity All nodes MUST silently discard any received Local Redirect messages that do not satisfy the following validity checks: - IPv6 Version is correct. - IPv6 Source is a Unicast Address, is not the Unspecified Address, is not a Cluster or Multicast Address, and is the current next hop router for the target specified in the Known-Identifier | extension(s). - When an Authentication Header is present, it is correct. | - ICMP Checksum is correct. - ICMP length (derived from the payload length) is 16 or more octets. - The Known-Identifier extension indicates one of the IPv6 Unicast | Addresses in the Hop Cache. - For interfaces which are not point-to-point links, the Media- Simpson expires in six months [Page 38] DRAFT IPv6 Neighbor Discovery February 1995 Access extension is present. 14.2. Details Since the routing-prefixes bound to an interface are not required to | be relevant for all Destinations, the next hop specified is always * presumed to be accessible via the same interface through which the | Redirect arrived. The Redirect MUST NOT be discarded simply because | it arrives on an interface which has no matching advertised prefix. RATIONALE: A Mobile Node will likely not have a prefix which matches any router advertised prefixes. When a local host (such as a printer or DNS) responds to a message from the Mobile Node, it will initially send to its preferred router. That router will send a Redirect to the Mobile Node. When a Redirect is received with a non-zero Prefix_Size, it is | treated as if it has a zero Prefix_Size. That is, the cache entry for the Destination (only) would be updated (or created when an entry for that Destination did not exist), with a Prefix_Size of zero. RATIONALE: This recommendation is to protect against routers that erroneously | send Redirects for an entire routing prefix. Simpson expires in six months [Page 39] DRAFT IPv6 Neighbor Discovery February 1995 15. Sending Remote Redirects Every IPv6 node MUST implement Remote Redirects. A node sends a Remote Redirect when it receives a Router Advertisement containing Change-Identifier extensions. The Hop Cache is examined for Destinations accessed through that router. Those remote nodes are sent the Remote Redirect with an indication of a Care-Of-Address to use in order to reach the expiring identification of the node. A Mobile Node MAY also send a Remote Redirect when it receives a datagram which does not have a Routing Header containing its current Care-Of-Address(es). See [Mobility] for details. | The Remote Redirect is only sent to those remote nodes with which the node maintains a Security Association. 16. Processing Remote Redirects Every IPv6 node MUST process Remote Redirects. On receipt of a valid Remote Redirect, the node uses a Routing Header to reach the sender. 16.1. Validity All nodes MUST silently discard any received Remote Redirect messages that do not satisfy the following validity checks: - IPv6 Version is correct. - IPv6 Source is a Unicast Address, is not the Unspecified Address, is not a Cluster or Multicast Address, and indicates one of the IPv6 Unicast Addresses in the Hop Cache. - An Authentication Header is present, and it is correct. | - ICMP Checksum is correct. - ICMP length (derived from the payload length) is 16 or more octets. Simpson expires in six months [Page 40] DRAFT IPv6 Neighbor Discovery February 1995 16.2. Details To process a Remote Redirect, the node scans the list of extensions in it. 16.2.1. Known-Identifier | The Known-Identifier extension is used to indicate the IPv6 Unicast | or Cluster Address which is used as a Care-Of-Address to reach the Source. Simpson expires in six months [Page 41] DRAFT IPv6 Neighbor Discovery February 1995 A. Configuration Summary A.1. Router Configuration 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. A.2. Host Configuration Most hosts need no prior configuration. A node attached to a multi-access link creates a local-use unicast | address from the link address. A node attached to a point-to-point link (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 "Address List". Simpson expires in six months [Page 42] DRAFT IPv6 Neighbor Discovery February 1995 B. Hop Cache Implementation 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 link address | (4) Destination IPv6 Address (5) Destination Prefix_Size (6) Source IPv6 Address (7) Flow Label (8) Path Maximum Transmission Unit (9) Path Round Trip Time Field (4) MAY be the full IPv6 Address of the Destination, or the Cluster which includes the Destination. This is determined by the | routing-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 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 Unicast 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 remote link. (3) The use of only node identifiers may allow the Internet Simpson expires in six months [Page 43] DRAFT IPv6 Neighbor Discovery February 1995 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 routing-prefixes 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. The cache needs to be large enough to include entries for the maximum number of destinations that may be in use at one time. Advertisement updates could indefinitely continue to refresh otherwise unused entries. A Hop Cache entry SHOULD also include control information used to choose an entry for replacement. For example, this might take the form of a "recently used" bit, a use count, or a last-used timestamp. It is also 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 internetwork-layer with each subsequent datagram. Although the Hop Cache, the Router List, and a table of static routes are described as conceptually distinct, in practice they may be combined into a single "routing table" data structure. Simpson expires in six months [Page 44] DRAFT IPv6 Neighbor Discovery February 1995 C. Proxy Advertisements A router MAY proxy for the identifiers of other nodes, using the | Known-Identifier extension. This SHOULD only be used when the router is translating to another internetwork protocol format. Simpson expires in six months [Page 45] DRAFT IPv6 Neighbor Discovery February 1995 D. Examples D.1. Simple Solicitation Assume host A has address 1 and host B has addresses 2 and 3. There is only one interface on A, and only one interface on B. A is trying to talk to B, so it sends a General Solicitation to B, fills in portions of a Hop Cache entry, and waits for the General Advertisement from B. The Known-Identifier extension in the solicitation is 2. | B sends a General Advertisement with the Media-Access for its interface. It also puts 3 in an Known-Identifier extension. | A MUST update its cache entry for 2. A SHOULD also add another cache entry for 3, using the same link | address. This is not required in a minimal memory implementation. D.2. Complex Solicitation Assume that host B had a different interface for 3 on the same link. If host A already had a Hop Cache entry for 3 (using the original | link address), but the advertisement (above) contains a different | link address for 3, A MUST add another cache entry for 3, pointing to 2. This is required in order that the purpose of redundant interfaces on the same link be fulfilled, and 3 is accessible through 2 (and vice versa) when its interface fails. The pairing of IPv6 address and link address can be considered a | tuple consisting of {IPv6 address, interface, link address}. This allows annealing of partitioned links with no effort by hosts. Simpson expires in six months [Page 46] DRAFT IPv6 Neighbor Discovery February 1995 Security Considerations There are a lot of Security issues which are not discussed in this memo. Acknowledgements The document was initially composed of quotations from the RFC-1122 "Requirements for Internet Hosts -- Communication Layers" (Robert Braden, Editor), and RFC-1256 "ICMP Router Discovery Messages" (Steve Deering, Editor), and "Requirements for IP Routers" (Almquist and Kastenholz, Editors). Thanks also for suggestions and contributions from the Simple-IP Working Group. The Dead Node detection method was clarified by Robert Elz. | Special thanks for implementation review by Ran Atkinson (Naval Research Laboratory), Alex Conta (Digital Equipment Corporation), Dan | McDonald (Naval Research Laboratory), Fred Rabouw (Network Systems Netherlands), and Brad Stone (Hewlett-Packard). 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 47] DRAFT IPv6 Neighbor Discovery February 1995 Table of Contents 1. Introduction .......................................... 1 2. Link-Layers ........................................... 1 2.1 Addresses .......................................1 | 2.2 Address Resolution Protocol (ARP) ............... 1 2.3 Trailers ........................................ 2 2.4 Maximum Transmission Unit (MTU) ................. 2 2.5 Maximum Receive Unit (MRU) ...................... 2 2.6 Incoming Interface .............................. 2 2.7 Outgoing Interface .............................. 3 2.8 Unreachable ..................................... 4 3. Sending Datagrams ..................................... 5 3.1 Choosing a Source Address ....................... 5 3.2 Hop Cache ....................................... 6 3.3 Next Hop Decision ............................... 6 3.4 Router Selection ................................ 8 3.5 Static Routes ................................... 9 3.6 Dead Node Detection ............................. 9 4. Processing Datagrams .................................. 12 4.1 Address List .................................... 12 4.2 Details ......................................... 13 5. Sending General Solicitations ......................... 15 5.1 Configuration ................................... 15 5.2 Details ......................................... 15 6. Processing General Solicitations ...................... 18 6.1 Validity ........................................ 18 6.2 Details ......................................... 18 6.2.1 Media-Access .................................... 19 6.2.2 Node-Heard ...................................... 19 7. Sending General Advertisements ........................ 20 7.1 Constants ....................................... 20 7.2 Configuration ................................... 20 7.3 Details ......................................... 20 8. Processing General Advertisements ..................... 22 8.1 Validity ........................................ 22 8.2 Details ......................................... 22 8.2.1 Media-Access .................................... 22 8.2.2 Known-Identifier ................................23 | 8.2.3 Node-Heard ...................................... 23 Simpson expires in six months [Page ii] DRAFT IPv6 Neighbor Discovery February 1995 9. Sending Router Solicitations .......................... 24 9.1 Constants ....................................... 24 9.2 Configuration ................................... 24 9.3 Details ......................................... 25 10. Processing Router Solicitations ....................... 26 10.1 Validity ........................................ 26 10.2 Details ......................................... 26 10.2.1 Media-Access .................................... 27 10.2.2 Node-Heard ...................................... 27 11. Sending Router Advertisements ......................... 28 11.1 Constants ....................................... 28 11.2 Configuration ................................... 28 11.3 Details ......................................... 30 12. Processing Router Advertisements ...................... 33 12.1 Validity ........................................ 33 12.2 Router List ..................................... 33 12.3 Details ......................................... 35 12.3.1 Media-Access .................................... 35 12.3.2 Change-Identifier ............................... 35 12.3.3 Prefix-Information ..............................36 | 12.3.4 Known-Identifier ................................37 | 12.3.5 Node-Heard ...................................... 37 13. Sending Local Redirects ............................... 38 14. Processing Local Redirects ............................ 38 14.1 Validity ........................................ 38 14.2 Details ......................................... 39 15. Sending Remote Redirects .............................. 40 16. Processing Remote Redirects ........................... 40 16.1 Validity ........................................ 40 16.2 Details ......................................... 41 16.2.1 Known-Identifier ................................41 | APPENDICES ................................................... 42 A. Configuration Summary ................................. 42 A.1 Router Configuration ............................ 42 A.2 Host Configuration .............................. 42 B. Hop Cache Implementation .............................. 43 C. Proxy Advertisements .................................. 45 Simpson expires in six months [Page iii] DRAFT IPv6 Neighbor Discovery February 1995 D. Examples .............................................. 46 D.1 Simple Solicitation ............................. 46 D.2 Complex Solicitation ............................ 46 SECURITY CONSIDERATIONS ...................................... 47 ACKNOWLEDGEMENTS ............................................. 47 AUTHOR'S ADDRESS ............................................. 47