--- 1/draft-ietf-ipv6-2461bis-10.txt 2007-03-09 22:12:15.000000000 +0100 +++ 2/draft-ietf-ipv6-2461bis-11.txt 2007-03-09 22:12:15.000000000 +0100 @@ -1,23 +1,23 @@ INTERNET-DRAFT T. Narten, -Expires: June 2007 IBM +Expires: September 2007 IBM Obsoletes: 2461 (if approved) E. Nordmark, Sun Microsystems W. Simpson, Daydreamer H. Soliman, Elevate Technologies - January, 2007 + March, 2007 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other @@ -29,21 +29,21 @@ material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice - Copyright (C) The Internet Society (2007). + Copyright (C) The IETF Trust (2007). Abstract This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. Table of Contents @@ -75,55 +75,55 @@ 5.3. Garbage Collection and Timeout Requirements...............34 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.................42 6.2.4. Sending Unsolicited Router Advertisements............43 - 6.2.5. Ceasing To Be An Advertising Interface...............44 + 6.2.5. Ceasing To Be An Advertising Interface...............43 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.......54 + 7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION.......53 7.1. Message Validation........................................54 7.1.1. Validation of Neighbor Solicitations.................54 7.1.2. Validation of Neighbor Advertisements................55 7.2. Address Resolution........................................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...................59 - 7.2.6. Sending Unsolicited Neighbor Advertisements..........61 + 7.2.6. Sending Unsolicited Neighbor Advertisements..........60 7.2.7. Anycast Neighbor Advertisements......................62 7.2.8. Proxy Neighbor Advertisements........................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............................................72 + 10. PROTOCOL CONSTANTS............................................71 11. SECURITY CONSIDERATIONS.......................................73 11.1 Threat analysis............................................73 11.2 Securing Neighbor Discovery messages.......................74 12. RENUMBERING CONSIDERATIONS....................................75 IANA CONSIDERATIONS................................................76 REFERENCES.........................................................77 Authors' Addresses.................................................79 APPENDIX A: MULTIHOMED HOSTS.......................................80 APPENDIX B: FUTURE EXTENSIONS......................................81 APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............82 @@ -438,21 +438,21 @@ 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 stateless 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 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 + 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 @@ -515,21 +515,21 @@ Router Solicitation: When an interface becomes enabled, hosts may send out Router Solicitations that request routers to generate Router Advertisements immediately rather than at their next scheduled time. Router Advertisement: Routers advertise their presence together with various link and Internet parameters either periodically, or in response to a Router Solicitation message. Router Advertisements contain prefixes that - are used for determining whether an another address + are used for determining whether another address shares the same link (on-link determination) and/or address configuration, a suggested hop limit value, etc. Neighbor Solicitation: Sent by a node to determine the link-layer address of a neighbor, or to verify that a neighbor is still reachable via a cached link-layer address. Neighbor Solicitations are also used for Duplicate Address Detection. Neighbor Advertisement: A response to a Neighbor Solicitation @@ -621,35 +621,36 @@ logical interface having multiple link-layer addresses. Neighbor Discovery allows a router to perform Load balancing for traffic addressed to itself by allowing routers to omit the source link-layer address from Router Advertisement packets, thereby forcing neighbors to use Neighbor Solicitation messages to learn link-layer addresses of routers. Returned Neighbor Advertisement messages can then contain link-layer addresses that differ depending on, e.g., who issued the solicitation. This specification does not - support a mechanism that allows hosts to Load-balance - incoming packets. + define a mechanism that allows hosts to Load-balance + incoming packets. See [LD-SHRE]. Anycast addresses - Anycast addresses identify one of a set of nodes providing an equivalent service, and multiple nodes on the same link may be configured to recognize the same Anycast address. Neighbor Discovery handles anycasts by having nodes expect to receive multiple Neighbor Advertisements for the same target. All advertisements for anycast addresses are tagged as being non-Override advertisements. A non-Override - advertisement is one that does not replace the information - sent by another advertisement. These advertisements are - discussed later in the context of Neighbor advertisement - messages. This invokes specific rules to determine which of - potentially multiple advertisements should be used. + advertisement is one that does not update or replace the + information sent by another advertisement. These + advertisements are discussed later in the context of Neighbor + advertisement messages. This invokes specific rules to + determine which of potentially multiple advertisements should + be used. Proxy advertisements - A node willing to accept packets on behalf of a target address that is unable to respond to Neighbor Solicitations can issue non-Override Neighbor Advertisements. Proxy advertisements are used by Mobile IPv6 home Agents to defend mobile nodes' addresses when they move off-link. However, it is not intended as a general mechanism to handle nodes that, e.g., do not implement this protocol. 3.1. Comparison with IPv4 @@ -742,21 +743,21 @@ Neighbor Discovery supports links with different properties. In the presence of certain properties only a subset of the ND protocol mechanisms are fully specified in this document: point-to-point - Neighbor Discovery handles such links just like multicast links. (Multicast can be trivially provided on point-to-point links, and interfaces can be assigned link-local addresses.) - multicast - Neighbor Discovery supports multicast capable + multicast - Neighbor Discovery operates over multicast capable links as described in this document. non-broadcast multiple access (NBMA) - Redirect, Neighbor Unreachability Detection and next-hop determination should be implemented as described in this document. Address resolution, and the mechanism for delivering Router Solicitations and Advertisements on NBMA links is not specified in this document. Note that if hosts support manual configuration of a list of @@ -1383,26 +1385,23 @@ 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. In other words, if the L flag is not set a host MUST - NOT assume that an address derived from the prefix - is on-link unless it is explicitly told in another - message (e.g. Redirect). 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. + NOT conclude that an address derived from the + prefix is off-link. That is, it MUST NOT update a + previous indication that the address is on-link. A 1-bit autonomous address-configuration flag. When set indicates that this prefix can be used for 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 @@ -4415,25 +4409,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 (2007). This document is subject + Copyright (C) The IETF Trust (2007). 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 + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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 June, 2007. +This Internet-Draft expires September, 2007.