ADDRCONF Working Group Susan Thomson (Bellcore) INTERNET-DRAFT July 7, 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 This document specifies how a node configures a link-local address per interface, and how a host configures a list of global or site- local addresses per interface, without any manual configuration. Stateless address autoconfiguration is only one mechanism available to hosts; stateful address configuration is also available. While stateful address configuration is outside the scope of this document, it is specified how hosts determine which configuration method must be used. The document also specifies a protocol for detecting whether an address is a duplicate when it is initially configured. Expires January 7, 1995 [Page 1] INTERNET-DRAFT Stateless Address Configuration July 1995 1. INTRODUCTION In IPv6, a host has two mechanisms available to form a global or site-local address that require no manual configuration: the state- less method and the stateful method. In the stateless method, no external state is maintained for the purpose of indicating to a host the list of addresses to use for an interface. Rather, a host forms a list of addresses algorithmically by concatenating each of the net- work prefixes of the attached link to an interface token unique per link. The interface token is defined to be link-dependent and may be the hardware address, for example. In contrast, state is maintained in the stateful address configuration, typically in 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, e.g. plug- and-play environments. In contrast, 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, e.g. corporate networks. Any node can use stateless address autoconfiguration to form a link- local address per interface. A host can use either stateless or stateful autoconfiguration (or both) to configure global or site- local addresses for an interface. The choice of mechanism for confi- guring global or site-local addresses is itself configurable, and requires no manual configuration per host. One of the basic assumptions of stateless autoconfiguration is that the token used to form addresses per interface is at least unique per link. However, whatever the type of tokens used, interface tokens are not guaranteed to always be unique in practice because of errors in assignment. Thus, it is possible that IPv6 addresses formed using stateless autoconfiguration are not unique among all nodes on a link. Since duplicate IPv6 addresses are very difficult to track down when they occur, this document also specifies a procedure for detecting duplicate addresses. Note that the algorithm does not only apply to addresses autoconfigured using the stateless mode. It should be used to verify the uniqueness of any address, for example, addresses con- figured using the stateful mode or manually configured addresses. Expires January 7, 1995 [Page 2] INTERNET-DRAFT Stateless Address Configuration July 1995 This document describes how a node configures a link-local address per interface using stateless address autoconfiguration, and how a host configures global or site-local unicast addresses per interface using stateless address autoconfiguration. Stateful address autocon- figuration is outside the scope of this document. However, the docu- ment does specify how a host determines whether to use the stateless mechanism or the stateful mechanism for configuring global or site- local addresses. The document also describes the algorithm used by a node to detect if an address is a duplicate when initially configured. Expires January 7, 1995 [Page 3] INTERNET-DRAFT Stateless Address Configuration July 1995 2. TERMINOLOGY node - a device that implements IPv6. router - a node that forwards IPv6 packets not explicitly addressed to itself. host - any node that is not a router. upper layer - a protocol layer immediately above IPv6. Examples are transport protocols such as TCP and UDP, control protocols such as ICMP, routing protocols such as OSPF, and internet or lower-layer protocols being "tunneled" over (i.e., encapsulated in) IPv6 such as IPX, AppleTalk, or IPv6 itself. link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6. Examples are Ethernets (simple or bridged); PPP links; X.25, Frame Relay, or ATM networks; and internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. neighbors - nodes attached to the same link. interface - a node's attachment to a link. packet - an IPv6 header plus payload. link MTU - the maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed in one piece over a link. target - a node about which address resolution information is sought, or a node which is the new first-hop when being redirected. address - an IPv6-layer identifier for an interface or a set of interfaces. unicast address - an identifier for a single interface. A packet sent to a unicast address is delivered to the interface Expires January 7, 1995 [Page 4] INTERNET-DRAFT Stateless Address Configuration July 1995 identified by that address. anycast address - an identifier for a set of interfaces (typically belonging to different nodes). A packet sent to an anycast address is delivered to one of the interfaces identified by that address (the "nearest" one, according to the routing protocols' measure of distance). multicast address - an identifier for a set of interfaces (typically belonging to different nodes). A packet sent to a multicast address is delivered to all interfaces identified by that address. link-layer address - a link-layer identifier for an interface. Examples are IEEE 802 addresses for Ethernet links, E.164 addresses for ISDN links. link-local address - an address with a scope that is limited to the locally attached link. site-local address - an address with a scope that is limited to the local site. global address - an address with unlimited scope. communication - any packet exchange between nodes that requires or recommends that the address of each node used in the exchange remain the same for the duration of the packet exchange. Examples are a TCP connection or a UDP request-response. deprecation lifetime - indicates the time at which an address should no longer be used as a source address in new communications. The deprecation lifetime must be less than or equal to the invalidation lifetime Expires January 7, 1995 [Page 5] INTERNET-DRAFT Stateless Address Configuration July 1995 of the address. invalidation lifetime - indicates the time at which an address no longer identifies an interface or set of interfaces. The invalidation lifetime must be greater than or equal to the deprecation lifetime of the address. valid address - an address whose deprecation lifetime has not yet expired. deprecated address - an address whose deprecation lifetime has expired, but whose invalidation lifetime has not. invalid address - an address whose invalidation lifetime has expired. interface token - a link-dependent identifier for an interface that is (at least) unique per link. An example is an IEEE 802 address. 2.1. Requirements Throughout this document, the words that are used to define the sig- nificance of the particular requirements are capitalized. These words are: MUST This word or the adjective "REQUIRED" means that the item is an absolute requirement of this specification. MUST NOT This phrase means the item is an absolute prohibition of this specification. SHOULD Expires January 7, 1995 [Page 6] INTERNET-DRAFT Stateless Address Configuration July 1995 This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full impliciations should be understood and the case carefully weighed before choosing a different course. SHOULD NOT This phrase means that there may exist valid reasons in particu- lar circumstances when the listed behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighted before implementing any behavior described with this label. MAY This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example, another vendor may omit the same item. Expires January 7, 1995 [Page 7] INTERNET-DRAFT Stateless Address Configuration July 1995 3. CONCEPTUAL MODEL OF HOST BEHAVIOR Conceptually, a host maintains three data structures: a list of addresses per interface and two flags. One flag, called the "address mode" flag, indicates whether the stateful protocol is to be used for address configuration (possibly in addition to the stateless proto- col). The other flag, called the "other configuration mode" flag, indicates whether the stateful protocol is to be used for configura- tion of other information besides addresses. The address list always includes at least one address, the host's link-local address, which is an address that can only be used in com- munications between nodes attached to the link. In addition, the address list includes any global or site-local addresses that have been manually or automatically configured. Note that stateless address autoconfiguration applies only to the formation of unicast addresses. A node may, however, have anycast and multicast addresses associated with an interface. In particular, a host must join the all-nodes multicast address on any multicast interface, and the solicited-node multicast address corresponding to each unicast address on any multicast interface. 3.1. Address Configuration 3.1.1. Link-Local Address On initialization of an interface, a host must form a link-local address by concatenating a well-known link-local prefix[1] to an interface 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 the 48-bit IEEE 802 link-layer address of the interface. Tokens for a specific link are defined in link-specific IPv6 documents and are outside the scope of this document. Note that a host is able to autoconfigure a link-local address Expires January 7, 1995 [Page 8] INTERNET-DRAFT Stateless Address Configuration July 1995 completely autonomously. In particular, a host can form a link-local address without a router present on the link. 3.1.2. Global/Site-Local Address A host forms a new global/site-local address whenever a new prefix is advertised by a router and stateless address configuration is enabled. The address is formed by concatenating the network prefix to the interface token that is unique per link in the same way as a link-local address described above. The mechanism used to advertise network prefixes for the purposes of address configuration is the same as that used in Neighbor Discovery for the purposes of prefix discovery. A router advertises prefix information periodically and a host uses this information to config- ure and reconfigure addresses. 3.2. Address Reconfiguration One of the goals of IPv6 address autoconfiguration is not only to be able to autoconfigure a list of addresses on initialization of an interface, but to be able to change the address list dynamically. Note that the link-local address never changes (except possibly on interface re-initialization). Host addresses may need to change for a number of reasons. For example, if the address assignment scheme is provider-based, hosts may need to change addresses when hosts change provider. Hosts may also need to change addresses when they are disconnected from one link and connected to another. Reconfiguration must not only allow a host to acquire a new address, but must also allow hosts to time-out an old address. Current networking protocols have not been designed to maintain existing communications during an address change. For example, a TCP connection will no longer work if one of the hosts changes its address in the middle of a connection. Even in a UDP exchange, a host is expected to be able to identify itself using the same address for the length of the exchange. Expires January 7, 1995 [Page 9] INTERNET-DRAFT Stateless Address Configuration July 1995 To minimise disruption caused by an address change, an address is configured with two lifetimes : a deprecation lifetime and an invali- dation lifetime. The deprecation lifetime must be less than or equal to the invalidation lifetime. Before expiry of the deprecation life- time, the address is valid and may be used as the source and destina- tion in any communications. At and after expiry of the deprecation lifetime, but before the invalidation lifetime has expired, the address is considered to be deprecated. A deprecated address can still be used as the source and destination in packets legitimately, but the deprecated address should not be used as a source address in new communications if other valid addresses exist and these addresses have sufficient scope. If no valid addresses of sufficient scope exist, then the deprecated address should still be used. (Note that there will always be at least one valid address in the address list, the link-local address (see below), but this address is only useful for communications on the local link, and thus cannot be used in place of a deprecated address for non-local link communications). An address becomes invalid when the invalidation lifetime expires. Such an address must not be used as a source address in outgoing com- munications or accepted as a destination address in incoming communi- cations. An invalid address is removed from the address list of the interface. Note that the deprecation lifetimes and invalidation lifetimes of the link-local address are set to infinity. Thus, the link-local address is never deprecated. The intention of the two lifetimes per address is to allow system administrators to specify a graceful transition period during renumbering. The purpose of the deprecation time is to indicate to the host to start using another (presumably longer lasting) address in new communications to minimise the risk of breaking communications when the old one times out. A system administrator should set the deprecation period long enough so that most, if not all, communica- tions have switched over to using the new address by the time the old one becomes invalid. The length of the deprecation period will be environment-dependent as it depends on the expected length of commun- ications. The fact that addresses have a deprecation lifetime does not need to affect the implementation of applications, i.e. an application is not expected to react when an address it is using becomes deprecated. The purpose of the deprecation lifetime is to help applications or networking software to select a sufficiently long-lasting source Expires January 7, 1995 [Page 10] INTERNET-DRAFT Stateless Address Configuration July 1995 address at the beginning of a new communication. The IP layer is expected to provide a means for upper layers or applications to select the most appropriate source address given a particular desti- nation. An application may choose to select the source address itself before starting a new communication or may leave the address unspecified, in which case the upper networking layers will use the mechanism provided by the IP layer to choose a suitable address on the application's behalf. Expires January 7, 1995 [Page 11] INTERNET-DRAFT Stateless Address Configuration July 1995 4. ROUTER SPECIFICATION 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 option of a Router Advertisement. Prefix Information includes 1. the prefix itself 2. the prefix length 3. a flag indicating whether the prefix is to be used for prefix discovery[2]. 4. a flag indicating whether the prefix is to be used for stateless address autoconfiguration 5. the deprecation lifetime of the prefix in seconds for the pur- pose of address deprecation 6 the invalidation lifetime of the prefix for the purpose of address invalidation. This field is also used by prefix discovery[2]. Router Advertisement processing is specified completely in [2] along with the message formats and configuration variables. Expires January 7, 1995 [Page 12] INTERNET-DRAFT Stateless Address Configuration July 1995 5. HOST SPECIFICATION This section specifies host address autoconfiguration behavior on receiving a Router Advertisement. 5.1. Host Configuration Variables A host SHOULD allow the following variable to be configured per mul- ticast interface: Perform_Addr_Config If set, the host MUST use either stateless or stateful mechanisms to configure global or site-local addresses and to acquire other configuration information as specified in this document. Default: TRUE An interface that has the Perform_Addr_Config flag set is called an "autoconfigurable interface". 5.2. Message Validation A host MUST silently discard any Router Advertisement that does not specify the validity checks as specified in [2]. An advertisement that passes these validity checks is called a valid advertisement. 5.3. Router Advertisement Processing To receive a Router Advertisement, a host joins the all-nodes multi- cast address over all multicast-capable interfaces. Expires January 7, 1995 [Page 13] INTERNET-DRAFT Stateless Address Configuration July 1995 A host performs the following address configuration processing when a valid solicited or unsolicited Router Advertisement is received over an autoconfigurable interface: For each valid Router Advertisement: The host stores the current value of the Address Mode and then sets the Address Mode to the value of the Managed flag (M bit). If the new value is set, the host MUST use stateful address confi- guration to configure and maintain a list of site-local or global addresses per interface. Note that this does not mean that the stateful protocol is neces- sarily invoked each time a Router Advertisement arrives with the M bit set. The host uses the flag only to indicate whether the stateful protocol is to be used to configure addresses. The state- ful protocol is enabled as soon as the Address Mode changes from FALSE to TRUE. The protocol is disabled as soon as the flag changes from TRUE to FALSE. The actual times at which the proto- col is invoked, for example, to request a list of addresses or renew a list of addresses, are specified by the protocol itself. The host stores the current value of the Other Configuration flag and then sets the Other Configuration Mode flag to that in the Router Advertisement (O bit). If the new value is set, the host MUST use stateful autoconfiguration to acquire other configuration information besides the address. The above disclaimer applies here as well. The O bit indicates whether the host must use the stateful mode to acquire other con- figuration information. The stateful protocol is enabled for this purpose as soon as the Other Configuration Mode changes from FALSE to TRUE. The protocol is disabled as soon as the mode changes from TRUE to FALSE. The mode does not indicate the timing of frequency of acquiring that information. This is defined by the stateful protocol itself. For each Prefix-Information extension in the Router Advertisement that has the Autonomous flag set: - If the prefix advertised matches the prefix of an Expires January 7, 1995 [Page 14] INTERNET-DRAFT Stateless Address Configuration July 1995 autoconfigured address already in the list, then set the deprecation timer to that of the deprecation lifetime speci- fied in the extension and the invalidation timer to that of the invalidation lifetime. Note that this processing MUST NOT be applied to the link- local address. That is, if the well-known link-local prefix is advertised for some reason (probably a configuration error), then the prefix should be ignored and a system management error logged. - If the prefix advertised does not match the prefix of an address already in the list, then form an address using this network prefix and the interface token. Definitions of the interface token to be used on a specific link are documented elsewhere. If the prefix advertised is too short or too long to form a 128-bit address, given the interface token, the prefix is ignored and an error is logged. 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: The address list should be variable-length. Hosts should be able to store the link-local address as well as all addresses configured using both the stateless and stateful modes. If the implementation cannot store all addresses, the host should log a system management error. 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.) If the deprecation lifetime is infinity, the address is never deprecated. Similarly, if the invalidation lifetime is infinity, the address is never invali- dated. The value of infinity is defined in [2]. An address is valid until the deprecation timer expires. A valid address can be used as a source address in all outgoing Expires January 7, 1995 [Page 15] INTERNET-DRAFT Stateless Address Configuration July 1995 communications and is accepted as a destination address in all incoming communications. When the deprecation lifetime of an address expires, the address SHOULD continue to be used as a source address if it is in use in existing communications, but SHOULD NOT be used in new communica- tions if a valid address is available and it has sufficient scope. The IP layer MUST continue to accept datagrams destined to a deprecated address since a deprecated address is still defined to identify the interface. An address remains deprecated until its invalidation timer expires at which point the address becomes invalid and is removed from the address list. 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 since the address is defined to no longer identify the interface. On initialisation of an interface, if a host determines that there are no IPv6 routers on a link, a host MUST attempt to use stateful autoconfiguration to acquire addresses and other configuration information. This is needed to support networks with no IPv6 routers. The host determines 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]. 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 it is possible for hosts to get address information using both stateless and stateful protocols since both may be enabled at the same time. Even if only stateless address autocon- figuration mode is enabled, it is still possible for hosts to get information from multiple sources since multiple routers may be advertising prefix information. The rules for handling this is as follows: hosts accept the union of all information received using the stateless and stateful protocols. If different sources config- ure the same address, then the address is updated with the most recently advertised lifetime. It is also possible for hosts to contain address information from different sources, when changing from one mechanism to the other, i.e. when changing from stateless mode to stateful mode, and vice Expires January 7, 1995 [Page 16] INTERNET-DRAFT Stateless Address Configuration July 1995 versa. In this case, the rules are no different from above. If the newly enabled mode is configured to hand out different addresses than the mode just disabled, then the host contains the union of addresses from both sources until the addresses configured using the old protocol timeout. If both the old and new modes are con- figured to hand out the same address, then the address is updated with the most recently advertised lifetime. NOTE: The above assumes that the stateless and stateful modes have the same life- time semantics. Expires January 7, 1995 [Page 17] INTERNET-DRAFT Stateless Address Configuration July 1995 6. NODE SPECIFICATION This section specifies the rules for forming a link-local address. It also specifies the protocol to be used for duplicate address detec- tion. 6.1. Forming a Link-Local Address A node MUST have a link-local address. A node forms a link-local address whenever an interface is initialised. The method for forming a link-local address is link-dependent and is outside the scope of this document. An interface may be initialised or become autoconfigurable after any of the following events: - The interface is initialized at system startup time. - The interface is reinitialized after a temporary interface failure or after being temporarily disabled by system manage- ment. - The node is re-attached to a link after being detached for some time. The link-local address is highly likely to need to be one of the first events in the interface initialisation process. Clearly, it must be formed before any duplicate detection processing is performed for this address (Section 6.2). In hosts, a link-local address is also required before a sends out a Router Solicitation, assuming the node chooses to do this[2]. This is because a solicitation is only sent if an advertisement has not yet been heard (and hence no non- link local address can be formed), and the unspecified address cannot be used as a source address in a Router Solicitation. 6.2. Detecting Duplicate Addresses The procedure to detect a duplicate address MUST be enabled by default in nodes and SHOULD be used. Expires January 7, 1995 [Page 18] INTERNET-DRAFT Stateless Address Configuration July 1995 In principle, the duplicate address detection procedure is applied to each new address configured for an interface, whether it be manually configured or configured automatically using either the stateless or stateful mode. However, if the addresses belonging to an interface are formed using the same interface token (as is the case in state- less autoconfiguration and may be the case in other forms of confi- guration), then it is only necessary to check that one of the addresses is unique on the link. In the stateless mechanism, it is recommended that the link-local address be the address checked for two reasons. First, it makes the implementation simpler, since the link-local address is guaranteed to always exist in all nodes, whereas global and site-local addresses are not. Second, in hosts, there will be less delay in performing duplicate address detection. Address validation can be done as soon as a link-local address is formed (this can be done immediately on initialisation of an inter- face), whereas checking a global or site-local address involves wait- ing until a host hears a Router Advertisement containing address pre- fixes, and there is the possibility that no advertisement will be heard at all. The procedure for duplicate address detection uses Neighbor Solicita- tion and Advertisement messages specified in [2] to validate an address as specified below. Note that before carrying out this pro- cedure, a node joins the all-nodes multicast address. Also, this mechanism is not completely reliable, and so it is possible that duplicate addresses will still exist. If a duplicate address is discovered after carrying out this procedure, the node will need to be configured with a new token, or if this is not possible, the IPv6 addresses will need to be manually configured. 6.2.1. Soliciting Node Behavior An address is checked for uniqueness only once, when the address is initially configured. Once the address is configured, the node sends a Neighbor Solicita- tion 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 (as it will be ignored by the Expires January 7, 1995 [Page 19] INTERNET-DRAFT Stateless Address Configuration July 1995 destination node[2]). Loopback of the Neighbor Solicitation MUST NOT be disabled. NOTE: If the Neighbor Solicitation is the first message to be sent from an interface on interface initialisation, the node should delay a random amount of time between 0 and MAX_INITIALIZATION_DELAY seconds before sending the solicitation. This serves to alleviate congestion when many nodes 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 node is trying to solicit for the same address at the same time. (It is recommended that nodes include some unique value in the seed used to initialise their pseudo-random number gen- erators. Note that using only the node token as a unique value is not sufficient to avoid race conditions since the token cannot be relied upon to be unique. Although the randomization range is specified 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.) If after sending a solicitation, no Neighbor Advertisement is received from the target, the node SHOULD retransmit the solicitation at most every DUPL_ADDR_RETRANS_TIMER seconds until either an adver- tisement 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 in the time it takes to send and wait for MAX_DUPL_ADDR_RETRANS solicitations, it must disable that interface and log a system management error. If no such advertisement is received within the time specified, the address is considered to be valid. 6.2.2. Solicited Node Behavior A node is in the process of validating an address when a Neighbor Solicitation has been sent for the address and no Neighbor Advertise- ment advertising that address has been received in the time it takes to send out MAX_DUPL_ADDR_RETRANS solicitations and wait for an advertisement (DUPL_ADDR_IGNORE_TIMER seconds). A node must follow special rules when it receives a Neighbor Solici- tation for an address that it is in the process of validating. This Expires January 7, 1995 [Page 20] INTERNET-DRAFT Stateless Address Configuration July 1995 is done to help avoid the race condition where more than one node is attempting to validate the address at the same time, i.e. each node sends out a Neighbor Solicitation and waits to hear a Neighbor Adver- tisement for the address, but no node actually sends an advertisement since the address has not yet been validated. The special rules are as follows: When a node is in the process of validating an address and receives a Neighbor Solicitation for that address, it MUST NOT send any advertisement in response to a solici- tation for that address. Rather, the node silently discards the sol- icitation unless the source address is the unspecified address. In the latter case, the first such solicitation received is noted, but otherwise silently discarded (see NOTE below). Any subsequent such solicitations cause the node to disable the interface and log a sys- tem management error. NOTE: The above behavior is required because nodes send out Neighbor Solicitations for their own address with loopback enabled. Thus, a node will always receive at least one solicitation for its own address. However, there is no way for the node to determine, in gen- eral, whether the solicitation comes from itself or another node since the source of the packet is the unspecified address. Hence, the above rules specify that a duplicate address is detected only if the node receives more than one solicitation for the address. Once a node has validated its address, it responds to a Neighbor Sol- icitation with a Neighbor Advertisement as specified in [2]. 6.2.3. Constants MAX_INITIALIZATION_DELAY 3 seconds DUPL_ADDR_RETRANS_TIMER 3 seconds MAX_DUPL_ADDR_RETRANS 1 transmission Expires January 7, 1995 [Page 21] INTERNET-DRAFT Stateless Address Configuration July 1995 7. SECURITY CONSIDERATIONS To be completed. Expires January 7, 1995 [Page 22] INTERNET-DRAFT Stateless Address Configuration July 1995 8. 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, E. Nordmark and W. A. Simpson, "IPv6 Neighbor Discovery", Internet Draft, July 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 January 7, 1995 [Page 23] INTERNET-DRAFT Stateless Address Configuration July 1995 Expires January 7, 1995 [Page 24]