--- 1/draft-ietf-ipv6-2461bis-09.txt 2007-01-08 22:12:27.000000000 +0100 +++ 2/draft-ietf-ipv6-2461bis-10.txt 2007-01-08 22:12:27.000000000 +0100 @@ -1,23 +1,23 @@ INTERNET-DRAFT T. Narten, -Expires: April 2007 IBM +Expires: June 2007 IBM Obsoletes: 2461 (if approved) E. Nordmark, Sun Microsystems W. Simpson, Daydreamer H. Soliman, - Flarion - October, 2006 + Elevate Technologies + January, 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,127 +29,117 @@ 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 (2006). + Copyright (C) The Internet Society (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 - 1. INTRODUCTION....................................................4 - + 1. INTRODUCTION....................................................3 2. TERMINOLOGY.....................................................4 - 2.1. General...................................................4 - 2.2. Link Types................................................8 - 2.3. Addresses.................................................9 - 2.4. Requirements.............................................10 - + 2.1. General....................................................4 + 2.2. Link Types.................................................7 + 2.3. Addresses..................................................9 + 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 - + 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 - + 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.1. Source/Target Link-layer Address.....................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..............35 - + 5.1. Conceptual Data Structures................................31 + 5.2. Conceptual Sending Algorithm..............................33 + 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........37 - 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.6. Processing Router Solicitations...................44 - 6.2.7. Router Advertisement Consistency..................46 - 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 - + 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.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.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.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 - + 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.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 - + 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 - 11. SECURITY CONSIDERATIONS.......................................73 - 11.1 Threat analysis...........................................73 - 11.2 Securing Neighbor Discovery messages......................74 - + 11.1 Threat analysis............................................73 + 11.2 Securing Neighbor Discovery messages.......................74 12. RENUMBERING CONSIDERATIONS....................................75 - - REFERENCES.........................................................76 - + 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 APPENDIX D: SUMMARY OF ISROUTER RULES..............................84 APPENDIX E: IMPLEMENTATION ISSUES..................................85 - Appendix E.1: Reachability confirmations...........................85 APPENDIX F: CHANGES FROM RFC 2461..................................86 + Intellectual Property Statement....................................87 + Full Copyright Statement...........................................88 + Disclaimer of Validity.............................................88 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 their behalf. Finally, nodes use the protocol to actively keep track @@ -165,56 +155,62 @@ be specified (in the appropriate document covering the operation of IP over a particular link type). The services described in this document that are not directly dependent on multicast, such as Redirects, Next-hop determination, Neighbor Unreachability Detection, 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-CELL] 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, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles - Perkins, Matt Thomas, and Susan Thomson. + The authors of RFC 2461 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, Stephen Deering, + Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, Robert + Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles Perkins, + Matt Thomas, and Susan Thomson. + + The editor of this document (Hesham Soliman) would like to thank the + ipv6 working group for the numerous contributions to this revision, + in particular, (in alphabetical order), Greg Daley, Elwyn Davies, + Ralph Droms, Brian Haberman, Bob Hinden, Tatuya Jinmei, Pekka Savola, + Fred Templin and Christian Vogt. 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 + ICMP - Internet Control Message Protocol for the Internet Protocol Version 6. The terms ICMPv4 and ICMPv6 are used only in contexts where necessary to avoid ambiguity. node - a device that implements IP. router - a node that forwards IP packets not explicitly addressed to itself. host - any node that is not a router. upper layer - a protocol layer immediately above IP. Examples are transport protocols such as TCP and UDP, control protocols such as ICMP, routing protocols such as OSPF, and internet or lower-layer protocols being "tunneled" over (i.e., encapsulated in) IP such as IPX, AppleTalk, or IP itself. link - a communication facility or medium over which nodes can - communicate at the link layer, i.e., the layer + communicate at the link-layer, i.e., the layer immediately below IP. Examples are Ethernets (simple or bridged), PPP links, X.25, Frame Relay, or ATM networks as well as internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. interface - a node's attachment to a link. neighbors - nodes attached to the same link. address - an IP-layer identifier for an interface or a set of @@ -241,21 +237,23 @@ bits of an address. link-layer address - a link-layer identifier for an interface. Examples include IEEE 802 addresses for Ethernet links. on-link - an address that is assigned to an interface on a specified link. A node considers an address to be on- link if: - - it is covered by one of the link's prefixes, or + - it is covered by one of the link's prefixes (e.g. + as indicated by the on-link flag in the Prefix + Information option), or - a neighboring router specifies the address as the target of a Redirect message, or - a Neighbor Advertisement message is received for the (target) address, or - any Neighbor Discovery message is received from the address. @@ -280,28 +278,28 @@ sent by a node's IP layer are delivered to the router's IP layer, and the router is indeed forwarding packets (i.e., it is configured as a router, not a host). For hosts, reachability means that packets sent by a node's IP layer are delivered to the neighbor host's IP layer. packet - an IP header plus payload. link MTU - the maximum transmission unit, i.e., maximum packet - size in octets, that can be conveyed in one piece - over a link. + size in octets, that can be conveyed in one + transmission unit over a link. target - an address about which address resolution information is sought, or an address which is the new first-hop when being redirected. - proxy - a router that responds to Neighbor Discovery query + proxy - a node that responds to Neighbor Discovery query messages on behalf of another node. A router acting on behalf of a mobile node that has moved off-link could potentially act as a proxy for the mobile node. ICMP destination unreachable indication - an error indication returned to the original sender of a packet that cannot be delivered for the reasons outlined in [ICMPv6]. If the error occurs on a node other than the node originating the packet, an ICMP @@ -331,38 +329,40 @@ insure that the granularity of the calculated random component and the resolution of the timer used are both high enough to insure that the probability of multiple nodes delaying the same amount of time is small. random delay seed - If a pseudo-random number generator is used in calculating a random delay component, the generator should be initialized with a unique seed prior to being used. Note that it is not sufficient to use the - interface token alone as the seed, since interface - tokens will not always be unique. To reduce the - probability that duplicate interface tokens cause the - same seed to be used, the seed should be calculated + interface identifier alone as the seed, since interface + identifiers will not always be unique. To reduce the + probability that duplicate interface identifiers cause + the same seed to be used, the seed should be calculated from a variety of input sources (e.g., machine components) that are likely to be different even on identical "boxes". For example, the seed could be formed by combining the CPU's serial number with an - interface token. + interface identifier. Additional information on + randomness and random number generation can be found in + [RAND]. 2.2. Link Types - Different link layers have different properties. The ones of concern + Different link-layers have different properties. The ones of concern to Neighbor Discovery are: multicast capable - a link that supports a native mechanism at the - link layer for sending packets to all (i.e., + link-layer for sending packets to all (i.e., 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.). @@ -382,21 +382,21 @@ 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- MEDIA]. variable MTU - a link that does not have a well-defined MTU (e.g., IEEE 802.5 token rings). Many links (e.g., Ethernet) have a standard MTU defined by the link- layer protocol or by the specific document - describing how to run IP over the link layer. + describing how to run IP over the link-layer. asymmetric reachability - a link where non-reflexive and/or non-transitive reachability is part of normal operation. (Non- reflexive reachability means packets from A reach B but packets from B don't reach A. Non-transitive reachability means packets from A reach B, and packets from B reach C, but packets from A don't reach C.) Many radio links exhibit these properties. @@ -415,43 +415,44 @@ 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 most significant bits, e.g., due to multiple prefixes associated with different providers, will map to the same solicited-node address thereby reducing the - number of multicast addresses a node must join. + number of multicast addresses a node must join at the + link-layer. 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. + 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 @@ -474,60 +475,63 @@ that define which destinations are on-link for an attached link. (Nodes use prefixes to distinguish destinations that reside on-link from those only reachable through a router.) Parameter Discovery: How a node learns such link parameters as the link MTU or such Internet parameters as the hop limit value to place in outgoing packets. Address Autoconfiguration: Introduces the mechanisms needed in - order to allow nodes to automatically configure an - address for an interface. + order to allow nodes to configure an address for an + interface in a stateless manner. Stateless address + autoconfiguration is specified in [ADDRCONF]. Address resolution: How nodes determine the link-layer address of an on-link destination (e.g., a neighbor) given only the destination's IP address. Next-hop determination: The algorithm for mapping an IP destination address into the IP address of the neighbor to which traffic for the destination should be sent. The next- hop can be a router or the destination itself. Neighbor Unreachability Detection: How nodes determine that a neighbor is no longer reachable. For neighbors used as routers, alternate default routers can be tried. For both routers and hosts, address resolution can be performed again. - Duplicate Address Detection: How a node determines that an address - it wishes to use is not already in use by another node. + Duplicate Address Detection: How a node determines whether or not + an address it wishes to use is already in use by + another node. Redirect: How a router informs a host of a better first-hop node to reach a particular destination. Neighbor Discovery defines five different ICMP packet types: A pair of Router Solicitation and Router Advertisement messages, a pair of Neighbor Solicitation and Neighbor Advertisements messages, and a Redirect message. The messages serve the following purpose: 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 on-link determination and/or address - configuration, a suggested hop limit value, etc. + are used for determining whether an 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 message. A node may also send unsolicited Neighbor Advertisements to announce a link-layer address change. @@ -615,36 +619,39 @@ interface. For example, a single network driver could represent multiple network interface cards as a single 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 who - issued the solicitation. This specification does not support - a mechanism that allows host to Load balance incoming - packets. + 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. 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. This invokes - specific rules to determine which of potentially multiple - advertisements should be used. + 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. - Proxy advertisements - A router willing to accept packets on behalf + 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 The IPv6 Neighbor Discovery protocol corresponds to a combination of @@ -692,22 +699,22 @@ Unlike IPv4, the recipient of an IPv6 redirect assumes that the new next-hop is on-link. In IPv4, a host ignores redirects specifying a next-hop that is not on-link according to the link's network mask. The IPv6 redirect mechanism is analogous to the XRedirect facility specified in [SH-MEDIA]. It is expected to be useful on non-broadcast and shared media links in which it is undesirable or not possible for nodes to know all prefixes for on-link destinations. - Neighbor Unreachability Detection is part of the base - significantly improving the robustness of packet delivery in the + Neighbor Unreachability Detection is part of the base, which + significantly improves the robustness of packet delivery in the presence of failing routers, partially failing or partitioned links and nodes that change their link-layer addresses. For instance, mobile nodes can move off-link without losing any connectivity due to stale ARP caches. Unlike ARP, Neighbor Discovery detects half-link failures (using Neighbor Unreachability Detection) and avoids sending traffic to neighbors with which two-way connectivity is absent. Unlike in IPv4 Router Discovery the Router Advertisement messages @@ -732,36 +739,33 @@ appropriate. 3.2. Supported Link Types 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.) Neighbor - Discovery should be implemented as described in - this document. + provided on point-to-point links, and interfaces + can be assigned link-local addresses.) - multicast - Neighbor Discovery should be implemented as - described in this document. + multicast - Neighbor Discovery supports 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 default routers, hosts can dynamically acquire the link-layer addresses for their neighbors from Redirect messages. shared media - The Redirect message is modeled after the XRedirect message in [SH-MEDIA] in order to simplify use of the protocol on shared media links. @@ -803,29 +807,32 @@ will refrain from using them. The protocol can presumably be extended in the future to find viable paths in environments that lack reflexive and transitive connectivity. 3.3. Securing Neighbor Discovery messages Neighbor Discovery messages are needed for various functions. Several functions are designed to allow hosts to ascertain the ownership of - an address or the mapping between link layer and IP layer addresses. + an address or the mapping between link-layer and IP layer addresses. Vulnerabilities related to Neighbor Discovery are discussed in section 11.1. A general solution for securing Neighbor Discovery is outside the scope of this specification and is discussed in [SEND]. However, Section 11.2 explains how and under which constraints IPsec AH or ESP can be used to secure Neighbor Discovery. 4. MESSAGE FORMATS + This section introduces message formats for all messages used in this + specification. + 4.1. Router Solicitation Message Format Hosts send Router Solicitations in order to prompt routers to generate Router Advertisements quickly. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -855,21 +862,21 @@ Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Valid Options: Source link-layer address The link-layer address of the sender, if known. MUST NOT be included if the Source Address is the unspecified address. Otherwise it SHOULD be - included on link layers that have addresses. + included on link-layers that have addresses. 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. 4.2. Router Advertisement Message Format Routers send out Router Advertisement message periodically, or in response to a Router Solicitation. @@ -961,40 +967,41 @@ Solicitation messages. Used by address resolution and the Neighbor Unreachability Detection algorithm (see Sections 7.2 and 7.3). A value of zero means unspecified (by this router). Possible options: Source link-layer address The link-layer address of the interface from which the Router Advertisement is sent. Only used on - link layers that have addresses. A router MAY omit + link-layers that have addresses. A router MAY omit this option in order to enable inbound load sharing across multiple link-layer addresses. MTU SHOULD be sent on links that have a variable MTU (as specified in the document that describes how to run IP over the particular link type). MAY be sent on other links. Prefix Information These options specify the prefixes that are on-link - and/or are used for address autoconfiguration. A - router SHOULD include all its on-link prefixes - (except the link-local prefix) so that multihomed - hosts have complete prefix information about on- - link destinations for the links to which they - attach. If complete information is lacking, a - multihomed host may not be able to choose the - correct outgoing interface when sending traffic to - its neighbors. + and/or are used for stateless address + autoconfiguration. A router SHOULD include all its + on-link prefixes (except the link-local prefix) so + that multihomed hosts have complete prefix + information about on-link destinations for the + links to which they attach. If complete + information is lacking, a host with multiple + interfaces may not be able to choose the correct + outgoing interface when sending traffic to its + neighbors. 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. 4.3. Neighbor Solicitation Message Format Nodes send Neighbor Solicitations to request the link-layer address of a target node while also providing their own link-layer address to the target. Neighbor Solicitations are multicast when the node needs @@ -1046,21 +1053,21 @@ Target Address The IP address of the target of the solicitation. It MUST NOT be a multicast address. Possible options: Source link-layer address The link-layer address for the sender. MUST NOT be included when the source IP address is the - unspecified address. Otherwise, on link layers + unspecified address. Otherwise, on link-layers that have addresses this option MUST be included in multicast solicitations and SHOULD be included in unicast solicitations. 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. 4.4. Neighbor Advertisement Message Format @@ -1145,21 +1151,21 @@ prompted this advertisement. For an unsolicited advertisement, the address whose link-layer address has changed. The Target Address MUST NOT be a multicast address. Possible options: Target link-layer address The link-layer address for the target, i.e., the sender of the advertisement. This option MUST be - included on link layers that have addresses when + included on link-layers that have addresses when responding to multicast solicitations. When 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 @@ -1318,21 +1324,21 @@ length fields) in units of 8 octets. For example, the length for IEEE 802 addresses is 1 [IPv6- ETHER]. Link-Layer Address The variable length link-layer address. The content and format of this field (including byte and bit ordering) is expected to be specified in specific documents that describe how IPv6 - operates over different link layers. For instance, + operates over different link-layers. For instance, [IPv6-ETHER]. Description The Source Link-Layer Address option contains the link-layer address of the sender of the packet. It is used in the Neighbor Solicitation, Router Solicitation, and Router Advertisement packets. The Target Link-Layer Address option contains the link-layer address of the target. It is used in @@ -1375,25 +1381,28 @@ necessary information for on-link determination (when combined with the L flag in the prefix 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 - to the prefix being on-link and others being off- - link. + 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. 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 @@ -1424,25 +1433,23 @@ leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver. A router SHOULD NOT send a prefix option for the link-local prefix and a host SHOULD ignore such a prefix option. Description The Prefix Information option provide hosts with on-link prefixes and prefixes for Address - Autoconfiguration. - - The Prefix Information option appears in Router - Advertisement packets and MUST be silently ignored - for other messages. + Autoconfiguration. The Prefix Information option + appears in Router Advertisement packets and MUST be + silently ignored for other messages. 4.6.3. Redirected Header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -1744,21 +1752,22 @@ caches that have become invalid. When removing an entry from the Default Router List, however, any entries in the Destination Cache that go through that router must perform next-hop determination again to select a new default router. 6. ROUTER AND PREFIX DISCOVERY This section describes router and host behavior related to the Router Discovery portion of Neighbor Discovery. Router Discovery is used to locate neighboring routers as well as learn prefixes and - configuration parameters related to address autoconfiguration. + configuration parameters related to stateless address + autoconfiguration. Prefix Discovery is the process through which hosts learn the ranges of IP addresses that reside on-link and can be reached directly without going through a router. Routers send Router Advertisements that indicate whether the sender is willing to be a default router. Router Advertisements also contain Prefix Information options that list the set of prefixes that identify on-link IP addresses. Stateless Address Autoconfiguration must also obtain subnet prefixes as part of configuring addresses. Although the prefixes used for @@ -1847,21 +1856,21 @@ A router MUST allow for the following conceptual variables to be configured by system management. The specific variable names are used for demonstration purposes only, and an implementation is not required to have them, so long as its external behavior is consistent with that described in this document. Default values are specified to simplify configuration in common cases. The default values for some of the variables listed below may be overridden by specific documents that describe how IPv6 operates over - different link layers. This rule simplifies the configuration of + different link-layers. This rule simplifies the configuration of Neighbor Discovery over link types with widely differing performance characteristics. For each interface: IsRouter A flag indicating whether routing is enabled on this interface. Enabling routing on the interface would imply that a router can forward packets to or from the interface. @@ -1885,23 +1893,26 @@ unsolicited multicast Router Advertisements from the interface, in seconds. MUST be no less than 4 seconds and no greater than 1800 seconds. Default: 600 seconds MinRtrAdvInterval The minimum time allowed between sending unsolicited multicast Router Advertisements from the interface, in seconds. MUST be no less than 3 - seconds and no greater than .75 *MaxRtrAdvInterval. + seconds and no greater than .75 * + MaxRtrAdvInterval. Default: 0.33 * MaxRtrAdvInterval + If MaxRtrAdvInterval >= 9 seconds, otherwise the + Default is MaxRtrAdvInterval. AdvManagedFlag The TRUE/FALSE value to be placed in the "Managed address configuration" flag field in the Router Advertisement. See [ADDRCONF]. Default: FALSE AdvOtherConfigFlag The TRUE/FALSE value to be placed in the "Other @@ -1928,21 +1939,21 @@ AdvRetransTimer The value to be placed in the Retrans Timer field in the Router Advertisement messages sent by the router. The value zero means unspecified (by this router). Default: 0 AdvCurHopLimit The default value to be placed in the Cur Hop Limit field in the Router Advertisement messages sent by - the router. The value should be set to that + the router. The value should be set to the current diameter of the Internet. The value zero means unspecified (by this router). Default: The value specified in the "Assigned Numbers" RFC [ASSIGNED] that was in effect at the time of implementation. AdvDefaultLifetime The value to be placed in the Router Lifetime field of Router Advertisements sent from the interface, @@ -1987,21 +1998,21 @@ (i.e., stays the same in consecutive advertisements). AdvOnLinkFlag The value to be placed in the on-link flag ("L-bit") field in the Prefix Information option. Default: TRUE - Automatic address configuration [ADDRCONF] + Stateless address configuration [ADDRCONF] defines additional information associated with each the prefixes: AdvPreferredLifetime The value to be placed in the Preferred Lifetime in the Prefix Information option, in seconds. The designated value of all 1's (0xffffffff) represents infinity. See [ADDRCONF] for details on how this value is used. Implementations @@ -2112,23 +2124,23 @@ AdvValidLifetime. - In the "Autonomous address configuration" flag: the entry's AdvAutonomousFlag. - In the Preferred Lifetime field: the entry's AdvPreferredLifetime. A router might want to send Router Advertisements without advertising itself as a default router. For instance, a router might advertise - prefixes for address autoconfiguration while not wishing to forward - packets. Such a router sets the Router Lifetime field in outgoing - advertisements to zero. + prefixes for stateless address autoconfiguration while not wishing to + forward packets. Such a router sets the Router Lifetime field in + outgoing advertisements to zero. A router MAY choose not to include some or all options when sending unsolicited Router Advertisements. For example, if prefix lifetimes are much longer than AdvDefaultLifetime, including them every few advertisements may be sufficient. However, when responding to a Router Solicitation or while sending the first few initial unsolicited advertisements, a router SHOULD include all options so that all information (e.g., prefixes) is propagated quickly during system initialization. @@ -2178,21 +2190,21 @@ - administratively disabling the interface, or - shutting down the system. In such cases the router SHOULD transmit one or more (but not more than MAX_FINAL_RTR_ADVERTISEMENTS) final multicast Router Advertisements on the interface with a Router Lifetime field of zero. In the case of a router becoming a host, the system SHOULD also depart from the all-routers IP multicast group on all interfaces on which the router supports IP multicast (whether or not they had been - advertising interfaces). In addition, the host MUST insure that + advertising interfaces). In addition, the host MUST ensure that subsequent Neighbor Advertisement messages sent from the interface have the Router flag set to zero. Note that system management may disable a router's IP forwarding capability (i.e., changing the system from being a router to being a host), a step that does not necessarily imply that the router's interfaces stop being advertising interfaces. In such cases, subsequent Router Advertisements MUST set the Router Lifetime field to zero. @@ -2351,24 +2363,24 @@ The default values in this specification may be overridden by specific documents that describe how IP operates over different link layers. This rule allows Neighbor Discovery to operate over links with widely varying performance characteristics. For each interface: LinkMTU The MTU of the link. Default: The valued defined in the specific document that describes how IPv6 operates over - the particular link layer (e.g., [IPv6-ETHER]). + the particular link-layer (e.g., [IPv6-ETHER]). CurHopLimit The default hop limit to be used when sending - (unicast) IP packets. + IP packets. Default: The value specified in the "Assigned Numbers" RFC [ASSIGNED] that was in effect at the time of implementation. BaseReachableTime A base value used for computing the random ReachableTime value. Default: REACHABLE_TIME milliseconds. @@ -2536,25 +2548,25 @@ 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 with other flags in the prefix option. Note: Implementations can choose to process the on-link aspects of - the prefixes separately from the address autoconfiguration aspects - of the prefixes by, e.g., passing a copy of each valid Router - Advertisement message to both an "on-link" and an "addrconf" - function. Each function can then operate independently on the - prefixes that have the appropriate flag set. + the prefixes separately from the stateless address + autoconfiguration aspects of the prefixes by, e.g., passing a copy + of each valid Router Advertisement message to both an "on-link" + and an "addrconf" function. Each function can then operate + independently on the prefixes that have the appropriate flag set. 6.3.5. Timing out Prefixes and Default Routers Whenever the invalidation timer expires for a Prefix List entry, that entry is discarded. No existing Destination Cache entries need be updated, however. Should a reachability problem arise with an existing Neighbor Cache entry, Neighbor Unreachability Detection will perform any needed recovery. Whenever the Lifetime of an entry in the Default Router List expires, @@ -2640,41 +2652,40 @@ a random delay since the interface became (re)enabled (e.g., as part of Duplicate Address Detection [ADDRCONF]) there is no need to delay again before sending the first Router Solicitation message. In some cases, the random delay MAY be omitted if necessary. For instance, a mobile node, using [MIPv6], moving to a new link would need to discover such movement as soon as possible to minimize the amount of packet losses resulting from the change in its topological movement. Router Solicitations provide a useful tool for movement detection in Mobile IPv6 as they allow mobile nodes to determine - movement to new links. Hence, if a mobile node received link layer + movement to new links. Hence, if a mobile node received link-layer information indicating that movement might have taken place, it MAY send a Router Solicitation immediately, without random delays. The strength of such indications should be assessed by the mobile node's - implementation depending on the level of certainty of the link layer + implementation depending on the level of certainty of the link-layer hints and is outside the scope of this specification. Note that using this mechanism inappropriately (e.g. based on weak or transient indications) may result in Router Solicitation storms. Furthermore, simultaneous mobility of a large number of mobile nodes that use this mechanism can result in a large number of solicitations sent simultaneously. Once the host sends a Router Solicitation, and receives a valid Router Advertisement with a non-zero Router Lifetime, the host MUST desist from sending additional solicitations on that interface, until the next time one of the above events occurs. Moreover, a host SHOULD send at least one solicitation in the case where an advertisement is received prior to having sent a solicitation. - Unsolicited Router Advertisements may be incomplete (see Section - 6.2.3); solicited advertisements are expected to contain complete - information. + Responses to solicited advertisements are expected to contain + complete information. If a host sends MAX_RTR_SOLICITATIONS solicitations, and receives no Router Advertisements after having waited MAX_RTR_SOLICITATION_DELAY seconds after sending the last solicitation, the host concludes that there are no routers on the link for the purpose of [ADDRCONF]. However, the host continues to receive and process Router Advertisements messages in the event that routers appear on the link. 7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION @@ -2772,39 +2783,39 @@ 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, a router advertisement, or a Redirect message 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 + before unicast communications with that address can 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 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] or - [MLDv2] protocols. Note that multiple unicast addresses may map into - the same solicited-node multicast address; a node MUST NOT leave the + is done using a Multicast Listener Discovery such as [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 @@ -2863,21 +2874,21 @@ - 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]. If the Target Address is tentative, the Neighbor Solicitation should be processed as described in [ADDRCONF]. Otherwise, the following description applies. If the Source Address is not the unspecified - address and, on link layers that have addresses, the solicitation + address and, on link-layers that have addresses, the solicitation includes a Source Link-Layer Address option, then the recipient SHOULD create or update the Neighbor Cache entry for the IP Source Address of the solicitation. If an entry does not already exist, the node SHOULD create a new one and set its reachability state to STALE as specified in Section 7.3.3. If an entry already exists, and the cached link-layer address differs from the one in the received Source Link-Layer option, the cached address should be replaced by the received address and the entry's reachability state MUST be set to STALE. @@ -2946,21 +2957,21 @@ 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. If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happens. If the - link layer has addresses and no Target Link-Layer address option is + 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 @@ -2983,40 +2994,40 @@ 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 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 differs + from 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. 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 + Receipt of an unsolicited advertisement, however, may indicate + 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 @@ -3058,21 +3069,21 @@ A node that has multiple IP addresses assigned to an interface MAY multicast a separate Neighbor Advertisement for each address. In such a case the node SHOULD introduce a small delay between the sending of each advertisement to reduce the probability of the advertisements being lost due to congestion. A proxy MAY multicast Neighbor Advertisements when its link-layer address changes or when it is configured (by system management or other mechanisms) to proxy for an address. If there are multiple nodes that are providing proxy services for the same set of addresses - the proxies SHOULD provide a mechanism that prevents multiple proxies + the proxies should provide a mechanism that prevents multiple proxies from multicasting advertisements for any one address, in order to reduce the risk of excessive multicast traffic. This is a requirement on other protocols that need to use proxies for Neighbor Advertisements. An example of a node that performs proxy advertisements is the Home Agent specified in [MIPv6]. Also, a node belonging to an anycast address MAY multicast unsolicited Neighbor Advertisements for the anycast address when the node's link-layer address changes. @@ -3106,39 +3117,43 @@ As with unicast addresses, Neighbor Unreachability Detection ensures that a node quickly detects when the current binding for an anycast address becomes invalid. 7.2.8. Proxy Neighbor Advertisements 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. + that has moved off-link. The mechanisms used by proxy are + essentially the same as 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] or [MLDv2]. + proxying. This SHOULD be done using a multicast listener discovery + protocol such as [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. Finally, when sending a proxy advertisement in response to a Neighbor Solicitation, the sender should delay its response by a random time - between 0 and MAX_ANYCAST_DELAY_TIME seconds. + between 0 and MAX_ANYCAST_DELAY_TIME seconds to avoid collisions due + to multiple responses sent by several proxies. However, in some cases + (e.g. Mobile IPv6) where only one proxy is present, such delay is not + necessary. 7.3. Neighbor Unreachability Detection Communication to or through a neighbor may fail for numerous reasons at any time, including hardware failure, hot-swap of an interface card, etc. If the destination has failed, no recovery is possible and communication fails. On the other hand, if it is the path that has failed, recovery may be possible. Thus, a node actively tracks the reachability "state" for the neighbors to which it is sending packets. @@ -3193,31 +3208,31 @@ 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 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 - perspective of Neighbor Unreachability Detection, only the - reachability of the forward path is of interest. + forward path to a neighbor from 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 perspective of Neighbor + Unreachability Detection, only the reachability of the forward path + is of interest. 7.3.2. Neighbor Cache Entry States A Neighbor Cache entry can be in one of five states: INCOMPLETE Address resolution is being performed on the entry. Specifically, a Neighbor Solicitation has been sent to the solicited-node multicast address of the target, but the corresponding Neighbor Advertisement has not yet been received. @@ -3441,21 +3456,21 @@ 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 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 + 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. - 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 @@ -3631,21 +3645,22 @@ MAX_RANDOM_FACTOR 1.5 Additional protocol constants are defined with the message formats in Section 4. All protocol constants are subject to change in future revisions of the protocol. The constants in this specification may be overridden by specific - documents that describe how IPv6 operates over different link layers. + documents that describe how IPv6 operates over different link-layers. + This rule allows Neighbor Discovery to operate over links with widely varying performance characteristics. 11. SECURITY CONSIDERATIONS Neighbor Discovery is subject to attacks that cause IP packets to flow to unexpected places. Such attacks can be used to cause denial of service but also allow nodes to intercept and optionally modify packets destined for other nodes. This section deals with the main threats related to Neighbor Discovery messages and possible security @@ -3679,23 +3694,23 @@ 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 + 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 + 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. 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 @@ -3703,21 +3718,21 @@ 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 + Many link-layers are also subject to different denial of service attacks such as continuously occupying the link in CSMA/CD networks (e.g., by sending packets closely back-to-back or asserting the collision signal on the link), or originating packets with somebody else's source MAC address to confuse, e.g., Ethernet switches. On the other hand, many of the threats discussed in this section are less effective, or non-existent, on point-to-point links, or cellular links where a host shares a link with only one neighbor, i.e. the default router. 11.2 Securing Neighbor Discovery messages @@ -3808,30 +3822,87 @@ sending Router Advertisements that contain appropriate (and current) prefixes. A host connected to a network that has no functioning routers is likely to have more serious problems than just a lack of a valid prefix and address. The above discussion does not distinguish between the preferred and valid lifetimes. For all practical purposes it is probably sufficient to track the valid lifetime since the preferred lifetime will not exceed the valid lifetime. +IANA CONSIDERATIONS + + This document does not require any new ICMPv6 types or codes to be + allocated. However, existing ICMPv6 types should be updated to point + to the document instead of RFC 2461. The procedure for the assignment + of ICMPv6 types/codes is described in Section 6 of [ICMPv6]. + + This document continues to use the following ICMPv6 message types + introduced in RFC 2461 and already assigned by IANA: + + Message name ICMPv6 Type + + Router Solicitation 133 + Router Advertisement 134 + Neighbor Solicitation 135 + Neighbor Advertisement 136 + Redirect 137 + + This document continues to use the following Neighbor Discovery + option types introduced in RFC 2461 and already assigned by IANA: + + Option Name Type + + Source Link-Layer Address 1 + Target Link-Layer Address 2 + Prefix Information 3 + Redirected Header 4 + MTU 5 + Neighbor Discovery option types are allocated using following + procedure: + + 1. The IANA should allocate and permanently register new option types + from IETF RFC publication. This is for all RFC types + including standards track, informational, and experimental status + that originate from the IETF and have been approved by the IESG + for publication. + + 2. IETF working groups with working group consensus and area director + approval can request reclaimable Neighbor Discovery option type + assignments from the IANA. The IANA will tag the values as + "reclaimable in future". + + The "reclaimable in the future" tag will be removed when an RFC is + published documenting the protocol as defined in 1). This will + make the assignment permanent and update the reference on the IANA + web pages. + + At the point where the option type values are 85% assigned, the + IETF will review the assignments tagged "reclaimable in the + future" and inform the IANA which ones should be reclaimed and + reassigned. + + 3. Requests for new option type value assignments from outside the + IETF are only made through the publication of an IETF document, + per 1) above. Note also that documents published as "RFC Editor + contributions" [RFC3667] are not considered to be IETF documents. + REFERENCES NORMATIVE [ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 3513, April 2003. + Architecture", RFC 4291, February 2006. [ICMPv6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 - (IPv6) Specification", RFC 2463, December 1998. + (IPv6) Specification", RFC 4443, March 2006. [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 @@ -3874,34 +3945,41 @@ [IPv6-SA] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [IPv6-AUTH] S. Kent, "IP Authentication Header", RFC 4302, December 2005. [IPv6-ESP] S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. + [IPv6-NBMA] Armitage, G., Schulter, P., Jork, M and G. Harter "IPv6 + over Non-Broadcast Multiple Access (NBMA) networks", RFC + 2491, January 1999. + [LD-SHRE] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load Sharing", RFC 4311, November 2005. [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. [PSREQ] Nikander, P., Kempf, J. And E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust and Threats", RFC 3756, May 2004. + rd [RAND] Eastlake, 3 , D., Schiller, J and S. Crocker, + "Randomness Requirements for Security", RFC 4086, June + 2005. [RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991. [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, February 2004. [RTSEL] Draves, R. and D. Thaler, "Default Router Preferences and more Specific Routes", draft-ietf-ipv6-router- selection-07, (work in progress), January 2005. @@ -3911,89 +3989,30 @@ 1994. [SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)",RFC3971, March 2005. [SYNC] S. Floyd, V. Jacobson, "The Synchronization of Periodic Routing Messages", IEEE/ACM Transactions on Networking, April 1994. ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z -IANA CONSIDERATIONS - - This document does not require any new ICMPv6 types or codes to be - allocated. However, existing ICMPv6 types should be updated to point - to the document instead of RFC 2461. The procedure for the assignment - of ICMPv6 types/codes is described in Section 6 of [ICMPv6]. - - This document continues to use the following ICMPv6 message types - introduced in RFC 2461 and already assigned by IANA: - - Message name ICMPv6 Type - - Router Solicitation 133 - Router Advertisement 134 - Neighbor Solicitation 135 - Neighbor Advertisement 136 - Redirect 137 - - This document continues to use the following Neighbor Discovery - option types introduced in RFC 2461 and already assigned by IANA: - - Option Name Type - - Source Link-Layer Address 1 - Target Link-Layer Address 2 - Prefix Information 3 - Redirected Header 4 - MTU 5 - - Neighbor Discovery option types are allocated using following - procedure: - - 1. The IANA should allocate and permanently register new option types - from IETF RFC publication. This is for all RFC types - including standards track, informational, and experimental status - that originate from the IETF and have been approved by the IESG - for publication. - - 2. IETF working groups with working group consensus and area director - approval can request reclaimable Neighbor Discovery option type - assignments from the IANA. The IANA will tag the values as - "reclaimable in future". - - The "reclaimable in the future" tag will be removed when an RFC is - published documenting the protocol as defined in 1). This will - make the assignment permanent and update the reference on the IANA - web pages. - - At the point where the option type values are 85% assigned, the - IETF will review the assignments tagged "reclaimable in the - future" and inform the IANA which ones should be reclaimed and - reassigned. - - 3. Requests for new option type value assignments from outside the - IETF are only made through the publication of an IETF document, - per 1) above. Note also that documents published as "RFC Editor - contributions" [RFC3667] are not considered to be IETF documents. - Authors' Addresses Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 USA Phone: +1 919 254 7798 - EMail: narten@raleigh.ibm.com - + EMail: narten@us.ibm.com Erik Nordmark Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303 USA Phone: +1 650 786 5166 Fax: +1 650 786 5896 EMail: nordmark@sun.com @@ -4001,22 +4020,22 @@ Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 USA EMail: Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com Hesham Soliman - Qualcomm-Flarion Technologies - Email: Hesham@Qualcomm.com + Elevate Technologies + Email: hesham@elevatemobile.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. Further work @@ -4034,21 +4053,22 @@ standard test for this case is to compare the source address of the packet to the list of on-link prefixes associated with the interface on which the packet was received. If the originating host is multihomed, however, the source address it uses may belong to an interface other than the interface from which it was sent. In such cases, a router will not send redirects, and suboptimal routing is likely. In order to be redirected, the sending host must always send packets out the interface corresponding to the outgoing packet's source address. Note that this issue never arises with non-multihomed hosts; they - only have one interface. + only have one interface. Additional discussion on this topic can + be found in RFC1122 under section 3.3.4.2. 2) If the selected first-hop router does not have a route at all for the destination, it will be unable to deliver the packet. However, the destination may be reachable through a router on one of the other interfaces. Neighbor Discovery does not address this scenario; it does not arise in the non-multihomed case. 3) Even if the first-hop router does have a route for a destination, there may be a better route via another interface. @@ -4124,30 +4144,29 @@ INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE Override=any address. Send queued packets. INCOMPLETE NA, Solicited=any, Update content of unchanged Override=any, No IsRouter flag Link-layer address - NS, RS, Redirect - - - No link layer address + No link-layer address !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 @@ -4218,23 +4237,20 @@ 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, either implicitly or explicitly, information that indicates whether or not the sender (or Target Address) is a host or a router. The following assumptions are used: - - The sender of a Router Solicitation is implicitly assumed to be a - host since there is no need for routers to send such messages. - - The sender of a Router Advertisement is implicitly assumed to be a router. - Neighbor Solicitation messages do not contain either an implicit or explicit indication about the sender. Both hosts and routers send such messages. - Neighbor Advertisement messages contain an explicit "IsRouter flag", the R-bit. @@ -4244,21 +4260,21 @@ node is expected to be able to forward the packets towards the destination. - The target of the redirect, when the target is the same as the destination, does not carry any host vs. router information. All that is known is that the destination (i.e. target) is on-link but it could be either a host or a router. The rules for setting the IsRouter flag are based on the information content above. If an ND message contains explicit or implicit - information the receipt of the message will cause the IsRouter flag + information, the receipt of the message will cause the IsRouter flag to be updated. But when there is no host vs. router information in the ND message the receipt of the message MUST NOT cause a change to the IsRouter state. When the receipt of such a message causes a Neighbor Cache entry to be created this document specifies that the IsRouter flag be set to FALSE. There is greater potential for mischief when a node incorrectly thinks a host is a router, than the other way around. In these cases a subsequent Neighbor Advertisement or Router Advertisement message will set the correct IsRouter value. APPENDIX E: IMPLEMENTATION ISSUES @@ -4293,48 +4309,48 @@ To minimize the cost of communicating reachability information between the TCP and IP layers, an implementation may wish to rate- limit the reachability confirmations its sends IP. One possibility is to process reachability only every few packets. For example, one might update reachability information once per round trip time, if an implementation only has one round trip timer per connection. For those implementations that cache Destination Cache entries within control blocks, it may be possible to update the Neighbor Cache entry 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 + implementations 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. It 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 request indicates that a previous response reached the client. - Note that an implementation can not use negative upper-layer advise + Note that an implementation can not use negative upper-layer advice as a replacement for the Neighbor Unreachability Detection algorithm. - Negative advise (e.g. from TCP when there are excessive + Negative advice (e.g., from TCP when there are excessive retransmissions) could serve as a hint that the forward path from the sender of the data might not be working. But it would fail to detect - when the path from the receiver of the data is not functioning - causing, none of the acknowledgement packets to reach the sender. + when the path from the receiver of the data is not functioning, + causing none of the acknowledgement packets to reach the sender. APPENDIX F: CHANGES FROM RFC 2461 o Removed references to IPsec AH and ESP for securing messages or as part of validating the received message. o Added section 3.3. o Updated section 11 to include more detailed discussion on threats, IPsec limitations, and use of SeND. @@ -4361,21 +4377,21 @@ o Updated the applicability to NBMA links in the introduction and added references to 3GPP RFCs. o Clarified support for Load balancing is limited to routers. 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. + non-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 Added New IANA section. o Miscellaneous editorials. @@ -4399,25 +4415,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 (2006). This document is subject + Copyright (C) The Internet Society (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 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. -This Internet-Draft expires April, 2007. +This Internet-Draft expires June, 2007.