--- 1/draft-ietf-ipv6-2461bis-03.txt 2006-02-05 00:01:58.000000000 +0100 +++ 2/draft-ietf-ipv6-2461bis-04.txt 2006-02-05 00:01:58.000000000 +0100 @@ -1,23 +1,23 @@ INTERNET-DRAFT T. Narten, -Expires: November 2005 IBM +Expires: January 2006 IBM E. Nordmark, Sun Microsystems W. Simpson, Daydreamer H. Soliman, Flarion - May, 2005 + July, 2005 Neighbor Discovery for IP version 6 (IPv6) - + Status of this memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. By submitting this Internet-Draft, we accept the provisions of Section 4 of RFC 3667 (BCP 78). @@ -49,21 +49,21 @@ about the paths to active neighbors. Table of Contents 1. INTRODUCTION....................................................4 2. TERMINOLOGY.....................................................4 2.1. General...................................................4 2.2. Link Types................................................8 2.3. Addresses.................................................9 - 2.4. Requirements.............................................10 + 2.4. Requirements..............................................9 3. PROTOCOL OVERVIEW..............................................10 3.1. Comparison with IPv4.....................................13 3.2. Supported Link Types.....................................15 3.3. Securing Neighbor Discovery messages......................17 4. MESSAGE FORMATS................................................17 4.1. Router Solicitation Message Format.......................17 4.2. Router Advertisement Message Format......................18 4.3. Neighbor Solicitation Message Format.....................20 @@ -119,23 +119,23 @@ 7.3.2. Neighbor Cache Entry States.......................64 7.3.3. Node Behavior.....................................65 8. REDIRECT FUNCTION..............................................67 8.1. Validation of Redirect Messages..........................67 8.2. Router Specification.....................................68 8.3. Host Specification.......................................69 9. EXTENSIBILITY - OPTION PROCESSING..............................70 - 10. PROTOCOL CONSTANTS............................................71 + 10. PROTOCOL CONSTANTS............................................72 - 11. SECURITY CONSIDERATIONS.......................................72 + 11. SECURITY CONSIDERATIONS.......................................73 11.1 Threat analysis...........................................73 11.2 Securing Neighbor Discovery messages......................74 12. RENUMBERING CONSIDERATIONS....................................75 REFERENCES.........................................................76 Authors' Addresses.................................................78 APPENDIX A: MULTIHOMED HOSTS.......................................79 @@ -361,28 +361,27 @@ broadcast) or a subset of all neighbors. point-to-point - a link that connects exactly two interfaces. A point-to-point link is assumed to have multicast capability and have a link-local address. non-broadcast multi-access (NBMA) - a link to which more than two interfaces can attach, but that does not support a native form of multicast or broadcast (e.g., X.25, ATM, frame relay, etc.). - Note that all link types (including NBMA) are expected to provide multicast service for applications that need it(e.g., using multicast servers). However, it is an issue for further study - whether ND should use such facilities - or an alternate mechanism that provides the - equivalent multicast capability for ND. + whether ND should use such facilities or an + alternate mechanism that provides the equivalent + multicast capability for ND. shared media - a link that allows direct communication among a number of nodes, but attached nodes are configured in such a way that they do not have complete prefix information for all on-link destinations. That is, at the IP level, nodes on the same link may not know that they are neighbors; by default, they communicate through a router. Examples are large (switched) public data networks such as SMDS and B- ISDN. Also known as "large clouds". See [SH- @@ -1259,21 +1257,22 @@ be included (if known). Note that on NBMA links, hosts may rely on the presence of the Target Link- Layer Address option in Redirect messages as the means for determining the link-layer addresses of neighbors. In such cases, the option MUST be included in Redirect messages. Redirected Header As much as possible of the IP packet that triggered the sending of the Redirect without making the - redirect packet exceed 1280 octets. + redirect packet exceed the minimum MTU specified in + [IPv6]. 4.6. Option Formats Neighbor Discovery messages include zero or more options, some of which may appear multiple times in the same message. Options should be padded when necessary to ensure that they end on their natural 64- bit boundaries. All options are of the form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 @@ -1368,21 +1367,21 @@ Type 3 Length 4 Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. The prefix length field provides necessary information for on-link determination (when combined with the L flag in the prefix - option). It also assists with address + information option). It also assists with address autoconfiguration as specified in [ADDRCONF], for which there may be more restrictions on the prefix length. L 1-bit on-link flag. When set, indicates that this prefix can be used for on-link determination. When not set the advertisement makes no statement about on-link or off-link properties of the prefix. For instance, the prefix might be used for address configuration with some of the addresses belonging @@ -1456,22 +1455,23 @@ Type 4 Length The length of the option in units of 8 octets. Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver. IP header + data The original packet truncated to ensure that the - size of the redirect message does not exceed 1280 - octets. + size of the redirect message does not exceed the + minimum MTU required to support IPv6 as specified + in [IPv6]. Description The Redirected Header option is used in Redirect messages and contains all or part of the packet that is being redirected. This option MUST be silently ignored for other Neighbor Discovery messages. 4.6.4. MTU @@ -2790,25 +2787,25 @@ When a multicast-capable interface becomes enabled the node MUST join the all-nodes multicast address on that interface, as well as the solicited-node multicast address corresponding to each of the IP addresses assigned to the interface. The set of addresses assigned to an interface may change over time. New addresses might be added and old addresses might be removed [ADDRCONF]. In such cases the node MUST join and leave the solicited-node multicast address corresponding to the new and old addresses, respectively. Joining the solicited-node multicast address - SHOULD be done using the Multicast Listener Discovery [MLD] protocol. - Note that multiple unicast addresses may map into the same solicited- - node multicast address; a node MUST NOT leave the solicited-node - multicast group until all assigned addresses corresponding to that - multicast address have been removed. + SHOULD be done using the Multicast Listener Discovery [MLD] or + [MLDv2] protocols. Note that multiple unicast addresses may map into + the same solicited-node multicast address; a node MUST NOT leave the + solicited-node multicast group until all assigned addresses + corresponding to that multicast address have been removed. 7.2.2. Sending Neighbor Solicitations When a node has a unicast packet to send to a neighbor, but does not know the neighbor's link-layer address, it performs address resolution. For multicast-capable interfaces this entails creating a Neighbor Cache entry in the INCOMPLETE state and transmitting a Neighbor Solicitation message targeted at the neighbor. The solicitation is sent to the solicited-node multicast address corresponding to the target address. @@ -2946,93 +2943,91 @@ If no entry exists, the advertisement SHOULD be silently discarded. There is no need to create an entry if none exists, since the recipient has apparently not initiated any communication with the target. Once the appropriate Neighbor Cache entry has been located, the specific actions taken depend on the state of the Neighbor Cache entry, the flags in the advertisement and the actual link-layer address supplied. - In any state, if the link layer has addresses and an unsolicited - Neighbor Advertisement is received with the O flag cleared, with no - Target Link-Layer address option included, the receiving node SHOULD - silently discard the received advertisement. - If the target's Neighbor Cache entry is in the INCOMPLETE state when - the advertisement is received, one of two things happen: If the - advertisement were solicited, the state is changed to REACHABLE. - Otherwise, the state is set to STALE. Note that the Override flag is - ignored if the entry is in the - INCOMPLETE state. - - If the Neighbor Cache entry is in INCOMPLETE state, the receiving - node performs the following steps: + the advertisement is received, one of two things happens. If the + link layer has addresses and no Target Link-Layer address option is + included, the receiving node SHOULD silently discard the received + advertisement. Otherwise, the receiving node performs the following + steps: - It records the link-layer address in the Neighbor Cache entry. - If the advertisement's Solicited flag is set, the state of the entry is set to REACHABLE, otherwise it is set to STALE. - It sets the IsRouter flag in the cache entry based on the Router flag in the received advertisement. - It sends any packets queued for the neighbor awaiting address resolution. + Note that the Override flag is ignored if the entry is in the + INCOMPLETE state. + If the target's Neighbor Cache entry is in any state other than INCOMPLETE when the advertisement is received, the following actions take place: I. If the Override flag is clear and the supplied link-layer address differs from that in the cache, then one of two actions takes place: a. If the state of the entry is REACHABLE, set it to STALE, but do not update the entry in any other way. - b. Otherwise, the received advertisement should be ignored and MUST - NOT update the cache. - II. If the Override flag is set, or the supplied Override flag is - Clear, or the supplied link-layer address is the same as that in - the cache, or no Target Link-layer address option was supplied, - the received advertisement MUST update the Neighbor Cache entry - as follows: + b. Otherwise, the received advertisement should be ignored and + MUST NOT update the cache. + + II. If the Override flag is set, or the supplied link-layer address + is the same as that in the cache, or no Target Link-layer address + option was supplied, the received advertisement MUST update the + Neighbor Cache entry as follows: - The link-layer address in the Target Link-Layer Address option - MUST be inserted in the cache (if one is supplied and is different - than the already recorded address). + MUST be inserted in the cache (if one is supplied and is + Different than the already recorded address). - - If the Solicited flag is set, the state of the entry MUST be set - to REACHABLE. If the Solicited flag is zero and the link-layer - address was updated with a different address the state MUST be set - to STALE. Otherwise, the entry's state remains unchanged. + - If the Solicited flag is set, the state of the entry MUST be + set to REACHABLE. If the Solicited flag is zero and the link + layer address was updated with a different address the state + MUST be set to STALE. Otherwise, the entry's state remains + unchanged. An advertisement's Solicited flag should only be set if the - advertisement is a response to a Neighbor Solicitation. Because - Neighbor Unreachability Detection Solicitations are sent to the - cached link-layer address, receipt of a solicited advertisement - indicates that the forward path is working. Receipt of an - unsolicited advertisement, however, suggests that a neighbor has - urgent information to announce (e.g., a changed link-layer - address). If the urgent information indicates a change from what - a node is currently using, the node should verify the reachability - of the (new) path when it sends the next packet. There is no need - to update the state for unsolicited advertisements that do not - change the contents of the cache. + advertisement is a response to a Neighbor Solicitation. + Because Neighbor Unreachability Detection Solicitations are + sent to the cached link-layer address, receipt of a solicited + advertisement indicates that the forward path is working. + Receipt of an unsolicited advertisement, however, suggests that + a neighbor has urgent information to announce (e.g., a changed + link-layer address). If the urgent information indicates a + change from what a node is currently using, the node should + verify the reachability of the (new) path when it sends the + next packet. There is no need to update the state for + unsolicited advertisements that do not change the contents of + the cache. - The IsRouter flag in the cache entry MUST be set based on the - Router flag in the received advertisement. In those cases where - the IsRouter flag changes from TRUE to FALSE as a result of this - update, the node MUST remove that router from the Default Router - List and update the Destination Cache entries for all destinations - using that neighbor as a router as specified in Section 7.3.3. - This is needed to detect when a node that is used as a router - stops forwarding packets due to being configured as a host. + Router flag in the received advertisement. In those cases + where the IsRouter flag changes from TRUE to FALSE as a result + of this update, the node MUST remove that router from the + Default Router List and update the Destination Cache entries + for all destinations using that neighbor as a router as + specified in Section 7.3.3. This is needed to detect when a + node that is used as a router stops forwarding packets due to + being configured as a host. The above rules ensure that the cache is updated either when the Neighbor Advertisement takes precedence (i.e., the Override flag is set) or when the Neighbor Advertisement refers to the same link-layer address that is currently recorded in the cache. If none of the above apply, the advertisement prompts future Neighbor Unreachability Detection (if it is not already in progress) by changing the state in the cache entry. 7.2.6. Sending Unsolicited Neighbor Advertisements @@ -3115,21 +3110,21 @@ Under limited circumstances, a router MAY proxy for one or more other nodes, that is, through Neighbor Advertisements indicate that it is willing to accept packets not explicitly addressed to itself. For example, a router might accept packets on behalf of a mobile node that has moved off-link. The mechanisms used by proxy are identical to the mechanisms used with anycast addresses. A proxy MUST join the solicited-node multicast address(es) that correspond to the IP address(es) assigned to the node for which it is - proxying. This SHOULD be done using [MLD]. + proxying. This SHOULD be done using [MLD] or [MLDv2]. All solicited proxy Neighbor Advertisement messages MUST have the Override flag set to zero. This ensures that if the node itself is present on the link its Neighbor Advertisement (with the Override flag set to one) will take precedence of any advertisement received from a proxy. A proxy MAY send unsolicited advertisements with the Override flag set to one as specified in Section 7.2.6, but doing so may cause the proxy advertisement to override a valid entry created by the node itself. @@ -3459,22 +3453,22 @@ - In the Destination Address field: the destination address of the invoking IP packet. - In the options: o Target Link-Layer Address option: link-layer address of the target, if known. o Redirected Header: as much of the forwarded packet as can - fit without the redirect packet exceeding 1280 octets in - size. + fit without the redirect packet exceeding the minimum MTU + required to support IPv6 as specified in [IPv6]. A router MUST limit the rate at which Redirect messages are sent, in order to limit the bandwidth and processing costs incurred by the Redirect messages when the source does not correctly respond to the Redirects, or the source chooses to ignore unauthenticated Redirect messages. More details on the rate-limiting of ICMP error messages can be found in [ICMPv6]. A router MUST NOT update its routing tables upon receipt of a Redirect. @@ -3565,35 +3559,35 @@ receivers MUST be prepared to process them independently of their order. There can also be multiple instances of the same option in a message (e.g., Prefix Information options). If the number of included options in a Router Advertisement causes the advertisement's size to exceed the link MTU, the router can send multiple separate advertisements each containing a subset of the options. The amount of data to include in the Redirected Header option MUST be - limited so that the entire redirect packet does not exceed 1280 - octets. + limited so that the entire redirect packet does not exceed the + minimum MTU required to support IPv6 as specified in [IPv6]. All options are a multiple of 8 octets of length, ensuring appropriate alignment without any "pad" options. The fields in the options (as well as the fields in ND packets) are defined to align on their natural boundaries (e.g., a 16-bit field is aligned on a 16-bit boundary) with the exception of the 128-bit IP addresses/prefixes, which are aligned on a 64-bit boundary. The link-layer address field contains an uninterpreted octet string; it is aligned on an 8-bit boundary. The size of an ND packet including the IP header is limited to the - link MTU (which is at least 1280 octets). When adding options to an - ND packet a node MUST NOT exceed the link MTU. + link MTU. When adding options to an ND packet a node MUST NOT exceed + the link MTU. Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message. 10. PROTOCOL CONSTANTS Router constants: MAX_INITIAL_RTR_ADVERT_INTERVAL 16 seconds @@ -3893,27 +3890,34 @@ [IPv6-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [MLD] Deering, S., Fenner, W, and B. Haberman, "Multicast Listener Discovery for IPv6", RFC 2710, October 1999. + [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery + Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. + [NDMAN] Arkko, J., "Manual Configuration of Security Associations for IPv6 Neighbor Discovery", draft-arkko- manual-icmpv6-sas-02 (work in progress), March 2003. [RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991. + [RTSEL] Draves, R. and D. Thaler, "Default Router Preferences + and more Specific Routes", draft-ietf-ipv6-router- + selection-07, (work in progress), January 2005. + [SH-MEDIA] Braden, R., Postel, J. and Y. Rekhter, "Internet Architecture Extensions for Shared Media", RFC 1620, May 1994. [SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-04 (work in progress), February 2004. [SYNC] S. Floyd, V. Jacobson, "The Synchronization of Periodic @@ -3964,21 +3967,22 @@ Email: H.Soliman@flarion.com APPENDIX A: MULTIHOMED HOSTS There are a number of complicating issues that arise when Neighbor Discovery is used by hosts that have multiple interfaces. This section does not attempt to define the proper operation of multihomed hosts with regard to Neighbor Discovery. Rather, it identifies issues that require further study. Implementors are encouraged to experiment with various approaches to making Neighbor Discovery work - on multihomed hosts and to report their experiences. + on multihomed hosts and to report their experiences. Further work + related to this problem can be found in [RTSEL]. If a multihomed host receives Router Advertisements on all of its interfaces, it will (probably) have learned on-link prefixes for the addresses residing on each link. When a packet must be sent through a router, however, selecting the "wrong" router can result in a suboptimal or non-functioning path. There are number of issues to consider: 1) In order for a router to send a redirect, it must determine that the packet it is forwarding originates from a neighbor. The @@ -4003,39 +4006,30 @@ case. 3) Even if the first-hop router does have a route for a destination, there may be a better route via another interface. No mechanism exists for the multihomed host to detect this situation. If a multihomed host fails to receive Router Advertisements on one or more of its interfaces, it will not know (in the absence of configured information) which destinations are on-link on the - affected interface(s). This leads to a number of problems: - - 1) If no Router Advertisement is received on any interfaces, a - multihomed host will have no way of knowing which interface to - send packets out on, even for on-link destinations. - One possible approach for a multihomed node would be to attempt - to perform address resolution on all interfaces, a step - involving significant complexity. - - 2) If Router Advertisements are received on some, but not all - interfaces, a multihomed host could choose to only send packets - out on the interfaces on which it has received Router - Advertisements. A key assumption made here, however, is that - routers on those other interfaces will be able to route packets - to the ultimate destination, even when those destinations reside - on the subnet to which the sender connects, but has no on-link - prefix information. Should the assumption be FALSE, - communication would fail. Even if the assumption holds, packets - will traverse a sub-optimal path. + affected interface(s). This leads to the following problem: If Router + Advertisements are received on some, but not all interfaces, a + multihomed host could choose to only send packets out on the + interfaces on which it has received Router Advertisements. A key + assumption made here, however, is that routers on those other + interfaces will be able to route packets to the ultimate destination, + even when those destinations reside on the subnet to which the sender + connects, but has no on-link prefix information. Should the + assumption be FALSE, communication would fail. Even if the assumption + holds, packets will traverse a sub-optimal path. APPENDIX B: FUTURE EXTENSIONS Possible extensions for future study are: o Using dynamic timers to be able to adapt to links with widely varying delay. Measuring round trip times, however, requires acknowledgments and sequence numbers in order to match received Neighbor Advertisements with the actual Neighbor Solicitation that triggered the advertisement. Implementors wishing to experiment @@ -4080,25 +4074,33 @@ retransmissions. INCOMPLETE NA, Solicited=0, Record link-layer STALE Override=any address. Send queued packets. INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE Override=any address. Send queued packets. + INCOMPLETE NA, Solicited=any, Retransmit NS unchanged + Override=any, No Start retransmit + Link-layer address timer + !INCOMPLETE NA, Solicited=1, - REACHABLE Override=0 Same link-layer address as cached. + !INCOMPLETE NA, Solicited=any, Update content of unchanged + Override=any, No IsRouter flag. + link-layer address + REACHABLE NA, Solicited=1, - STALE Override=0 Different link-layer address than cached. STALE, PROBE NA, Solicited=1, - unchanged Or DELAY Override=0 Different link-layer address than cached. @@ -4150,20 +4152,23 @@ - NS, RS, RA, Redirect Create entry. STALE INCOMPLETE NS, RS, RA, Redirect Record link-layer STALE address. Send queued packets. !INCOMPLETE NS, RS, RA, Redirect Update link-layer STALE Different link-layer address address than cached. + INCOMPLETE NS, RS No link-layer - unchanged + address + !INCOMPLETE NS, RS, RA, Redirect - unchanged Same link-layer address as cached. APPENDIX D: SUMMARY OF ISROUTER RULES This appendix presents a summary of the rules for maintaining the IsRouter flag as specified in this document. The background for these rules is that the ND messages contain, @@ -4357,11 +4362,11 @@ Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. -This Internet-Draft expires November, 2005. +This Internet-Draft expires January, 2006.