HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 00:44:24 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Thu, 08 Jun 1995 22:00:00 GMT ETag: "2e9c9d-724f-2fd772e0" Accept-Ranges: bytes Content-Length: 29263 Connection: close Content-Type: text/plain INTERNET-DRAFT June 5, 1995 IPv6 Stateless Address Autoconfiguration Status of this Memo This document is a submission to the ADDRCONF Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the addrconf@cisco.com mailing list. This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet Draft. please check the 1id-abstracts.txt listing contained in the Internet Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com or munnari.oz.au. Abstract In IPv6, there are two types of address autoconfiguration: stateless address autoconfiguration and stateful address configuration. In stateless address autoconfiguration, no state is maintained binding a particular host interface to a specific list of addresses. Rather, an address is formed algorithmically by concatenating the network prefix of the attached link to a host token that is unique per link. Hosts use stateless address autoconfiguration to form a link-local unicast address and may use stateless address autoconfiguration to form global and site-local unicast addresses. This document specifies how a host uses stateless address autoconfiguration to form a list of Expires December 5, 1995 [Page 1] INTERNET-DRAFT Stateless Address Configuration June 1995 unicast addresses per interface. It also specifies how a host determines whether to use the stateless mechanism or the stateful mechanism. Stateful address autoconfiguration is outside the scope of this document. Expires December 5, 1995 [Page 2] INTERNET-DRAFT Stateless Address Configuration June 1995 1. INTRODUCTION In IPv6, there are two types of address autoconfiguration: stateless address autoconfiguration and stateful address configuration. In stateless address autoconfiguration, no state is maintained binding a particular host interface to a specific list of addresses. Rather, an interface address is formed algorithmically by concatenating the net- work prefix of the attached link to a host token unique per link. In stateful address configuration, state is maintained, typically by a server. For example, the IPv6 Dynamic Host Configuration Protocol is an example of stateful address autoconfiguration. Stateless autoconfiguration is designed to make address configuration very simple to use and implement, and is suitable for environments with simple topologies, e.g. routerless networks, and for environ- ments where system administrative control is not desired. In con- trast, stateful address configuration is designed to support flexible address assignment and is suitable for more sophisticated topologies and for environments where system administrative control is desired. A host always uses stateless address autoconfiguration to form a link-local address per interface. A host may use either stateless or stateful autoconfiguration to configure addresses of inter-link scope for an interface, i.e. global or site-local addresses. This document describes how a host forms unicast addresses per inter- face using stateless autoconfiguration. It also specifies how a host determines whether to use the stateless mechanism or the stateful mechanism. Stateful address autoconfiguration is outside the scope of this document. Expires December 5, 1995 [Page 3] INTERNET-DRAFT Stateless Address Configuration June 1995 2. OVERVIEW An IPv6 host may have multiple unicast addresses per interface[1]. The addresses can have one of three scopes: a link-local scope, a site-local scope, or a global scope. Addresses of all three address scopes can be autoconfigured. A host is able to autoconfigure a link-local address completely autonomously. In particular, a host can form a link-local address without a router present on the link. A host is able to autoconfigure an inter-link scope address only when a router is present on the link. The scope of the inter-link address formed depends on the prefix advertised on the link. On initialization of an interface, a host forms a link-local address by concatenating a well-known link-local prefix[1] to a token that is unique per link. The definition of the tokens used are link- dependent. For example, in the case of a host attached to a link that uses IEEE 802 addresses, the token is an IEEE 802 address asso- ciated with the interface. A host forms or updates an inter-link scope address on hearing prefix advertisements advertised by a router. A global or site-local address is formed by concatenating a network prefix to a host token that is unique per link in the same way as described above. The mechanism used to advertise network prefixes for the purposes of address confi- guration is the same as that used in Neighbor Discovery[2] for the purposes of prefix discovery. Rather than specify two separate mechanisms to advertise the same prefix information, we use a single mechanism which requires hosts to perform both prefix discovery pro- cessing and address autoconfiguration processing on receiving a pre- fix advertisement. Note that, when prefixes are advertised, it is possible to indicate whether the prefixes are to be used for prefix discovery only, address autoconfiguration only or both. One of the goals of IPv6 address autoconfiguration is not only to be able to autoconfigure addresses on startup, but to be able to recon- figure addresses dynamically. Address reconfiguration ("renumbering") enables hosts to acquire new addresses and relinquish old addresses automatically. Old addresses may then be reused. To enable hosts to renumber with minimal disruption of existing communications, prefixes are advertised with two lifetimes: a deprecation lifetime and an invalidation lifetime. The deprecation lifetime indicates when an address formed from a prefix must be deprecated. A deprecated address may continue to be used as a source address in existing Expires December 5, 1995 [Page 4] INTERNET-DRAFT Stateless Address Configuration June 1995 communications, but should not be used as a source address in new communications. The invalidation lifetime indicates when an address formed from a prefix is no longer valid and may be reused. Invalid addresses cannot be used in any communications. By specifying two separate lifetimes, a host can gradually phase out use of old addresses, while beginning to use new addresses for new communica- tions (if any). The deprecation and invalidation lifetimes are con- figurable by a system administrator and so the transition from old to new addresses may be as quick (the deprecation and invalidation life- times are the same) or as slow as desired. One of the basic assumptions of stateless autoconfiguration is that the host token is at least unique per link. However, in practice, host tokens are not always unique because of errors in assignment. Thus, it cannot be guaranteed that IPv6 addresses formed from a host token are indeed unique among all hosts on a link. Since duplicate IPv6 addresses are very difficult to track down and debug, we specify a procedure for detecting duplicate addresses that hosts should use on initialising an interface. Note that this procedure is not com- pletely reliable, and so duplicate addresses may still exist. The procedure makes use of Neighbor Solicitations and Advertisements[2] in a special-purpose way. Briefly, a host uses a Neighbor Solicita- tion to solicit for itself. If it discovers that another host has the address through receiving a Neighbor Advertisement, the valida- tion check fails and the host ceases operation on that interface. Note that the host that is already using the address (presumably leg- itimately) continues unharmed, although it may log a message to the effect that it has received a solicitation for its own address. This document specifies router and host behavior related to stateless address configuration and duplicate address detection in more detail in the sections that follow. Expires December 5, 1995 [Page 5] INTERNET-DRAFT Stateless Address Configuration June 1995 3. ROUTER BEHAVIOR The stateless address autoconfiguration mechanism relies on the pre- fix discovery mechanism specified in [2] for advertising network pre- fixes required for the formation of addresses with site-local or glo- bal scope. A prefix is advertised in a Prefix Information extension of a Router Advertisement. The Prefix Information extension includes the prefix and its length, flags indicating whether the information is to be used for prefix discovery or address configuration, and two lifetimes: the deprecation lifetime and the invalidation lifetime. The Router Advertisement itself includes flags indicating whether stateful address configuration should be used by hosts and whether other configuration information (besides an address) needs to be con- figured. Router Advertisement and Solicitation processing is specified com- pletely in [2] along with the message formats and configuration vari- ables. Additional configuration variables pertinent to stateless address configuration are specified below. 3.1. Router Configuration Variables In addition to the configuration variables specified in [2], routers MUST also be configurable as follows. For each of the prefixes to be advertised in Prefix Information extensions per interface: Autonomous Flag If set, the prefix is being advertised for the purposes of stateless address configuration. Default: TRUE Deprecation Lifetime The value to be placed in the Deprecation Lifetime field of Expires December 5, 1995 [Page 6] INTERNET-DRAFT Stateless Address Configuration June 1995 Prefix Information extensions in Router Advertisements sent from the interface in seconds. Invalidation Lifetime The value to be placed in the Invalidation Lifetime field of Prefix Information extensions in Router Advertisements sent from the interface in seconds. Must be no less than Deprecation Lifetime. For each advertising interface: Administered Flag If set, the host must autoconfigure addresses using stateful address autoconfiguration. Default: FALSE Other Flag If set, the host must autoconfigure other configuration infor- mation (besides the address) using stateful autoconfiguration. Default: FALSE NOTE: All routers advertising a given prefix on a link MUST set all of the configuration variables to the same value. Expires December 5, 1995 [Page 7] INTERNET-DRAFT Stateless Address Configuration June 1995 4. HOST BEHAVIOR Conceptually, a host maintains a list of addresses per interface. Entries in the list are created as a result of forming addresses from prefixes advertised in Prefix Information extensions of Router Adver- tisements. Each entry in the list has two associated timers, a deprecation timer and an invalidation timer, which have values set according to lifetimes learned from the router advertisement. In addition, the address list always includes the link-local address, which the host forms autonomously whenever an interface is initial- ised. The deprecation and invalidation lifetimes of a link-local address are set to infinity. This section specifies host address autoconfiguration behavior on interface initialisation and on receiving a Router Advertisement. This section also specifies a host protocol for attempting to verify that an address is not a duplicate. 4.1. Host Configuration Variables A host MUST allow the following variable to be configured per inter- face: Perform_Auto_Config If set, the host MUST perform address autoconfiguration process- ing. Default: TRUE 4.2. Router Advertisement Processing An "autoconfigurable" interface is one on which Router Advertisements are received and the Perform_Auto_Config flag is set. A host MUST perform the following address configuration processing when a solicited or unsolicited Router Advertisement is received over Expires December 5, 1995 [Page 8] INTERNET-DRAFT Stateless Address Configuration June 1995 an autoconfigurable interface: For each valid Router Advertisement: If the Administered flag is set, the host MUST use stateful auto- configuration to acquire a list of site-local or global addresses per interface. If the Other flag is set, the host MUST use stateful autoconfi- guration to acquire other configuration information besides the address. For each Prefix-Information extension in the Router Advertisement that has the Autonomous flag set: - If the prefix advertised matches the prefix of an autoconfig- ured address already in the list, then set the deprecation timer to that of the deprecation lifetime specified in the extension and the invalidation timer to that of the invalida- tion lifetime. Note that this processing does not apply to a link-local address. - If the prefix advertised does not match the prefix of an address already in the list, then form an address using this network prefix. Appendix A specifies how to form an address for hosts that have IEEE 802 tokens. The extension is ignored if the prefix is not valid, e.g. it is not the right length for forming an address with the given host token. Add this address to the list with the deprecation timer set to that of the deprecation lifetime and the invalidation timer to that of the invalidation lifetime. Note that if the deprecation lifetime is zero, the address with that prefix is immediately deprecated. Similarly, if the invalida- tion lifetime is zero, the address with that prefix is immediately made invalid. (The invalidation lifetime is defined to be no less than the deprecation lifetime.) An address is valid until the deprecation timer expires. A valid address may be used as a source address in all outgoing Expires December 5, 1995 [Page 9] INTERNET-DRAFT Stateless Address Configuration June 1995 communications and MUST be accepted as a destination address in all incoming communications. When the deprecation lifetime of an address expires, an address is said to be deprecated. A deprecated address SHOULD NOT be used as a source address in new communications. However, a deprecated address SHOULD continue to be used as a source address if it is in use in existing communications. The IP layer MUST continue to accept datagrams destined to a deprecated address. Upper layers MAY refuse to accept new communications requests to a deprecated address, however. An address remains deprecated until its invalidation timer expires at which point the address becomes invalid. An invalid address can no longer be used as a source address in outgoing communications and is not recognised as a valid destination address in incoming communications. Note that, when choosing a source address in outgoing communica- tons, a global valid address should be used in preference to a site-local valid address, which in turn should be used in prefer- ence to the link-local address. Similarly, a global deprecated address should also be used in preference to a site-local depre- cated addresses. Note that the link-local address is never depre- cated; it is always valid. One of the implications of these rules is that if there are no valid inter-link scope addresses, e.g. all global and site-local addresses are deprecated, then the host will default to using the link-local address as a source address in new communications. To limit storage space required for the address list, a host may choose not to store all valid and deprecated addresses. Deprecated addresses that are not in use by existing communications should be discarded in favor of valid addresses and deprecated addresses that are in use. If a host determines that there are no IPv6 routers on a link, either on startup or during normal processing, a host MUST attempt to use stateful autoconfiguration to acquire addresses or other configuration information if it is not already doing so. This is needed to support networks with no IPv6 routers. The host deter- mines that there are no routers on the link after startup if no Router Advertisements are heard in the time that it would take to send MAX_ROUTER_SOLICITATIONs and wait for a response[2]. During normal processing, it is determined that there are no routers when Expires December 5, 1995 [Page 10] INTERNET-DRAFT Stateless Address Configuration June 1995 all router advertisements have timed out. If a router comes up on the link and Router Advertisements begin to be received, a host MUST start to use Router Advertisements in the normal way, and, in particular, use advertisements to determine whether stateless or stateful address configuration should be in use. Note that if a host does not receive Router Advertisements because of some error, e.g. all routers are down or there is a network partition, hosts will attempt to change mode from stateless (assuming this was the advertised mode) to stateful and then back again when Router Advertisements start being heard. This means that if the stateful mode is available, it should be configured correctly to serve only the hosts that it should, since hosts may attempt to use it, even if it is not the intention that they do so. A host must behave reasonably when there is a change from the stateless mode to the stateful mode, and vice versa. This can hap- pen because routers advertise a new configuration mode due to a deliberate change by a system administrator, or because of a change in topology, e.g. an IPv6 router is connected to or removed from the link. It is possible and quite likely that during the change-over, a host will have addresses autoconfigured using both mechanisms. If the addresses acquired using the two mechanisms are the same, then the new addresses should replace the old and the aging semantics associated with the new mode apply. If the addresses acquired using the two mechanisms are different, then the old addresses should be aged according to the rules specified in the old configuration mode and the new addresses should follow the rules of the new mode. 4.3. Host Initialisation A host forms a link-local address when an autoconfigurable interface is initialised. Appendix A specifies how a host that is attached to a link that uses IEEE 802 addresses forms a link-local address. Note that an interface may be initialised after any of the following events: - The interface is initialized at system startup time. - The interface is reinitialized after a temporary interface Expires December 5, 1995 [Page 11] INTERNET-DRAFT Stateless Address Configuration June 1995 failure or after being temporarily disabled by system manage- ment. - The system changes from being a router to being a host, by hav- ing its IP forwarding capability turned off by system manage- ment. - The host is re-attached to a link after being detached for some time. - The interface has its Perform_Auto_Config flag changed from FALSE to TRUE. 4.4. Detecting Duplicate IPv6 Addresses The procedure to detect duplicate addresses MUST be implemented in hosts and SHOULD be used. In stateless address configuration, it is only necessary to check that one of the autoconfigured addresses is unique since the same token is used to form all addresses. It is recommended that the link-local address be the address checked since the host always forms this address. The procedure uses Neighbor Solicitation and Advertisement messages specified in [2] to validate an address and is specified below. Note that this mechanism is not completely reliable, and so it is possible that duplicate addresses will still exist. If a duplicate address is discovered, the host will need to be configured with a new token, or if this is not possible, the IPv6 addresses will need to be manually configured. 4.4.1. Soliciting Host Behavior The host first delays a random amount of time between 0 and DUPL_ADDRESS_DELAY seconds before sending out a Neighbor Solicitation Expires December 5, 1995 [Page 12] INTERNET-DRAFT Stateless Address Configuration June 1995 for the address. This serves to alleviate congestion when many hosts start up on the link at the same time, such as after a power failure, and helps to avoid race conditions when more than one host is trying to solicit for the same address at the same time. (It is recommended that hosts include some unique value in the seed used to initialise their pseudo-random number generators. Note that using only the host token as a unique value is not sufficient since the token cannot be relied upon to be unique. Although the randomization range is speci- fied in units of seconds, the actual randomly-chosen value should not be in units of whole seconds, but rather in units of the highest available timer resolution.) The node then sends a Neighbor Solicitation with a target address containing the address to be validated. The source is set to the unspecified address and the destination is set to the solicited-node multicast address. The Source Link Layer Address extension SHOULD NOT be sent. NOTE: There SHOULD be some way to inhibit local delivery of the soli- citation since, in general, it will not be possible for a host to determine whether a solicitation is from itself or from another host with a duplicate address. If local delivery cannot be inhibited, then the host should ignore the first Neighbor Solicitation with an unspecified source address or wait for a period of DUPL_ADDR_IGNORE_TIMER seconds after sending a Neighbor Solicitation before beginning to process solicitations again. If after sending a solicitation, no advertisement is received from the target, the node SHOULD retransmit the solicitation every DUPL_ADDR_RETRANS_TIMER seconds until either an advertisement is received or the solicitation has been retransmitted MAX_DUPL_ADDR_RETRANS times. If an advertisement is received with a target address the same as the address being validated, it must cease operation on that interface and indicate an appropriate error. If no such advertisement is received in response to the Neighbor Solicita- tions sent, the address is considered to be valid. 4.4.2. Solicited Node Behavior When a host is in the process of validating an address, it MUST NOT send any advertisement in response to a solicitation for that Expires December 5, 1995 [Page 13] INTERNET-DRAFT Stateless Address Configuration June 1995 address. Rather, all solicitations for the address are ignored, except when the solicitation is from the unspecified address i.e. the Neighbor Solicitation message has a target address which is the same as the address to be validated, and a source address that is the unspecified address. (Note that any solicitation that is likely to be a loopback solicitation should be ignored too as mentioned in the above section.) If a solicitation is received from the unspecified address, the host must cease operation on that interface and indicate an appropriate error. Once a host has validated its address, it responds to a Neighbor Sol- icitation with a Neighbor Advertisement as specified in [2]. However, the processing of the solicitation is somewhat different from that in [2] when a solicitation is received from the unspecified address. In this case, the host MUST ignore any Link Layer Address Extension in the solicitation and MUST NOT perform any link-layer address resolu- tion processing before sending a Neighbor Advertisement. The host sends the Neighbor Advertisement to the all-nodes multicast address of the soliciting host. The target address is copied from the solici- tation message. The source address MUST be set to the address of the target field. The Target Link Layer Address extension need not be filled in. 4.4.3. Constants DUPL_ADDR_DELAY 4 seconds (XX) DUPL_ADDR_IGNORE_TIMER 0.1 seconds DUPL_ADDR_RETRANS_TIMER 4 seconds (XX) MAX_DUPL_ADDR_RETRANS 1 transmission (XX) 5. SECURITY CONSIDERATIONS To be completed. Expires December 5, 1995 [Page 14] INTERNET-DRAFT Stateless Address Configuration June 1995 6. APPENDIX A: FORMING AN IPv6 ADDRESS FOR IEEE 802 LINKS The token for an interface on an IEEE 802 link or any link that uses IEEE 802 addressing, such as FDDI, is the 48-bit IEEE 802 address in canonical format, i.e. the Individual/Group bit is the low-order bit of the furst byte. A host forms an IPv6 address per link by concatenating an 80-bit pre- fix with the IEEE 802 address as follows: | 80 bits | 48 bits | +---------------------------------------+------------------------+ | prefix | IEEE 802 address | +----------------------------------------------------------------+ In the case of a link-local prefix, the prefix is well-defined[1]. The prefixes of other types of addresses need to be configured. Expires December 5, 1995 [Page 15] INTERNET-DRAFT Stateless Address Configuration June 1995 7. REFERENCES [1] R. Hinden and S. Deering, "Internet Protocol Version (IPv6) Addressing Architecture", Internet Draft, May 1995, draft-ietf- ipngwg-addr-arch-02.txt [2] T. Narten and E. Nordmark, "IPv6 Neighbor Discovery", Internet Draft, June 1995, Acknowledgements The author would like to thank the members of both the IPNG and ADDRCONF working groups for their input. In particular, thanks to Jim Bound, Steve Deering, Erik Nordmark and Bill Simpson. Author's Addresses Susan Thomson Bellcore 445 South Street Morristown, NJ 07960 U.S.A. Phone: +1 201-829-4514 Email: set@thumper.bellcore.com Expires December 5, 1995 [Page 16] INTERNET-DRAFT Stateless Address Configuration June 1995 Expires December 5, 1995 [Page 17]