ADDRCONF Working Group Susan Thomson (Bellcore) INTERNET-DRAFT January 31, 1995 IPv6 Address Autoconfiguration Status of this Memo 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 This document specifies how a host autoconfigures one or more addresses per interface. A host can form an intra-link scope address autonomously based on information local to the host. A host can form an inter-link scope address in two ways: either semi-autonomously, based on knowledge of subnet prefixes advertised by routers, or by using DHCPv6. All mechanisms rely on a host having a token per interface that is unique at least per subnet. This document specifies how a host forms an intra-link scope address autonomously and an inter-link scope address semi-autonomously using IEEE 802 tokens to identify each interface. DHCPv6 is described elsewhere. Expires July 31, 1995 [Page 1] INTERNET-DRAFT Address Configuration January 1995 1. INTRODUCTION An IPv6 host can autoconfigure two types of address: 1. an intra-link scope address, 2. an inter-link scope address. An intra-link scope address is autoconfigurable in the absence of a router. An inter-link scope address is autoconfigurable only when a router is present on the link. There is only one way to form an intra-link scope address. On ini- tialization of an interface, a host forms an IPv6 intra-link scope address by concatenating a predefined intra-link scope prefix to a token that is unique per link. Typically, the definition of the token is link-layer dependent. In the case of a host attached to an IEEE 802 network, for example, the token is the IEEE 802 address of the interface. There are two ways to form an inter-link scope address. In the first mechanism, a host forms an IPv6 inter-link scope address by con- catenating a network prefix advertised in a Router Advertisement[IPv6-DISC-PROC,IPv6-DISC-PROC] to a token that is unique per link. The other mechanism available to hosts is to use the IPv6 version of the Dynamic Host Configuration Protocol (DHCPv6)[IPv6-DHCP]. The choice of protocol to use is advertised by the router, and this choice is configurable by the system administra- tor. The first mechanism for forming an inter-link scope address is suit- able for environments where no administrative control is desired. It is a simple, efficient protocol designed for a very specific purpose: to make stateless address configuration very straightforward to use and implement. DHCPv6 is a more complex protocol allowing for very flexible address assignment under the control of a system administra- tor. This protocol typically requires significant system management, including server and database configuration. This document describes the general host address autoconfiguration procedure in Section 2, and how a host forms an intra-link scope address and an inter-link scope address without using DHCPv6 in Sec- tions 3 and 4, respectively. The DHCPv6 protocol is specified else- where [IPv6-DHCP]. The scope of the document is limited to hosts Expires July 31, 1995 [Page 2] INTERNET-DRAFT Address Configuration January 1995 attached to IEEE 802 networks. The effect of the transition scheme on the address autoconfiguration procedure is discussed in Section 5. Expires July 31, 1995 [Page 3] INTERNET-DRAFT Address Configuration January 1995 2. PROCEDURE FOR FORMING AND MAINTAINING ADDRESSES A host maintains a list of addresses per interface. At a minimum, the list includes the intra-link scope address, which the host can form autonomously whenever an interface is initialised. If a router is attached to the link, the list will also include inter-link scope addresses formed either from subnet prefixes advertised in router advertisements or by making requests to DHCPv6. Inter-link scope addresses may also be manually configured. 2.1. Host Configuration A host must maintain a list of the following configurable variables per interface: Address A valid IPv6 unicast address for this interface Default: None LifeTime: The length of time for which an address is valid in seconds. Default: Infinity An intra-link scope address and all manually configured addresses have their lifetimes set to infinity. A host may also allow the following variable to be configured by a system administrator per interface: Perform_Auto_Address If TRUE, the host must perform address autoconfiguration process- ing. Otherwise, the host performs no address autoconfiguration Expires July 31, 1995 [Page 4] INTERNET-DRAFT Address Configuration January 1995 processing at all. Default: TRUE 2.2. Router Configuration A router must be configurable by a system administrator so that the choice of mechanism used for host configuration of inter-link scope addresses can be controlled. Thus, a router must allow the following variable to be configured by a system administrator per interface: Perform_Auto_Address If and only if TRUE, the router must send an Address Prefix exten- sion in every Router Advertisement. Default: TRUE All router interfaces advertising a given subnet prefix on a link must be configured to advertise the same address autoconfiguration mode to hosts. 2.3. Host Address Autoconfiguration Procedure A host must perform the following procedure for each interface when booting or whenever an interface needs to be initialised: When a host boots or at any time when a host has no address for an autoconfigurable interface, e.g. when an interface is enabled after being disabled, the host forms an address of intra-link scope and adds it to the list of addresses. Section 3 specifies how a host forms an intra-link scope address. The host must send a Router Solicitation so that inter-link scope addresses can be formed (or verified) as soon as possible. Expires July 31, 1995 [Page 5] INTERNET-DRAFT Address Configuration January 1995 When a solicited or unsolicited Router Advertisement is received over an interface, the host must perform the following address configura- tion processing: If an Address Prefix extension exists, the host forms or verifies its inter-link addresses autonomously as specified in Section 4. Otherwise, the implication is that the host must use DHCPv6 for address autoconfiguration. If no address exists on the interface, the host must initiate a request to a DHCPv6 server to acquire a new address. (Verification and renewal of existing addresses is performed at DHCPv6-specified times.) If DHCPv6 fails for any rea- son, the host falls back to using an intra-link scope address or a manually configured inter-link scope address until a DHCPv6 server request is successful. Note that the above procedure should continue to operate when a sys- tem administrator decides to change the autoconfiguration mode from the autonomous mode (the host forms the address) to DHCPv6, and vice versa. The requirement during a changeover is that the system administrator must ensure that a DHCPv6 server is configured to hand out addresses that are unique per subnet, particularly with respect to addresses that hosts configure autonomously. To avoid problems during a changeover, it is recommended that a DHCP server should use exactly the same algorithm to form a host address as that used in the autonomous mode, particularly when the subnet prefix used is the same. Otherwise, further precautionary measures will need to be taken to ensure correct operation. To support the changeover from autonomous mode to DHCPv6 mode, DHCPv6 should provide the ability for a host to specify in a request previ- ously configured inter-link addresses. A DHCPv6 server can then validate, deprecate or forbid the use of the autonomously formed addresses. Changing from DHCPv6 mode to autonomous mode is somewhat tricky. Normal autonomous mode processing should support the changeover from DHCPv6 mode to autonomous mode assuming the above recommendation is followed. DHCPv6-assigned addresses can be validated or deprecated as a normal part of host processing when an Address Prefix extension is heard in a Router Advertisement. The Drop Address Prefix can be used to invalidate DHCPv6 addresses, if desired. Expires July 31, 1995 [Page 6] INTERNET-DRAFT Address Configuration January 1995 3. FORMING AN IEEE 802 IPv6 ADDRESS A host forms an IEEE 802 IPv6 address for an interface by concatenat- ing an 80-bit subnet prefix with the 48-bit IEEE 802 address of the interface as follows: | 80 bits | 48 bits | +---------------------------------------+------------------------+ | subnet prefix | IEEE 802 address | +----------------------------------------------------------------+ In the case of an intra-link scope prefix, the subnet prefix is well-defined (TBD). In the case of an inter-link scope prefix, the subnet prefix is con- figurable (typically in a router). Expires July 31, 1995 [Page 7] INTERNET-DRAFT Address Configuration January 1995 4. FORMING INTER-LINK SCOPE IPv6 ADDRESSES AUTONOMOUSLY 4.1. Router Operation 4.1.1. Sending Router Advertisements with Address Extensions A router may be configured to advertise address configuration infor- mation in extensions of Router Advertisements. Two extensions are defined for address configuration: the Address Prefix extension which advertises valid subnet prefixes to enable hosts to form their own addresses autonomously, and the Drop Address Prefix Extension which indicates that a subnet prefix (and hence an address formed from such a subnet prefix) is unrouteable. ED'S NOTE: I have used two new extensions here for illustrative purposes. It is likely the case that the Address Prefix Extension and the Drop Prefix Extension can be supported using the Routing Information Extensions and Change Prefix extensions defined in neighbor discovery, respectively. The details of combining the semantics of the existing extensions with that of the following extensions still need to be worked out. Expires July 31, 1995 [Page 8] INTERNET-DRAFT Address Configuration January 1995 4.1.2. Address Prefix Extension Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension | Length | Reserved |M| Prefix Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subnet Prefix | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extension TBD Length 18 Reserved Must be zero M When set, indicates more IPv6 parameters to configure besides address. Use DHCPv6 to acquire these parameters. Prefix Size Length of subnet prefix in bits. Subnet Prefix Valid subnet prefix for this link. This extension is found in Router Advertisements. 4.1.3. Drop Address Prefix Extension Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension | Length | Reserved | Prefix Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subnet Prefix | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extension TBD Length 18 Expires July 31, 1995 [Page 9] INTERNET-DRAFT Address Configuration January 1995 Reserved Must be zero Prefix Size Length of subnet prefix in bits. Subnet Prefix Subnet prefix for this link to be invalidated. This extension is found in Router Advertisements. 4.2. Host Operation 4.2.1. Processing Router Advertisements with Address Extensions On hearing a Router Advertisement on an interface, a host checks for an Address Prefix extension and a Drop Address Prefix extension. A host processes an Address Prefix extension as described in Section 4.2.2 below and a Drop Address Prefix extension as in Section 4.2.3. 4.2.2. Address Prefix Extension Processing For each address prefix advertised on an autoconfigurable interface, the host updates the list of addresses as follows: 1. If the prefix advertised matches the prefix of an address already in the list, then set the lifetime to infinity. 2. If the prefix advertised does not match the prefix of an address already in the list, then form an inter-link scope address using this network prefix. Section 3 specifies how to form an inter- link scope address. Add this address to the list with an infinite lifetime. 3. All other autoconfigured inter-link addresses in the list have Expires July 31, 1995 [Page 10] INTERNET-DRAFT Address Configuration January 1995 their lifetimes set to zero. An inter-link scope address is valid for as long as the subnet prefix is advertised in the appropriate extension of a Router Advertisement. A lifetime of infinity is used in the above algorithm to indicate this. An address is deprecated when the subnet prefix is no longer advertised in the Address Prefix extension of the Router Advertise- ment, but the subnet prefix has not been explicitly invalidated by a Drop Address Prefix extension. An address is also deprecated when a new Router Advertisement is not heard before the old advertisement times out. A lifetime of zero is used in the above algorithm to indicate that the address has been deprecated. A deprecated address is likely to be routable, although it is not guaranteed to be. In the case where a subnet prefix that has been previously advertised is no longer advertised in a Router Advertise- ment (this assumes that a host is hearing Router Advertisements), a host should prepare for the time when the address becomes invalid: a host should stop using the address as a source address in communica- tions, if other addresses are available, and should stop advertising the address to others in DNS. Also, it should refuse to accept new connections to this address. However, the address may still be used to accept incoming datagrams and to avoid breaking existing connec- tions. When an address becomes deprecated because no Router Adver- tisements are heard (because the router is down, for example), the host may still continue to use the address as normal until the next Router Advertisement is heard. Note that the 'M' bit of an address prefix extension may indicate to the host that it must use DHCPv6 to acquire other IPv6 configuration parameters (besides the address). 4.2.3. Drop Address Prefix Extension Processing For each address prefix advertised, the host updates the list of addresses as follows: 1. If the prefix advertised matches the prefix of an address already in the list, then remove address from list. Expires July 31, 1995 [Page 11] INTERNET-DRAFT Address Configuration January 1995 When an address is invalidated, it should no longer be used at all in communications since the subnet prefix is no longer routable. 5. TRANSITION IMPLICATIONS IPv4-compatible IPv6 addresses are required by IPv6 hosts for the following purposes in the SIT scheme[IPv6-TRANS]: 1) to communicate off a link when an IPv6 neighboring router is not present on the link and 2) to communicate with IPv4-only hosts. In order that dual IPv4/IPv6 hosts can communicate using IPv6 without the presence of an IPv6 neighboring router, such a host should be able to form an IPv4-compatible IPv6 address autonomously. This is done by concatenating the well-defined IPv4-compatibility prefix to the host's IPv4 address. (It is not defined here how the host gets an IPv4 address; the IPv4 address may have been manually configured or autoconfigured using BOOTP, DHCP[RFC1531],etc). An IPv4-compatible IPv6 address should be formed on an interface if no Router Advertise- ment is heard within a reasonable timeframe. On hearing an IPv6 Router Advertisement, however, the host must carry out the IPv6 address autoconfiguration procedure as normal. In the case where the router advertises subnet prefixes for autoconfigura- tion purposes, it is possible to tell from the value of the subnet prefix advertised what form of address is to be used. The subnet prefix advertised may contain the IPv4-compatibility prefix in which case the IPv4-compatible form of the address is used. Otherwise, an IPv6-only address must be formed to replace any IPv4-compatible address previously formed as described in Section 3. 6. SECURITY CONSIDERATIONS To be completed. Expires July 31, 1995 [Page 12] INTERNET-DRAFT Address Configuration January 1995 7. APPENDIX - UNIQUENESS OF HOST TOKENS One of the basic assumptions of the autoconfiguration schemes out- lined in this memo is that the host token is at least unique per link. The only feasible choice for the token is the link layer address in most cases. In practice, two hosts on the same link may have the same link layer address because of an assignment error, in which case the resulting IPv6 addresses will not be unique. There is no automatic detection of such occurrences. The use of DNS to regis- ter name to address mappings may help system administrators detect when such a problem occurs since two different hosts will register the same IPv6 address. The above problem may occur in any particular network topology. One particular scenario deserves further mention though. Consider a topology consisting of two links with singly-homed hosts attached to each, a multi-homed host attached to both and no router. In this case, because no router is present, hosts will form intra-link addresses only on all interfaces. It is imperative that hosts have interface tokens that are unique across both links, which is not true if a host token is defined to be a link layer address and the address is only defined to be unique per link as is true in some cases. Strictly speaking, we require that host tokens are globally unique to ensure correct operation in these topologies. In practice, link layer addresses are frequently globally unique and so the uniqueness problems in this scenario should not be appreciably worse than in more traditional topologies as described above. If two intra-link scope addresses are detected to be the same in this scenario, there are two solutions: one is to make the multihomed host a router, the other is to manually configure the intra-link scope address of an offending host. Expires July 31, 1995 [Page 13] INTERNET-DRAFT Address Configuration January 1995 8. REFERENCES [RFC1531] R. Droms, "Dynamic Host Configuration Protocol", RFC 1531, Buck- nell University, October 1993. [IPv6-TRANS] Robert E. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", Internet Draft, November 1994, [IPv6-SPEC] R. Hinden, "Internet Protocol Version 6 (IPv6) Specification", Internet Draft, February 1994, [IPv6-ROAD] [IPv6-ICMP] A. Conta and S. Deering, "ICMP and IGMP for IPv6", Internet Draft, September 1994, [IPv6-DISC-FORM] W. A. Simpson, "IPv6 Neighbor Discovery -- ICMP Message For- mats", Internet Draft, November 1994, [IPv6-DISC-PROC] W. A. Simpson, "IPv6 Neighbor Discovery -- Processing", Internet Draft, November 1994, [IPv6-DHCP] J. Bound, Y. Rekhter and S. Thomson, Internet Draft in progress. Acknowledgements The author would like to thank the members of both the IPNG and ADDRCONF working groups for their input. Expires July 31, 1995 [Page 14] INTERNET-DRAFT Address Configuration January 1995 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 July 31, 1995 [Page 15]