--- 1/draft-ietf-ipv6-2461bis-02.txt 2006-02-05 00:01:56.000000000 +0100 +++ 2/draft-ietf-ipv6-2461bis-03.txt 2006-02-05 00:01:57.000000000 +0100 @@ -1,30 +1,30 @@ INTERNET-DRAFT T. Narten, -Expires: August 2005 IBM +Expires: November 2005 IBM E. Nordmark, Sun Microsystems W. Simpson, Daydreamer H. Soliman, Flarion - February, 2005 + May, 2005 Neighbor Discovery for IP version 6 (IPv6) - + Status of this memo - By submitting this Internet-Draft, we certify that any applicable - patent or other IPR claims of which we are aware have been disclosed, - and any of which we become aware will be disclosed, in accordance - with RFC 3668 (BCP 79). + 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). 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 @@ -49,108 +49,108 @@ 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..............................................9 + 2.4. Requirements.............................................10 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 4.4. Neighbor Advertisement Message Format....................22 4.5. Redirect Message Format..................................24 4.6. Option Formats...........................................26 4.6.2. Prefix Information.................................27 4.6.3. Redirected Header..................................29 4.6.4. MTU................................................30 5. CONCEPTUAL MODEL OF A HOST.....................................31 5.1. Conceptual Data Structures...............................31 5.2. Conceptual Sending Algorithm.............................33 - 5.3. Garbage Collection and Timeout Requirements..............34 + 5.3. Garbage Collection and Timeout Requirements..............35 6. ROUTER AND PREFIX DISCOVERY....................................35 6.1. Message Validation.......................................36 6.1.1. Validation of Router Solicitation Messages.........36 6.1.2. Validation of Router Advertisement Messages........36 6.2. Router Specification.....................................37 6.2.1. Router Configuration Variables....................37 6.2.2. Becoming An Advertising Interface.................41 - 6.2.3. Router Advertisement Message Content..............41 + 6.2.3. Router Advertisement Message Content..............42 6.2.4. Sending Unsolicited Router Advertisements.........43 - 6.2.5. Ceasing To Be An Advertising Interface............43 + 6.2.5. Ceasing To Be An Advertising Interface............44 6.2.6. Processing Router Solicitations...................44 6.2.7. Router Advertisement Consistency..................45 6.2.8. Link-local Address Change.........................46 6.3. Host Specification.......................................47 6.3.1. Host Configuration Variables......................47 6.3.2. Host Variables....................................47 6.3.3. Interface Initialization..........................48 6.3.4. Processing Received Router Advertisements.........48 6.3.5. Timing out Prefixes and Default Routers...........51 6.3.6. Default Router Selection..........................51 6.3.7. Sending Router Solicitations......................52 - 7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION.......53 + 7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION.......54 7.1. Message Validation.......................................54 7.1.1. Validation of Neighbor Solicitations..............54 - 7.1.2. Validation of Neighbor Advertisements.............54 + 7.1.2. Validation of Neighbor Advertisements.............55 7.2. Address Resolution.......................................55 - 7.2.1. Interface Initialization..........................55 + 7.2.1. Interface Initialization..........................56 7.2.2. Sending Neighbor Solicitations....................56 7.2.3. Receipt of Neighbor Solicitations.................57 7.2.4. Sending Solicited Neighbor Advertisements.........58 - 7.2.5. Receipt of Neighbor Advertisements................58 - 7.2.6. Sending Unsolicited Neighbor Advertisements.......60 - 7.2.7. Anycast Neighbor Advertisements...................61 + 7.2.5. Receipt of Neighbor Advertisements................59 + 7.2.6. Sending Unsolicited Neighbor Advertisements.......61 + 7.2.7. Anycast Neighbor Advertisements...................62 7.2.8. Proxy Neighbor Advertisements.....................62 - 7.3. Neighbor Unreachability Detection........................62 + 7.3. Neighbor Unreachability Detection........................63 7.3.1. Reachability Confirmation.........................63 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 11. SECURITY CONSIDERATIONS.......................................72 - 11.1 Threat analysis...........................................72 + 11.1 Threat analysis...........................................73 11.2 Securing Neighbor Discovery messages......................74 - 12. RENUMBERING CONSIDERATIONS....................................74 + 12. RENUMBERING CONSIDERATIONS....................................75 REFERENCES.........................................................76 Authors' Addresses.................................................78 - APPENDIX A: MULTIHOMED HOSTS.......................................78 + APPENDIX A: MULTIHOMED HOSTS.......................................79 APPENDIX B: FUTURE EXTENSIONS......................................80 - APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............80 - APPENDIX D: SUMMARY OF ISROUTER RULES..............................82 - APPENDIX E: IMPLEMENTATION ISSUES..................................83 - Appendix E.1: Reachability confirmations...........................83 + APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............81 + APPENDIX D: SUMMARY OF ISROUTER RULES..............................83 + APPENDIX E: IMPLEMENTATION ISSUES..................................84 + Appendix E.1: Reachability confirmations...........................84 APPENDIX F: CHANGES FROM RFC 2461..................................85 1. INTRODUCTION This specification defines the Neighbor Discovery (ND) protocol for Internet Protocol Version 6 (IPv6). Nodes (hosts and routers) use Neighbor Discovery to determine the link-layer addresses for neighbors known to reside on attached links and to quickly purge cached values that become invalid. Hosts also use Neighbor Discovery to find neighboring routers that are willing to forward packets on @@ -171,22 +171,22 @@ etc., are expected to be provided as specified in this document. The details of how one uses ND on NBMA links are addressed in [IPv6- NBMA]. In addition, [IPv6-3GPP] and [IPv6-CELLULAR] discuss the use of this protocol over some cellular links, which are examples of NBMA links. The authors would like to acknowledge the contributions of the IPv6 working group and, in particular, (in alphabetical order) Ran Atkinson, Jim Bound, Scott Bradner, Alex Conta, Elwyn Davies, Stephen Deering Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, - Robert Hinden, Allison Mankin, Dan McDonald, Charles Perkins, Matt - Thomas, and Susan Thomson. + Robert Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles + Perkins, Matt Thomas, and Susan Thomson. 2. TERMINOLOGY 2.1. General IP - Internet Protocol Version 6. The terms IPv4 and IPv6 are used only in contexts where necessary to avoid ambiguity. ICMP - Internet Message Control Protocol for the Internet @@ -363,25 +363,26 @@ 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 IP (e.g., - using multicast servers), but it is an issue for - further study whether ND should use such facilities + 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 ND services. + 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- @@ -414,46 +415,47 @@ all-routers multicast address - the link-local scope address to reach all routers, FF02::2. solicited-node multicast address - a link-local scope multicast address that is computed as a function of the solicited target's address. The function is described in [ADDR-ARCH]. The function is chosen so that IP addresses which differ only in the - high-order bits, e.g., due to multiple high-order - prefixes associated with different providers, will map - to the same solicited-node address thereby reducing the - number of multicast addresses a node must join. + least significant bits, e.g., due to multiple + high-order prefixes associated with different + providers, will map to the same solicited-node address + thereby reducing the number of multicast addresses a + node must join. link-local address - a unicast address having link-only scope that can be used to reach neighbors. All interfaces on routers MUST have a link-local address. Also, [ADDRCONF] requires that interfaces on hosts have a link-local address. unspecified address - a reserved address value that indicates the lack of an address (e.g., the address is unknown). It is never used as a destination address, but may be used as a source address if the sender does not (yet) know its own address (e.g., while verifying an address is unused during address autoconfiguration [ADDRCONF]). The unspecified address has a value of 0:0:0:0:0:0:0:0. Note that this specification does not strictly comply with the - consistency requirements for the scopes of source and destination - addresses. It is possible in some cases for hosts to use a source - address of a larger scope than the destination address in the IPv6 - header. + consistency requirements in [ADDR-SEL] for the scopes of source and + destination addresses. It is possible in some cases for hosts to use + a source address of a larger scope than the destination address in + the IPv6 header. 2.4. Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [KEYWORDS]. This document also makes use of internal conceptual variables to describe protocol behavior and external variables that an implementation must allow system administrators to change. The @@ -916,22 +917,21 @@ Cur Hop Limit 8-bit unsigned integer. The default value that should be placed in the Hop Count field of the IP header for outgoing IP packets. A value of zero means unspecified (by this router). M 1-bit "Managed address configuration" flag. When set, it indicates that Dynamic Host Configuration Protocol [DHCPv6] is available for address configuration in addition to any addresses autoconfigured using stateless address - autoconfiguration. The use of this flag is - further described in [ADDRCONF]. + autoconfiguration. O 1-bit "Other configuration" flag. When set, it indicates that [DHCPv6lite] is available for autoconfiguration of other (non-address) information. Examples of such information are DNS- related information or information on other servers within the network. Reserved A 6-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the @@ -1160,21 +1160,21 @@ responding to a unicast Neighbor Solicitation this option SHOULD be included. The option MUST be included for multicast solicitations in order to avoid infinite Neighbor Solicitation "recursion" when the peer node does not have a cache entry to return a Neighbor Advertisements message. When responding to unicast solicitations, the option can be omitted since the sender of the solicitation has the correct link- - layer address; otherwise it would not have be able + layer address; otherwise it would not be able to send the unicast solicitation in the first place. However, including the link-layer address in this case adds little overhead and eliminates a potential race condition where the sender deletes the cached link-layer address prior to receiving a response to a previous solicitation. 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. @@ -1367,38 +1367,38 @@ Fields: 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 other flags in the prefix + (when combined with the L flag in the prefix 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 to the prefix being on-link and others being off- link. A 1-bit autonomous address-configuration flag. When set indicates that this prefix can be used for - autonomous address configuration as specified in + stateless address configuration as specified in [ADDRCONF]. Reserved1 6-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Valid Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for the purpose of on-link determination. A value of all one bits @@ -2074,21 +2073,21 @@ A router sends periodic as well as solicited Router Advertisements out its advertising interfaces. Outgoing Router Advertisements are filled with the following values consistent with the message format given in Section 4.2: - In the Router Lifetime field: the interface's configured AdvDefaultLifetime. - In the M and O flags: the interface's configured AdvManagedFlag - and AdvOtherConfigFlag, respectively. See [ADDRCONF]. + and AdvOtherConfigFlag, respectively. - In the Cur Hop Limit field: the interface's configured CurHopLimit. - In the Reachable Time field: the interface's configured AdvReachableTime. - In the Retrans Timer field: the interface's configured AdvRetransTimer. @@ -2525,21 +2523,21 @@ the result of a previously-received advertisement, reset its invalidation timer to the Valid Lifetime value in the Prefix Information option. If the new Lifetime value is zero, time-out the prefix immediately (see Section 6.3.5). - If the Prefix Information option's Valid Lifetime field is zero, and the prefix is not present in the host's Prefix List, silently ignore the option. Stateless address autoconfiguration [ADDRCONF] may in some - circumstances increase the Valid Lifetime of a prefix or ignore it + circumstances use a larger Valid Lifetime of a prefix or ignore it completely in order to prevent a particular denial of service attack. However, since the effect of the same denial of service targeted at the on-link prefix list is not catastrophic (hosts would send packets to a default router and receive a redirect rather than sending packets directly to a neighbor) the Neighbor Discovery protocol does not impose such a check on the prefix lifetime values. Similarly, [ADDRCONF] may impose certain restrictions on the prefix length for address configuration purposes. Therefore, the prefix might be rejected by [ADDRCONF] implementation in the host. However, the prefix length is still valid for on-link determination when combined @@ -2770,20 +2768,30 @@ 7.2. Address Resolution Address resolution is the process through which a node determines the link-layer address of a neighbor given only its IP address. Address resolution is performed only on addresses that are determined to be on-link and for which the sender does not know the corresponding link-layer address (see section 5.2). Address resolution is never performed on multicast addresses. + It is possible that a host may receive a solicitation or a router + advertisement without a link-layer address option included. These + messages MUST not create or update neighbor cache entries, except + with respect to the IsRouter flag as specified in sections 6.3.4 and + 7.2.5. If a neighbor cache entry does not exist for the source of + such a message, Address Resolution will be required before unicast + communications with that address to begin. This is particularly + relevant for unicast responses to solicitations where an additional + packet exchange is required for advertisement delivery. + 7.2.1. Interface Initialization 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 @@ -2843,21 +2850,21 @@ Retransmissions MUST be rate-limited to at most one solicitation per neighbor every RetransTimer milliseconds. If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT solicitations, address resolution has failed. The sender MUST return ICMP destination unreachable indications with code 3 (Address Unreachable) for each packet queued awaiting address resolution. 7.2.3. Receipt of Neighbor Solicitations - A valid Neighbor Solicitation that does not meet any the following + A valid Neighbor Solicitation that does not meet any of the following requirements MUST be silently discarded: - The Target Address is a "valid" unicast or anycast address assigned to the receiving interface [ADDRCONF], - The Target Address is a unicast or anycast address for which the node is offering proxy service, or - The Target Address is a "tentative" address on which Duplicate Address Detection is being performed [ADDRCONF]. @@ -2951,21 +2958,21 @@ 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 not in INCOMPLETE state, the receiving + If the Neighbor Cache entry is in INCOMPLETE state, 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. @@ -2976,25 +2983,25 @@ 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, both the Override flag is clear - and 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: + 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: - 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). - 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. @@ -3187,22 +3194,22 @@ and a node is sending packets to a neighbor, the node actively probes the neighbor using unicast Neighbor Solicitation messages to verify that the forward path is still working. The receipt of a solicited Neighbor Advertisement serves as reachability confirmation, since advertisements with the Solicited flag set to one are sent only in response to a Neighbor Solicitation. Receipt of other Neighbor Discovery messages such as Router Advertisements and Neighbor Advertisement with the Solicited flag set to zero MUST NOT be treated as a reachability confirmation. Receipt - of unsolicited messages only confirm the one-way path from the sender - to the recipient node. In contrast, Neighbor Unreachability + of unsolicited messages only confirms the one-way path from the + sender to the recipient node. In contrast, Neighbor Unreachability Detection requires that a node keep track of the reachability of the forward path to a neighbor from the its perspective, not the neighbor's perspective. Note that receipt of a solicited advertisement indicates that a path is working in both directions. The solicitation must have reached the neighbor, prompting it to generate an advertisement. Likewise, receipt of an advertisement indicates that the path from the sender to the recipient is working. However, the latter fact is known only to the recipient; the advertisement's sender has no direct way of knowing that the advertisement it sent actually reached a neighbor. From the @@ -3432,21 +3439,21 @@ - the Source Address field of the packet identifies a neighbor, and - the router determines (by means outside the scope of this specification) that a better first-hop node resides on the same link as the sending node for the Destination Address of the packet being forwarded, and - the Destination Address of the packet is not a multicast - address, and + address The transmitted redirect packet contains, consistent with the message format given in Section 4.5: - In the Target Address field: the address to which subsequent packets for the destination SHOULD be sent. If the target is a router, that router's link-local address MUST be used. If the target is a host the target address field MUST be set to the same value as the Destination Address field. @@ -3645,65 +3652,64 @@ packets destined for other nodes. This section deals with the main threats related to Neighbor Discovery messages and possible security mechanisms that can mitigate these threats. 11.1 Threat analysis This section discusses the main threats associated with Neighbor Discovery. A more detailed analysis can be found in [PSREQ]. The main vulnerabilities of the protocol fall under three categories: - - DoS attacks - - Address spoofing attacks + - Denial of Service (DoS) attacks. + - Address spoofing attacks. - Router spoofing attacks. An example of denial of service attacks is that a node on the link that can send packets with an arbitrary IP source address can both advertise itself as a default router and also send "forged" Router Advertisement messages that immediately time out all other default routers as well as all on-link prefixes. An intruder can achieve this by sending out multiple Router Advertisements, one for each legitimate router, with the source address set to the address of another router, the Router Lifetime field set to zero, and the Preferred and Valid lifetimes set to zero for all the prefixes. Such an attack would cause all packets, for both on-link and off-link destinations, to go to the rogue router. That router can then selectively examine, modify or drop all packets sent on the link. The - Neighbor Unreachability Detection will not detect such a black hole - as long as the rogue router politely answers the NUD probes with a - Neighbor Advertisement with the R-bit set. + Neighbor Unreachability Detection (NUD) will not detect such a black + hole as long as the rogue router politely answers the NUD probes with + a Neighbor Advertisement with the R-bit set. It is also possible for any host to launch a DoS attack on another host by preventing it from configuring an address using [ADDRCONF]. The protocol does not allow hosts to verify whether the sender of a Neighbor Advertisement is the true owner of the IP address included in the message. Redirect attacks can also be achieved by any host in order to flood a victim or steal its traffic. A host can send a Neighbor advertisement (in response to a solicitation) that contains its IP address and a victim's link layer address in order to flood the victim with unwanted traffic. Alternatively, the host can send a Neighbor Advertisement that includes a victim's IP address and its own link layer address to overwrite an existing entry in the sender's destination cache, thereby forcing the sender to forward all of the victim's traffic to itself. The trust model for redirects is the same as in IPv4. A redirect is accepted only if received from the same router that is currently - being used for that destination. It is natural to trust the routers - on the link. If a host has been redirected to another node (i.e., - the destination is on-link) there is no way to prevent the target - from issuing another redirect to some other destination. However, - this exposure is no worse than it was before being redirected; the - target host, once subverted, could always act as a hidden router to - forward traffic elsewhere. + being used for that destination. If a host has been redirected to + another node (i.e., the destination is on-link) there is no way to + prevent the target from issuing another redirect to some other + destination. However, this exposure is no worse than it was before + being redirected; the target host, once subverted, could always act + as a hidden router to forward traffic elsewhere. The protocol contains no mechanism to determine which neighbors are authorized to send a particular type of message (e.g., Router Advertisements); any neighbor, presumably even in the presence of authentication, can send Router Advertisement messages thereby being able to cause denial of service. Furthermore, any neighbor can send proxy Neighbor Advertisements as well as unsolicited Neighbor Advertisements as a potential denial of service attack. Many link layers are also subject to different denial of service @@ -3732,21 +3738,24 @@ resolution or neighbor solicitation messages as documented in [ICMPIKE]. The security of Neighbor Discovery messages through dynamic keying is outside the scope of this document and is addressed in [SEND]. In some cases, it may be acceptable to use statically configured security associations with either [IPv6-AH] or [IPv6-ESP] to secure Neighbor Discovery messages. However, it is important to note that statically configured security associations are not scalable (especially when considering multicast links) and are therefore - limited to small networks with known hosts. + limited to small networks with known hosts. In any case, if either + [IPv6-AH] or [IPv6-ESP] is used, ND packets MUST be verified for the + purpose of authentication. Packets that fail authentication checks + MUST be silently discarded. 12. RENUMBERING CONSIDERATIONS The Neighbor Discovery protocol together with IPv6 Address Autoconfiguration [ADDRCONF] provides mechanisms to aid in renumbering - new prefixes and addresses can be introduced and old ones can be deprecated and removed. The robustness of these mechanisms is based on all the nodes on the link receiving the Router Advertisement messages in a timely manner. @@ -3823,22 +3831,26 @@ [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. INFORMATIVE [ADDRCONF] Thomson, S. Narten, T, and T. Jinmei, "IPv6 Address - Autoconfiguration", draft-ietf-ipv6-rfc2462bis-07, Dec - 2004. + Autoconfiguration", draft-ietf-ipv6-rfc2462bis-08, May + 2005. + + [ADDR-SEL] Draves, R., "Default Address Selection for Internet + Protocol version 6 (IPv6)", RFC 3484, February 2003. + [ANYCST] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. [ARP] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37, RFC 826, November 1982. [ASSIGNED] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. [DHCPv6] Droms, R., Ed, "Dynamic Host Configuration Protocol for @@ -3994,28 +4007,24 @@ 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. Under - similar conditions in the non-multihomed host case, a node - treats all destinations as residing on-link, and communication - proceeds. In the multihomed case, however, additional - information is needed to select the proper outgoing interface. - Alternatively, a node could attempt to perform address - resolution on all interfaces, a step involving significant - complexity that is not present in the non-multihomed host case. + 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 @@ -4238,21 +4247,21 @@ directly (i.e., without an expensive lookup) once the TCP packet has been demultiplexed to its corresponding control block. For other implementation it may be possible to piggyback the reachability confirmation on the next packet submitted to IP assuming that the implementation guards against the piggybacked confirmation becoming stale when no packets are sent to IP for an extended period of time. TCP must also guard against thinking "stale" information indicates current reachability. For example, new data received 30 minutes after a window has opened up does not constitute a confirmation that - the path is currently working. In merely indicates that 30 minutes + the path is currently working. It merely indicates that 30 minutes ago the window update reached the peer i.e. the path was working at that point in time. An implementation must also take into account TCP zero-window probes that are sent even if the path is broken and the window update did not reach the peer. For UDP based applications (RPC, DNS) it is relatively simple to make the client send reachability confirmations when the response packet is received. It is more difficult and in some cases impossible for the server to generate such confirmations since there is no flow control, i.e., the server can not determine whether a received @@ -4303,20 +4312,23 @@ o Clarified router behaviour when receiving a Router Solicitation without SLLAO. o Clarified that inconsistency checks for CurHopLimit are done for none zero values only. o Rearranged section 7.2.5 for clarity and described the processing when receiving the NA in INCOMPLETE state. + o Added clarifications in section 7.2 on how a node should react + upon receiving a message without SLLAO. + o Miscellaneous editorials. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information @@ -4331,25 +4343,25 @@ http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Full Copyright Statement - Copyright (C) The Internet Society (2004). This document is subject + Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 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 August, 2005. +This Internet-Draft expires November, 2005.