--- 1/draft-ietf-ipv6-rfc2462bis-06.txt 2006-02-05 00:03:48.000000000 +0100 +++ 2/draft-ietf-ipv6-rfc2462bis-07.txt 2006-02-05 00:03:48.000000000 +0100 @@ -1,163 +1,128 @@ IETF IPv6 Working Group S. Thomson Internet-Draft Cisco -Expires: March 4, 2005 T. Narten +Expires: June 10, 2005 T. Narten IBM T. Jinmei Toshiba - September 3, 2004 + December 10, 2004 IPv6 Stateless Address Autoconfiguration - draft-ietf-ipv6-rfc2462bis-06.txt + draft-ietf-ipv6-rfc2462bis-07.txt 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 RFC 3668. + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with + RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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. - This Internet-Draft will expire on March 4, 2005. + This Internet-Draft will expire on June 10, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration - process includes creating a link-local address and verifying its - uniqueness on a link, determining what information can be - autoconfigured (addresses, other information, or both), and in the - case of addresses, whether they can be obtained through the stateless - mechanism, the stateful mechanism, or both. This document defines - the process for generating a link-local address, the process for - generating global addresses via stateless address autoconfiguration, - and the Duplicate Address Detection procedure. The details of - autoconfiguration using the stateful protocol are specified in RFC - 3315; an alternative way of using the stateful protocol to deliver - 'other information' only is specified in RFC 3736. + process includes generating a link-local address, generating global + addresses via stateless address autoconfiguration, and the Duplicate + Address Detection procedure to verify the uniqueness of the addresses + on a link. Table of Contents 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. TERMINOLOGY . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. TERMINOLOGY . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 3. DESIGN GOALS . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. PROTOCOL OVERVIEW . . . . . . . . . . . . . . . . . . . . . . 8 - 4.1 Site Renumbering . . . . . . . . . . . . . . . . . . . . . 11 - 5. PROTOCOL SPECIFICATION . . . . . . . . . . . . . . . . . . . . 11 - 5.1 Node Configuration Variables . . . . . . . . . . . . . . . 12 - 5.2 Autoconfiguration-Related Structures . . . . . . . . . . . 12 - 5.3 Creation of Link-Local Addresses . . . . . . . . . . . . . 12 - 5.4 Duplicate Address Detection . . . . . . . . . . . . . . . 13 - 5.4.1 Message Validation . . . . . . . . . . . . . . . . . . 15 - 5.4.2 Sending Neighbor Solicitation Messages . . . . . . . . 15 - 5.4.3 Receiving Neighbor Solicitation Messages . . . . . . . 16 - 5.4.4 Receiving Neighbor Advertisement Messages . . . . . . 17 - 5.4.5 When Duplicate Address Detection Fails . . . . . . . . 17 - 5.5 Creation of Global Addresses . . . . . . . . . . . . . . . 18 - 5.5.1 Soliciting Router Advertisements . . . . . . . . . . . 18 - 5.5.2 Absence of Router Advertisements . . . . . . . . . . . 18 - 5.5.3 Router Advertisement Processing . . . . . . . . . . . 19 - 5.5.4 Address Lifetime Expiry . . . . . . . . . . . . . . . 21 - 5.6 Configuration Consistency . . . . . . . . . . . . . . . . 22 - 5.7 Retaining Configured Addresses for Stability . . . . . . . 22 - 6. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . 23 - 7. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . 23 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 24 - 9.2 Informative References . . . . . . . . . . . . . . . . . . . 24 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 - A. LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION . . . . . . 25 - B. CHANGES SINCE RFC 1971 . . . . . . . . . . . . . . . . . . . . 27 - C. CHANGES SINCE RFC 2462 . . . . . . . . . . . . . . . . . . . . 27 - D. CHANGE HISTORY . . . . . . . . . . . . . . . . . . . . . . . . 28 + 4.1 Site Renumbering . . . . . . . . . . . . . . . . . . . . . 9 + 5. PROTOCOL SPECIFICATION . . . . . . . . . . . . . . . . . . . . 10 + 5.1 Node Configuration Variables . . . . . . . . . . . . . . . 10 + 5.2 Autoconfiguration-Related Structures . . . . . . . . . . . 11 + 5.3 Creation of Link-Local Addresses . . . . . . . . . . . . . 11 + 5.4 Duplicate Address Detection . . . . . . . . . . . . . . . 12 + 5.4.1 Message Validation . . . . . . . . . . . . . . . . . . 14 + 5.4.2 Sending Neighbor Solicitation Messages . . . . . . . . 14 + 5.4.3 Receiving Neighbor Solicitation Messages . . . . . . . 15 + 5.4.4 Receiving Neighbor Advertisement Messages . . . . . . 16 + 5.4.5 When Duplicate Address Detection Fails . . . . . . . . 16 + 5.5 Creation of Global Addresses . . . . . . . . . . . . . . . 17 + 5.5.1 Soliciting Router Advertisements . . . . . . . . . . . 17 + 5.5.2 Absence of Router Advertisements . . . . . . . . . . . 17 + 5.5.3 Router Advertisement Processing . . . . . . . . . . . 18 + 5.5.4 Address Lifetime Expiry . . . . . . . . . . . . . . . 20 + 5.6 Configuration Consistency . . . . . . . . . . . . . . . . 21 + 5.7 Retaining Configured Addresses for Stability . . . . . . . 21 + 6. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . 22 + 7. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . 22 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 + 9.2 Informative References . . . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 + A. LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION . . . . . . 24 + B. CHANGES SINCE RFC 1971 . . . . . . . . . . . . . . . . . . . . 26 + C. CHANGES SINCE RFC 2462 . . . . . . . . . . . . . . . . . . . . 26 + D. CHANGE HISTORY . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . 31 1. INTRODUCTION This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6 (IPv6). The - autoconfiguration process includes creating a link-local address and - verifying its uniqueness on a link, determining what information can - be autoconfigured (addresses, other information, or both), and in the - case of addresses, whether they can be obtained through the stateless - mechanism, the stateful mechanism, or both. This document defines - the process for generating a link-local address, the process for + autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, - and the Duplicate Address Detection procedure. The details of - autoconfiguration using the stateful protocol is specified in - [RFC3315] and [RFC3736]. + and the Duplicate Address Detection procedure to verify the + uniqueness of the addresses on a link. - IPv6 defines both a stateful and stateless address autoconfiguration - mechanism. Stateless autoconfiguration requires no manual + The IPv6 stateless autoconfiguration mechanism requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers. The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. Routers advertise prefixes that identify the subnet(s) associated with a link, while hosts generate an "interface identifier" that uniquely identifies an interface on a subnet. An address is formed by combining the two. In the absence of routers, a host can only generate link-local addresses. However, link-local addresses are sufficient for allowing communication among nodes attached to the same link. - In the stateful autoconfiguration model, hosts obtain interface - addresses and/or configuration information and parameters from a - Dynamic Host Configuration Protocol (DHCPv6) server. Servers - maintain a database that keeps track of which addresses have been - assigned to which hosts. The stateful autoconfiguration protocol - allows hosts to obtain addresses, other configuration information or - both from a server. Stateless and stateful autoconfiguration - complement each other. For example, a host can use stateless - autoconfiguration to configure its own addresses, but use stateful - autoconfiguration to obtain other information. - - To obtain other configuration information without configuring - addresses in the stateful autoconfiguration model, a subset of DHCPv6 - [RFC3736] will be used. While the model is called "stateful" here in - order to highlight the contrast to the stateless protocol defined in - this document, the intended protocol is also defined to work in a - stateless fashion. This is based on a result, through operational - experiments, that all known "other" configuration information can be - managed by a stateless server, that is, a server that does not - maintain state of each client that the server provides with the - configuration information. - The stateless approach is used when a site is not particularly concerned with the exact addresses hosts use, so long as they are - unique and properly routable. The stateful approach is used when a + unique and properly routable. On the other hand, Dynamic Host + Configuration Protocol for IPv6 (DHCPv6) [RFC3315] is used when a site requires tighter control over exact address assignments. Both - stateful and stateless address autoconfiguration may be used - simultaneously. The site administrator specifies which type of - autoconfiguration is available through the setting of appropriate - fields in Router Advertisement messages [I-D.ietf-ipv6-2461bis]. + stateless address autoconfiguration and DHCPv6 may be used + simultaneously. IPv6 addresses are leased to an interface for a fixed (possibly infinite) length of time. Each address has an associated lifetime that indicates how long the address is bound to an interface. When a lifetime expires, the binding (and address) become invalid and the address may be reassigned to another interface elsewhere in the Internet. To handle the expiration of address bindings gracefully, an address goes through two distinct phases while assigned to an interface. Initially, an address is "preferred", meaning that its use in arbitrary communication is unrestricted. Later, an address @@ -166,23 +131,23 @@ an address is discouraged, but not strictly forbidden. New communication (e.g., the opening of a new TCP connection) should use a preferred address when possible. A deprecated address should be used only by applications that have been using it and would have difficulty switching to another address without a service disruption. To ensure that all configured addresses are likely to be unique on a given link, nodes run a "duplicate address detection" algorithm on addresses before assigning them to an interface. The Duplicate Address Detection algorithm is performed on all addresses, - independent of whether they are obtained via stateless or stateful - autoconfiguration. This document defines the Duplicate Address - Detection algorithm. + independent of whether they are obtained via stateless + autoconfiguration or DHCPv6. This document defines the Duplicate + Address Detection algorithm. The autoconfiguration process specified in this document applies only to hosts and not routers. Since host autoconfiguration uses information advertised by routers, routers will need to be configured by some other means. However, it is expected that routers will generate link-local addresses using the mechanism described in this document. In addition, routers are expected to successfully pass the Duplicate Address Detection procedure described in this document on all addresses prior to assigning them to an interface. @@ -314,77 +279,75 @@ some set of addresses, but the two sets of definitions must be consistent. In many cases, the identifier will be derived from the interface's link-layer address. 2.1 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 [RFC2119]. + Note that this document intentionally limits the use of the keywords + to the protocol specification (Section 5). + 3. DESIGN GOALS Stateless autoconfiguration is designed with the following goals in mind: o Manual configuration of individual machines before connecting them to the network should not be required. Consequently, a mechanism is needed that allows a host to obtain or create unique addresses for each of its interfaces. Address autoconfiguration assumes that each interface can provide a unique identifier for that interface (i.e., an "interface identifier"). In the simplest case, an interface identifier consists of the interface's link-layer address. An interface identifier can be combined with a prefix to form an address. o Small sites consisting of a set of machines attached to a single - link should not require the presence of a stateful server or - router as a prerequisite for communicating. Plug-and-play - communication is achieved through the use of link-local addresses. - Link-local addresses have a well-known prefix that identifies the - (single) shared link to which a set of nodes attach. A host forms - a link-local address by appending its interface identifier to the + link should not require the presence of a DHCPv6 server or router + as a prerequisite for communicating. Plug-and-play communication + is achieved through the use of link-local addresses. Link-local + addresses have a well-known prefix that identifies the (single) + shared link to which a set of nodes attach. A host forms a + link-local address by appending its interface identifier to the link-local prefix. o A large site with multiple networks and routers should not require - the presence of a stateful address configuration server. In order - to generate global addresses, hosts must determine the prefixes - that identify the subnets to which they attach. Routers generate - periodic Router Advertisements that include options listing the - set of active prefixes on a link. + the presence of a DHCPv6 server for address configuration. In + order to generate global addresses, hosts must determine the + prefixes that identify the subnets to which they attach. Routers + generate periodic Router Advertisements that include options + listing the set of active prefixes on a link. o Address configuration should facilitate the graceful renumbering of a site's machines. For example, a site may wish to renumber all of its nodes when it switches to a new network service provider. Renumbering is achieved through the leasing of addresses to interfaces and the assignment of multiple addresses to the same interface. Lease lifetimes provide the mechanism through which a site phases out old prefixes. The assignment of multiple addresses to an interface provides for a transition period during which both a new address and the one being phased out work simultaneously. - o System administrators need the ability to specify whether - stateless autoconfiguration, stateful autoconfiguration, or both - are available. Router Advertisements include flags which can be - used to indicate which mechanisms are available. - 4. PROTOCOL OVERVIEW This section provides an overview of the typical steps that take place when an interface autoconfigures itself. Autoconfiguration is performed only on multicast-capable links and begins when a multicast-capable interface is enabled, e.g., during system startup. Nodes (both hosts and routers) begin the autoconfiguration process by generating a link-local address for the interface. A link-local address is formed by appending the interface's identifier to the - well-known link-local prefix. + well-known link-local prefix [RFC3513]. Before the link-local address can be assigned to an interface and used, however, a node must attempt to verify that this "tentative" address is not already in use by another node on the link. Specifically, it sends a Neighbor Solicitation message containing the tentative address as the target. If another node is already using that address, it will return a Neighbor Advertisement saying so. If another node is also attempting to use the same address, it will send a Neighbor Solicitation for the target as well. The exact number of times the Neighbor Solicitation is (re)transmitted and the delay time @@ -402,76 +365,56 @@ Once a node ascertains that its tentative link-local address is unique, it assigns the address to the interface. At this point, the node has IP-level connectivity with neighboring nodes. The remaining autoconfiguration steps are performed only by hosts; the (auto)configuration of routers is beyond the scope of this document. The next phase of autoconfiguration involves obtaining a Router Advertisement or determining that no routers are present. If routers are present, they will send Router Advertisements that specify what - sort of autoconfiguration a host can do. Note that stateful - autoconfiguration may still be available even if no routers are - present. + sort of autoconfiguration a host can do. Note that the DHCPv6 + service for address configuration may still be available even if no + routers are present. Routers send Router Advertisements periodically, but the delay between successive advertisements will generally be longer than a host performing autoconfiguration will want to wait [I-D.ietf-ipv6-2461bis]. To obtain an advertisement quickly, a host sends one or more Router Solicitations to the all-routers multicast - group. Router Advertisements contain two flags indicating what type - of stateful autoconfiguration (if any) is available. A "managed - address configuration (M)" flag indicates whether hosts can use - stateful autoconfiguration [RFC3315] to obtain addresses. An "other - stateful configuration (O)" flag indicates whether hosts can use - stateful autoconfiguration [RFC3736] to obtain additional information - (excluding addresses). - - The details of how a host may use the M flag, including any use of - the "on" and "off" transitions for this flag, to control the use of - the stateful protocol for address assignment will be described in a - separate document. Similarly, the details of how a host may use the - O flag, including any use of the "on" and "off" transitions for this - flag, to control the use of the stateful protocol for getting other - configuration information will be described in a separate document. - However a host uses the M and O flags, and local configuration to - control autoconfiguration, the default setting will result in - received Router Advertisements being processed for stateless address - autoconfiguration. + group. Router Advertisements also contain zero or more Prefix Information options that contain information used by stateless address autoconfiguration to generate global addresses. It should be noted - that the stateless and stateful address autoconfiguration fields in - Router Advertisements are processed independently of one another, and - a host may use both stateful and stateless address autoconfiguration - simultaneously. One Prefix Information option field, the "autonomous - address-configuration flag", indicates whether or not the option even - applies to stateless autoconfiguration. If it does, additional - option fields contain a subnet prefix together with lifetime values - indicating how long addresses created from the prefix remain - preferred and valid. + that a host may use both stateless address autoconfiguration and + DHCPv6 simultaneously. One Prefix Information option field, the + "autonomous address-configuration flag", indicates whether or not the + option even applies to stateless autoconfiguration. If it does, + additional option fields contain a subnet prefix together with + lifetime values indicating how long addresses created from the prefix + remain preferred and valid. Because routers generate Router Advertisements periodically, hosts will continually receive new advertisements. Hosts process the information contained in each advertisement as described above, adding to and refreshing information received in previous advertisements. - For safety, all addresses must be tested for uniqueness prior to - their assignment to an interface. The test should individually be - performed on all addresses obtained manually, via stateless address - autoconfiguration, or via stateful address autoconfiguration. To - accommodate sites that believe the overhead of performing Duplicate - Address Detection outweighs its benefits, the use of Duplicate - Address Detection can be disabled through the administrative setting - of a per-interface configuration flag. + By default, all addresses should be tested for uniqueness prior to + their assignment to an interface for safety. The test should + individually be performed on all addresses obtained manually, via + stateless address autoconfiguration, or via DHCPv6. To accommodate + sites that believe the overhead of performing Duplicate Address + Detection outweighs its benefits, the use of Duplicate Address + Detection can be disabled through the administrative setting of a + per-interface configuration flag. To speed the autoconfiguration process, a host may generate its link-local address (and verify its uniqueness) in parallel with waiting for a Router Advertisement. Because a router may delay responding to a Router Solicitation for a few seconds, the total time needed to complete autoconfiguration can be significantly longer if the two steps are done serially. 4.1 Site Renumbering @@ -595,29 +538,30 @@ carefully define the length so that link-local addresses can be autoconfigured on the link. A link-local address has an infinite preferred and valid lifetime; it is never timed out. 5.4 Duplicate Address Detection Duplicate Address Detection MUST be performed on all unicast addresses prior to assigning them to an interface, regardless of - whether they are obtained through stateful, stateless or manual - configuration, with the following exceptions: + whether they are obtained through stateless autoconfiguration, + DHCPv6, or manual configuration, with the following exceptions: - An interface whose DupAddrDetectTransmits variable is set to zero does not perform Duplicate Address Detection, - Duplicate Address Detection MUST NOT be performed on anycast addresses (note that anycast addresses cannot syntactically be distinguished from unicast addresses), and + - Each individual unicast address SHOULD be tested for uniqueness. Note that there are implementations deployed that only perform Duplicate Address Detection for the link-local address and skip the test for the global address using the same interface identifier as that of the link-local address. Whereas this document does not invalidate such implementations, this kind of "optimization" is NOT RECOMMENDED, and new implementations MUST NOT do that optimization. This optimization came from the assumption that all of an interface's addresses are generated from the same identifier. However, the assumption does actually not @@ -831,41 +775,41 @@ Note: as specified in Section 2, "IP" means "IPv6" in the above description. While the background rationale about hardware address is independent of particular network protocols, its effect on other protocols is beyond the scope of this document. 5.5 Creation of Global Addresses Global addresses are formed by appending an interface identifier to a prefix of appropriate length. Prefixes are obtained from Prefix Information options contained in Router Advertisements. Creation of - global addresses and configuration of other parameters as described - in this section SHOULD be locally configurable. However, the - processing described below MUST be enabled by default. + global addresses as described in this section SHOULD be locally + configurable. However, the processing described below MUST be + enabled by default. 5.5.1 Soliciting Router Advertisements Router Advertisements are sent periodically to the all-nodes multicast address. To obtain an advertisement quickly, a host sends out Router Solicitations as described in [I-D.ietf-ipv6-2461bis]. 5.5.2 Absence of Router Advertisements - Even if a link has no routers, stateful autoconfiguration to obtain - addresses and other configuration information may still be available, - and hosts may want to use the mechanism. From the perspective of - autoconfiguration, a link has no routers if no Router Advertisements - are received after having sent a small number of Router Solicitations - as described in [I-D.ietf-ipv6-2461bis]. + Even if a link has no routers, the DHCPv6 service to obtain addresses + may still be available, and hosts may want to use the service. From + the perspective of autoconfiguration, a link has no routers if no + Router Advertisements are received after having sent a small number + of Router Solicitations as described in [I-D.ietf-ipv6-2461bis]. Note that it is possible that there is no router on the link in this sense but there is a node that has the ability to forward packets. + In this case, the forwarding node's address must be manually configured in hosts to be able to send packets off-link, since the only mechanism to configure the default router's address automatically is the one using Router Advertisements. 5.5.3 Router Advertisement Processing For each Prefix-Information option in the Router Advertisement: a) If the Autonomous flag is not set, silently ignore the Prefix @@ -913,23 +857,29 @@ autoconfiguration. Note that a future revision of the address architecture [RFC3513] and a future link-type specific document, which will still be consistent with each other, could potentially allow for an interface identifier of length other than the value defined in the current documents. Thus, an implementation should not assume a particular constant. Rather, it should expect any lengths of interface identifiers. - If an address is formed successfully, the host adds it to the list - of addresses assigned to the interface, initializing its preferred - and valid lifetime values from the Prefix Information option. + If an address is formed successfully and the address is not yet in + the list, the host adds it to the list of addresses assigned to + the interface, initializing its preferred and valid lifetime + values from the Prefix Information option. Note that the check + against the prefix performed at the beginning of this step cannot + always detect the address conflict in the list. It could be + possible that an address already in the list, configured either + manually or by DHCPv6, happens to be identical to the newly + created address whereas such a case should be atypical. e) If the advertised prefix is equal to the prefix of an address configured by stateless autoconfiguration in the list, the preferred lifetime of the address is reset to the Preferred Lifetime in the received advertisement. The specific action to perform for the valid lifetime of the address depends on the Valid Lifetime in the received advertisement and the remaining time to the valid lifetime expiration of the previously autoconfigured address. We call the remaining time "RemainingLifetime" in the following discussion: @@ -1008,33 +958,32 @@ address selection including this case are described in [RFC3484] and beyond the scope of this document. An address (and its association with an interface) becomes invalid when its valid lifetime expires. An invalid address MUST NOT be used as a source address in outgoing communications and MUST NOT be recognized as a destination on a receiving interface. 5.6 Configuration Consistency - It is possible for hosts to obtain address information using both - stateless and stateful protocols since both may be enabled at the - same time. It is also possible that the values of other - configuration parameters such as MTU size and hop limit will be - learned from both Router Advertisements and the stateful - autoconfiguration protocol. If the same configuration information is - provided by multiple sources, the value of this information should be - consistent. However, it is not considered a fatal error if - information received from multiple sources is inconsistent. Hosts - accept the union of all information received via the stateless and - stateful protocols. If inconsistent information is learned from - different sources, the most recently obtained values always have - precedence over information learned earlier. + It is possible for hosts to obtain address information using both the + stateless protocol and DHCPv6 since both may be enabled at the same + time. It is also possible that the values of other configuration + parameters such as MTU size and hop limit will be learned from both + Router Advertisements and DHCPv6. If the same configuration + information is provided by multiple sources, the value of this + information should be consistent. However, it is not considered a + fatal error if information received from multiple sources is + inconsistent. Hosts accept the union of all information received via + the stateless protocol and DHCPv6. If inconsistent information is + learned from different sources, the most recently obtained values + always have precedence over information learned earlier. 5.7 Retaining Configured Addresses for Stability An implementation that has stable storage may want to retain addresses in the storage when the addresses were acquired using stateless address autoconfiguration. Assuming the lifetimes used are reasonable, this technique implies that a temporary outage (less than the valid lifetime) of a router will never result in the node losing its global address even if the node were to reboot. When this technique is used, it should also be noted that the expiration times @@ -1080,57 +1029,55 @@ of the "0 Lifetime Prefix Advertisement" denial of service attack vulnerability; this document incorporates changes that address this vulnerability. A number of people have contributed to identifying issues on a previous version of this document and to proposing resolutions to the issues, on which this version is based. In addition to those listed above, the contributors include Jari Arkko, Brian E Carpenter, Gregory Daley, Elwyn Davies, Ralph Droms, Jun-ichiro itojun Hagino, Christian Huitema, Suresh Krishnan, Soohong Daniel Park, Markku - Savela, and Pekka Savola. + Savela, Pekka Savola, and Margaret Wasserman. 9. References 9.1 Normative References [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [I-D.ietf-ipv6-2461bis] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", - draft-ietf-ipv6-2461bis-00 (work in progress), July 2004. + draft-ietf-ipv6-2461bis-01 (work in progress), October + 2004. Note: this reference is expected to be published in parallel with the referring document, both of which will be recycled as a draft standard. Upon publication the reference will be updated and this note will be removed. 9.2 Informative References [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. - [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol - (DHCP) Service for IPv6", RFC 3736, April 2004. - [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [I-D.ietf-send-cga] Aura, T., "Cryptographically Generated Addresses (CGA)", draft-ietf-send-cga-06 (work in progress), April 2004. @@ -1283,36 +1229,37 @@ o Clarified that on failure of Duplicate Address Detection, IP network operation should be disabled and that the rule should apply when the hardware address is supposed to be unique. Major clarifications: o Clarified how the length of interface identifiers should be determined, described the relationship with the prefix length advertised in Router Advertisements, and avoided using a particular length hard-coded in this document. - o Clarified that the "stateful" protocols for address configuration - and other information configuration are RFC 3315 and RFC 3736, - respectively. - o Clarified the semantics of the M and O flags based on the latest - standard and operational status. In particular, clarified that - these flags show the availability of the stateful protocol instead - of a trigger to invoke the stateful protocol. ManagedFlag and - OtherConfigFlag, which were implementation-internal variables, - were removed accordingly. + o Removed the text regarding the M and O flags, considering the + maturity of implementations and operational experiences. + ManagedFlag and OtherConfigFlag were removed accordingly. (Note + that this change does not mean the use of these flags is + deprecated.) + o Avoided the wording of "stateful configuration", which is known to + be quite confusing, and simply used "DHCPv6" wherever appropriate. o Recommended to perform Duplicate Address Detection for all unicast addresses more strongly, considering a variety of different interface identifiers, while keeping care of existing implementations. o Clarified wording in Section 5.5.4 to make clear that a deprecated address specified by an application should be used for any communication. + o Clarified the prefix check described in Section 5.5.3 using more + appropriate terms and that the check is done against the prefixes + of addresses configured by stateless autoconfiguration. o Revised the Security Considerations section with a reference to RFC 3756 and a note that the use of IP security is not always feasible. o Added a note when an implementation uses stable storage for autoconfigured addresses. Other miscellaneous clarifications: o Removed references to site-local and revised wording around the keyword. @@ -1415,29 +1363,42 @@ Changes since draft-ietf-ipv6-rfc2462bis-05.txt are: o Clarified the role of RFC 3736 in the abstract. o Clarified that the default configuration method is the one described in this document. o Changed the reference for the Neighbor Discovery protocol to [I-D.ietf-ipv6-2461bis]. o Reorganized the conditions at the beginning of Section 5.4 with an additional note to avoid confusion. - o Clarified the role of the link-local prefix in Section 5.3. o Added a reference to RFC 3810 as well as to RFC 2710. o Clarified the MLD issues a bit more. o Replaced "multicast interface" with "multicast-capable interface". o Clarified that the autoconfiguration protocol would basically be used on all types of links in line with the Neighbor Discovery protocol. + Changes since draft-ietf-ipv6-rfc2462bis-06.txt are: + + o Removed text mentioning the M and O flags to avoid having a stale + reference. + o Noted that the host should make sure that an autoconfigured global + address is not yet in the address list before adding it to the + list. + o Replaced "stateful configuration" with "DHCPv6". + o Added a reference to [RFC3513] from Section 4. + o Changed wording about Duplicate Address Detection in Section 4 to + avoid confusion on the requirement level. + o Clarified that the use of the RFC2119 keywords is intentionally + limited to the protocol specification (Section 5). + Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.