--- 1/draft-ietf-ipv6-2461bis-00.txt 2006-02-05 00:01:54.000000000 +0100 +++ 2/draft-ietf-ipv6-2461bis-01.txt 2006-02-05 00:01:54.000000000 +0100 @@ -1,23 +1,23 @@ INTERNET-DRAFT T. Narten, -Expires: January 2005 IBM +Expires: April 2005 IBM E. Nordmark, Sun Microsystems W. Simpson, Daydreamer H. Soliman, Flarion - July, 2004 + October, 2004 Neighbor Discovery for IP version 6 (IPv6) - + Status of this memo By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668 (BCP 79). By submitting this Internet-Draft, we accept the provisions of Section 4 of RFC 3667 (BCP 78). @@ -49,111 +49,111 @@ about the paths to active neighbors. Table of Contents 1. INTRODUCTION....................................................4 2. TERMINOLOGY.....................................................4 2.1. General...................................................4 2.2. Link Types................................................8 2.3. Addresses.................................................9 - 2.4. Requirements..............................................9 + 2.4. Requirements.............................................10 3. PROTOCOL OVERVIEW..............................................10 3.1. Comparison with IPv4.....................................13 3.2. Supported Link Types.....................................15 - 3.3. Securing Neighbor Discovery messages......................16 + 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....................21 + 4.4. Neighbor Advertisement Message Format....................22 4.5. Redirect Message Format..................................24 - 4.6. Option Formats...........................................25 + 4.6. Option Formats...........................................26 4.6.2. Prefix Information.................................27 4.6.3. Redirected Header..................................29 4.6.4. MTU................................................30 - 5. CONCEPTUAL MODEL OF A HOST.....................................30 + 5. CONCEPTUAL MODEL OF A HOST.....................................31 5.1. Conceptual Data Structures...............................31 5.2. Conceptual Sending Algorithm.............................33 5.3. Garbage Collection and Timeout Requirements..............34 6. ROUTER AND PREFIX DISCOVERY....................................35 - 6.1. Message Validation.......................................35 - 6.1.1. Validation of Router Solicitation Messages.........35 + 6.1. Message Validation.......................................36 + 6.1.1. Validation of Router Solicitation Messages.........36 6.1.2. Validation of Router Advertisement Messages........36 6.2. Router Specification.....................................37 6.2.1. Router Configuration Variables....................37 6.2.2. Becoming An Advertising Interface.................41 6.2.3. Router Advertisement Message Content..............41 6.2.4. Sending Unsolicited Router Advertisements.........43 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.......................................46 - 6.3.1. Host Configuration Variables......................46 - 6.3.2. Host Variables....................................46 + 6.3.1. Host Configuration Variables......................47 + 6.3.2. Host Variables....................................47 6.3.3. Interface Initialization..........................48 6.3.4. Processing Received Router Advertisements.........48 6.3.5. Timing out Prefixes and Default Routers...........51 6.3.6. Default Router Selection..........................51 6.3.7. Sending Router Solicitations......................52 7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION.......53 - 7.1. Message Validation.......................................53 - 7.1.1. Validation of Neighbor Solicitations..............53 + 7.1. Message Validation.......................................54 + 7.1.1. Validation of Neighbor Solicitations..............54 7.1.2. Validation of Neighbor Advertisements.............54 7.2. Address Resolution.......................................55 7.2.1. Interface Initialization..........................55 7.2.2. Sending Neighbor Solicitations....................55 7.2.3. Receipt of Neighbor Solicitations.................56 7.2.4. Sending Solicited Neighbor Advertisements.........57 7.2.5. Receipt of Neighbor Advertisements................58 7.2.6. Sending Unsolicited Neighbor Advertisements.......60 7.2.7. Anycast Neighbor Advertisements...................61 7.2.8. Proxy Neighbor Advertisements.....................61 7.3. Neighbor Unreachability Detection........................62 7.3.1. Reachability Confirmation.........................62 7.3.2. Neighbor Cache Entry States.......................63 7.3.3. Node Behavior.....................................64 8. REDIRECT FUNCTION..............................................66 - 8.1. Validation of Redirect Messages..........................66 - 8.2. Router Specification.....................................67 - 8.3. Host Specification.......................................68 + 8.1. Validation of Redirect Messages..........................67 + 8.2. Router Specification.....................................68 + 8.3. Host Specification.......................................69 9. EXTENSIBILITY - OPTION PROCESSING..............................69 10. PROTOCOL CONSTANTS............................................71 11. SECURITY CONSIDERATIONS.......................................72 11.1 Threat analysis...........................................72 11.2 Securing Neighbor Discovery messages......................73 12. RENUMBERING CONSIDERATIONS....................................74 REFERENCES.........................................................75 Authors' Addresses.................................................77 - APPENDIX A: MULTIHOMED HOSTS.......................................77 + APPENDIX A: MULTIHOMED HOSTS.......................................78 APPENDIX B: FUTURE EXTENSIONS......................................79 - APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............79 - APPENDIX D: SUMMARY OF ISROUTER RULES..............................81 - APPENDIX E: IMPLEMENTATION ISSUES..................................82 - Appendix E.1: Reachability confirmations...........................82 + APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............80 + APPENDIX D: SUMMARY OF ISROUTER RULES..............................82 + APPENDIX E: IMPLEMENTATION ISSUES..................................83 + Appendix E.1: Reachability confirmations...........................83 APPENDIX F: CHANGES FROM RFC 2461..................................84 - Full Copyright Statement...........................................84 + Full Copyright Statement.................Error! Bookmark not defined. 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 @@ -171,24 +171,24 @@ 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-CELLULAR] discuss the use of this protocol over some cellular links, which are examples of NBMA links. The authors would like to acknowledge the contributions of the IPv6 working group and, in particular, (in alphabetical order) Ran - Atkinson, Jim Bound, Scott Bradner, Alex Conta, Stephen Deering - Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, Robert - Hinden, Allison Mankin, Dan McDonald, Charles Perkins, Matt Thomas, - and Susan Thomson. + Atkinson, Jim Bound, Scott Bradner, Alex Conta, Elwyn Davies, Stephen + Deering Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, + Robert Hinden, Allison Mankin, Dan McDonald, Charles Perkins, Matt + Thomas, and Susan Thomson. 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 @@ -329,42 +329,44 @@ exactly the same time, or to prevent long-range periodic transmissions from synchronizing with each other [SYNC]. When a random component is required, a node calculates the actual delay in such a way that the computed delay forms a uniformly-distributed random value that falls between the specified minimum and maximum delay times. The implementor must take care to 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 + 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 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. 2.2. Link Types Different link layers have different properties. The ones of concern to Neighbor Discovery are: - multicast - a link that supports a native mechanism at the + multicast capable + - a link that supports a native mechanism at the 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 @@ -436,20 +438,26 @@ unspecified address - a reserved address value that indicates the lack of an address (e.g., the address is unknown). It is never used as a destination address, but may be used as a source address if the sender does not (yet) know its own address (e.g., while verifying an address is unused during address autoconfiguration [ADDRCONF]). The unspecified address has a value of 0:0:0:0:0:0:0:0. + Note that this specification does not strictly comply with the + consistency requirements for the scopes of source and destination + addresses. It is possible in some cases for hosts to use a source + address of a larger scope than the destination address in the IPv6 + header. + 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 specific variable names, how their values change, and how their @@ -470,21 +478,22 @@ Prefix Discovery: How hosts discover the set of address prefixes 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: How nodes automatically configure an + Address Autoconfiguration: Introduces the mechanisms needed in + order to allow nodes to automatically configure an address for an interface. 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. @@ -629,21 +638,21 @@ 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. Proxy advertisements - A router 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. + 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 the IPv4 protocols ARP [ARP], ICMP Router Discovery [RDISC], and ICMP Redirect [ICMPv4]. In IPv4 there is no generally agreed upon protocol or mechanism for Neighbor Unreachability Detection, although Hosts Requirements [HR-CL] does specify some possible algorithms for @@ -709,24 +718,24 @@ do not contain a preference field. The preference field is not needed to handle routers of different "stability"; the Neighbor Unreachability Detection will detect dead routers and switch to a working one. The use of link-local addresses to uniquely identify routers (for Router Advertisement and Redirect messages) makes it possible for hosts to maintain the router associations in the event of the site renumbering to use new global prefixes. - Using the Hop Limit equal to 255 trick Neighbor Discovery is - immune to off-link senders that accidentally or intentionally send - ND messages. In IPv4 off-link senders can send both ICMP - Redirects and Router Advertisement messages. + By setting the Hop Limit to 255, Neighbor Discovery is immune to + off-link senders that accidentally or intentionally send ND + messages. In IPv4 off-link senders can send both ICMP Redirects + and Router Advertisement messages. Placing address resolution at the ICMP layer makes the protocol more media-independent than ARP and makes it possible to use standard IP authentication and security mechanisms as 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: @@ -912,21 +919,21 @@ M 1-bit "Managed address configuration" flag. When set, it indicates that Dynamic Host Configuration Protocol [DHCPv6] is available for address configuration in addition to any addresses autoconfigured using stateless address autoconfiguration. The use of this flag is further described in [ADDRCONF]. O 1-bit "Other stateful configuration" flag. When - set, it indicates that [DHCPv6-lite] is available + set, it indicates that [DHCPv6lite] is available for autoconfiguration of other (non-address) information. Examples of such information are DNS- related information or information on other servers within the network. The use of this flag for add is further described in [ADDRCONF]. Reserved A 6-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. @@ -1257,22 +1264,23 @@ included in Redirect messages. Redirected Header As much as possible of the IP packet that triggered the sending of the Redirect without making the redirect packet exceed 1280 octets. 4.6. Option Formats Neighbor Discovery messages include zero or more options, some of - which may appear multiple times in the same message. All options are - of the form: + which may appear multiple times in the same message. Options should + be padded when necessary to ensure that they end on their natural 64- + bit boundaries. All options are of the form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: @@ -1845,21 +1852,21 @@ 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 Neighbor Discovery over link types with widely differing performance characteristics. - For each multicast interface: + 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. Default: FALSE AdvSendAdvertisements A flag indicating whether or not the router sends @@ -2031,21 +2039,21 @@ variables described above. However, external router behavior MUST be the same as host behavior with respect to these variables. In particular, this includes the occasional randomization of the ReachableTime value as described in Section 6.3.2. Protocol constants are defined in Section 10. 6.2.2. Becoming An Advertising Interface The term "advertising interface" refers to any functioning and - enabled multicast interface that has at least one unicast IP address + enabled interface that has at least one unicast IP address assigned to it and whose corresponding AdvSendAdvertisements flag is TRUE. A router MUST NOT send Router Advertisements out any interface that is not an advertising interface. An interface may become an advertising interface at times other than system startup. For example: - changing the AdvSendAdvertisements flag on an enabled interface from FALSE to TRUE, or @@ -2471,21 +2478,21 @@ IsRouter flag is used by Neighbor Unreachability Detection to determine when a router changes to being a host (i.e., no longer capable of forwarding packets). If a Neighbor Cache entry is created for the router its reachability state MUST be set to STALE as specified in Section 7.3.3. If a cache entry already exists and is updated with a different link-layer address the reachability state MUST also be set to STALE. If the MTU option is present, hosts SHOULD copy the option's value into LinkMTU so long as the value is greater than or equal to the - minimum link MTU [IPv6] and does not exceed the default LinkMTU value + minimum link MTU [IPv6] and does not exceed the maximum LinkMTU value specified in the link type specific document (e.g., [IPv6-ETHER]). Prefix Information options that have the "on-link" (L) flag set indicate a prefix identifying a range of addresses that should be considered on-link. Note, however, that a Prefix Information option with the on-link flag set to zero conveys no information concerning on-link determination and MUST NOT be interpreted to mean that addresses covered by the prefix are off-link. The only way to cancel a previous on-link indication is to advertise that prefix with the L-bit set and the Lifetime set to zero. The default behavior (see @@ -2587,23 +2594,20 @@ return the same router until all other routers have been selected. Cycling through the router list in this case ensures that all available routers are actively probed by the Neighbor Unreachability Detection algorithm. A request for a default router is made in conjunction with the sending of a packet to a router, and the selected router will be probed for reachability as a side effect. - 3) If the Default Router List is empty, assume that all - destinations are on-link as specified in Section 5.2. - 6.3.7. Sending Router Solicitations When an interface becomes enabled, a host may be unwilling to wait for the next unsolicited Router Advertisement to locate default routers or learn prefixes. To obtain Router Advertisements quickly, a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router Solicitation messages each separated by at least RTR_SOLICITATION_INTERVAL seconds. Router Solicitations may be sent after any of the following events: @@ -2638,21 +2642,21 @@ 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 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 + indications should be assessed by the mobile node's implementation and is outside the scope of this specification. 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 @@ -2752,41 +2756,42 @@ A Neighbor Advertisements that passes the validity checks is called a "valid advertisement". 7.2. Address Resolution Address resolution is the process through which a node determines the link-layer address of a neighbor given only its IP address. Address resolution is performed only on addresses that are determined to be on-link and for which the sender does not know the corresponding - link-layer address. Address resolution is never performed on - multicast addresses. + link-layer address (see section 5.2). Address resolution is never + performed on multicast addresses. 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. 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. + addresses, respectively. Joining the solicited-node multicast address + SHOULD be done using the Multicast Listener Discovery [MLD] protocol. + Note that multiple unicast addresses may map into the same solicited- + node multicast address; a node MUST NOT leave the solicited-node + multicast group until all assigned addresses corresponding to that + multicast address have been removed. 7.2.2. Sending Neighbor Solicitations - When a node has a unicast packet to send to a neighbor, but does not know the neighbor's link-layer address, it performs address resolution. For multicast-capable interfaces this entails creating a Neighbor Cache entry in the INCOMPLETE state and transmitting a Neighbor Solicitation message targeted at the neighbor. The solicitation is sent to the solicited-node multicast address corresponding to the target address. If the source address of the packet prompting the solicitation is the same as one of the addresses assigned to the outgoing interface, that @@ -2920,25 +2925,28 @@ If no entry exists, the advertisement SHOULD be silently discarded. There is no need to create an entry if none exists, since the recipient has apparently not initiated any communication with the target. Once the appropriate Neighbor Cache entry has been located, the specific actions taken depend on the state of the Neighbor Cache entry, the flags in the advertisement and the actual link-layer address supplied. + In any state, if the link layer has addresses and an unsolicited + Neighbor Advertisement is received with the O flag cleared, with no + Target Link-Layer address option included, the receiving node SHOULD + silently discard the received advertisement. + If the target's Neighbor Cache entry is in the INCOMPLETE state when - the advertisement is received, one of two things happens. If the - link layer has addresses and no Target Link-Layer address option is - included, the receiving node SHOULD silently discard the received - advertisement. Otherwise, the receiving node performs the following + the advertisement is received, one of two things happens. + Otherwise, the receiving node performs the following steps: - It records the link-layer address in the Neighbor Cache entry. - If the advertisement's Solicited flag is set, the state of the entry is set to REACHABLE, otherwise it is set to STALE. - It sets the IsRouter flag in the cache entry based on the Router flag in the received advertisement. @@ -3077,21 +3085,21 @@ Under limited circumstances, a router MAY proxy for one or more other nodes, that is, through Neighbor Advertisements indicate that it is willing to accept packets not explicitly addressed to itself. For example, a router might accept packets on behalf of a mobile node that has moved off-link. The mechanisms used by proxy are identical to the mechanisms used with anycast addresses. A proxy MUST join the solicited-node multicast address(es) that correspond to the IP address(es) assigned to the node for which it is - proxying. + proxying. This SHOULD be done using [MLD]. 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. @@ -3349,23 +3357,20 @@ not satisfy all of the following validity checks: - IP Source Address is a link-local address. Routers must use their link-local address as the source for Router Advertisement and Redirect messages so that hosts can uniquely identify routers. - The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router. - - If the message includes an IP Authentication Header, the message - authenticates correctly. - - ICMP Checksum is valid. - ICMP Code is 0. - ICMP length (derived from the IP length) is 40 or more octets. - The IP source address of the Redirect is the same as the current first-hop router for the specified ICMP Destination Address. - The ICMP Destination Address field in the redirect message does @@ -3640,33 +3643,34 @@ Preferred and Valid lifetimes set to zero for all the prefixes. Such an attack would cause all packets, for both on-link and off-link destinations, to go to the rogue router. That router can then selectively examine, modify or drop all packets sent on the link. The Neighbor Unreachability Detection will not detect such a black hole as long as the rogue router politely answers the NUD probes with a Neighbor Advertisement with the R-bit set. 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 - layer address to overwrite an existing entry in the senderÆs + 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. + victim's traffic to itself. The trust model for redirects is the same as in IPv4. A redirect is accepted only if received from the same router that is currently being used for that destination. It is natural to trust the routers on the link. If a host has been redirected to another node (i.e., the destination is on-link) there is no way to prevent the target from issuing another redirect to some other destination. However, this exposure is no worse than it was; the target host, once subverted, could always act as a hidden router to forward traffic elsewhere. @@ -3777,53 +3781,62 @@ 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. REFERENCES - [ADDRCONF] Thomson, S. Narten, T, and T. Jinmei, "IPv6 Address - Autoconfiguration", draft-ietf-ipv6-rfc2462bis-02, June - 2004. +NORMATIVE [ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. + [ICMPv6] Conta, A. and S. Deering, "Internet Control Message + Protocol (ICMPv6) for the Internet Protocol Version 6 + (IPv6) Specification", RFC 2463, December 1998. + + [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [MLD] Deering, S., Fenner, W, and B. Haberman, "Multicast + Listener Discovery for IPv6", RFC 2710, October 1999. + +INFORMATIVE + + [ADDRCONF] Thomson, S. Narten, T, and T. Jinmei, "IPv6 Address + Autoconfiguration", draft-ietf-ipv6-rfc2462bis-02, June + 2004. [ANYCST] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. [ARP] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37, RFC 826, November 1982. [DHCPv6] Droms, R., Ed, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. + [DHCPv6lite] Droms, R., "Stateless Dynamic Host Configuration + Protocol (DHCP)for IPv6", RFC 3736, April 2004. + [HR-CL] Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989. [ICMPIKE] Arkko, J., "Effects of ICMPv6 on IKE", draft-arkko-icmpv6-ike-effects-02 (work in progress), March 2003. [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. - [ICMPv6] Conta, A. and S. Deering, "Internet Control Message - Protocol (ICMPv6) for the Internet Protocol Version 6 - (IPv6) Specification", RFC 2463, December 1998. - - [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", RFC 2460, December 1998. - [IPv6-3GPP] Wasserman, M., Ed, "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) standards", RFC 3314, September 2002. [IPv6-CELL] Arkko, J., Kuipers, G., Soliman, H., Loughney, J. and J. Wiljakka, " Internet Protocol version 6 (IPv6) for Some Second and Third Generation Cellular Hosts", RFC 3316, April 2003. [IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over @@ -3899,21 +3911,22 @@ Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 USA EMail: Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com Hesham Soliman Flarion Technologies - H.Soliman@flarion.com + Phone: +1 908 997 9775 + Email: H.Soliman@flarion.com APPENDIX A: MULTIHOMED HOSTS There are a number of complicating issues that arise when Neighbor Discovery is used by hosts that have multiple interfaces. This section does not attempt to define the proper operation of multihomed hosts with regard to Neighbor Discovery. Rather, it identifies issues that require further study. Implementors are encouraged to experiment with various approaches to making Neighbor Discovery work on multihomed hosts and to report their experiences. @@ -4013,22 +4026,22 @@ Detection the following state transitions apply using the conceptual model: State Event Action New state - Packet to send. Create entry. INCOMPLETE Send multicast NS. Start retransmit timer INCOMPLETE Retransmit timeout, Retransmit NS INCOMPLETE - less than N Start retransmit timer - retransmissions. + less than N Start retransmit + retransmissions. timer INCOMPLETE Retransmit timeout, Discard entry - N or more Send ICMP error retransmissions. INCOMPLETE NA, Solicited=0, Record link-layer STALE Override=any address. Send queued packets. INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE @@ -4038,22 +4051,22 @@ !INCOMPLETE NA, Solicited=1, - REACHABLE Override=0 Same link-layer address as cached. REACHABLE NA, Solicited=1, - STALE Override=0 Different link-layer address than cached. - STALE or PROBE NA, Solicited=1, - unchanged - Override=0 + STALE, PROBE NA, Solicited=1, - unchanged + Or DELAY Override=0 Different link-layer address than cached. !INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE Override=1 address (if different). !INCOMPLETE NA, Solicited=0, - unchanged Override=0 @@ -4249,37 +4263,51 @@ o Allowed mobile nodes to be exempt from adding random delays before sending an RS during a handover. o Updated the definition of the prefix length in the prefix option o Updated the applicability to NBMA links in the introduction and added references to 3GPP RFCs. o Miscellaneous editorials. -Full Copyright Statement +Intellectual Property Statement - Copyright (C) The Internet Society (1998). All Rights Reserved. + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. + 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. - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. +Copyright Statement + + Copyright (C) The Internet Society (2004). 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, 2005.