idnits 2.17.1 draft-ietf-addrconf-ipv6-auto-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 197 has weird spacing: '...ssigned addre...' == Line 376 has weird spacing: '...ed what form ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 31, 1995) is 10671 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IPv6-SPEC' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'IPv6-ROAD' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'IPv6-ICMP' is defined on line 436, but no explicit reference was found in the text == Unused Reference: 'IPv6-DISC-FORM' is defined on line 440, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1531 (Obsoleted by RFC 1541) -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-TRANS' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-SPEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-ROAD' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-ICMP' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-DISC-FORM' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-DISC-PROC' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-DHCP' Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ADDRCONF Working Group Susan Thomson (Bellcore) 3 INTERNET-DRAFT January 31, 1995 4 6 IPv6 Address Autoconfiguration 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a "working 19 draft" or "work in progress." 21 To learn the current status of any Internet Draft. please check the 22 1id-abstracts.txt listing contained in the Internet Drafts Shadow 23 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com or 24 munnari.oz.au. 26 Abstract 28 This document specifies how a host autoconfigures one or more 29 addresses per interface. A host can form an intra-link scope address 30 autonomously based on information local to the host. A host can form 31 an inter-link scope address in two ways: either semi-autonomously, 32 based on knowledge of subnet prefixes advertised by routers, or by 33 using DHCPv6. All mechanisms rely on a host having a token per 34 interface that is unique at least per subnet. This document 35 specifies how a host forms an intra-link scope address autonomously 36 and an inter-link scope address semi-autonomously using IEEE 802 37 tokens to identify each interface. DHCPv6 is described elsewhere. 39 1. INTRODUCTION 41 An IPv6 host can autoconfigure two types of address: 43 1. an intra-link scope address, 45 2. an inter-link scope address. 47 An intra-link scope address is autoconfigurable in the absence of a 48 router. An inter-link scope address is autoconfigurable only when a 49 router is present on the link. 51 There is only one way to form an intra-link scope address. On ini- 52 tialization of an interface, a host forms an IPv6 intra-link scope 53 address by concatenating a predefined intra-link scope prefix to a 54 token that is unique per link. Typically, the definition of the 55 token is link-layer dependent. In the case of a host attached to an 56 IEEE 802 network, for example, the token is the IEEE 802 address of 57 the interface. 59 There are two ways to form an inter-link scope address. In the first 60 mechanism, a host forms an IPv6 inter-link scope address by con- 61 catenating a network prefix advertised in a Router 62 Advertisement[IPv6-DISC-PROC,IPv6-DISC-PROC] to a token that is 63 unique per link. The other mechanism available to hosts is to use the 64 IPv6 version of the Dynamic Host Configuration Protocol 65 (DHCPv6)[IPv6-DHCP]. The choice of protocol to use is advertised by 66 the router, and this choice is configurable by the system administra- 67 tor. 69 The first mechanism for forming an inter-link scope address is suit- 70 able for environments where no administrative control is desired. It 71 is a simple, efficient protocol designed for a very specific purpose: 72 to make stateless address configuration very straightforward to use 73 and implement. DHCPv6 is a more complex protocol allowing for very 74 flexible address assignment under the control of a system administra- 75 tor. This protocol typically requires significant system management, 76 including server and database configuration. 78 This document describes the general host address autoconfiguration 79 procedure in Section 2, and how a host forms an intra-link scope 80 address and an inter-link scope address without using DHCPv6 in Sec- 81 tions 3 and 4, respectively. The DHCPv6 protocol is specified else- 82 where [IPv6-DHCP]. The scope of the document is limited to hosts 83 attached to IEEE 802 networks. The effect of the transition scheme on 84 the address autoconfiguration procedure is discussed in Section 5. 86 2. PROCEDURE FOR FORMING AND MAINTAINING ADDRESSES 88 A host maintains a list of addresses per interface. At a minimum, the 89 list includes the intra-link scope address, which the host can form 90 autonomously whenever an interface is initialised. If a router is 91 attached to the link, the list will also include inter-link scope 92 addresses formed either from subnet prefixes advertised in router 93 advertisements or by making requests to DHCPv6. Inter-link scope 94 addresses may also be manually configured. 96 2.1. Host Configuration 98 A host must maintain a list of the following configurable variables 99 per interface: 101 Address 103 A valid IPv6 unicast address for this interface 105 Default: None 107 LifeTime: 109 The length of time for which an address is valid in seconds. 111 Default: Infinity 113 An intra-link scope address and all manually configured addresses 114 have their lifetimes set to infinity. 116 A host may also allow the following variable to be configured by a 117 system administrator per interface: 119 Perform_Auto_Address 121 If TRUE, the host must perform address autoconfiguration process- 122 ing. Otherwise, the host performs no address autoconfiguration 123 processing at all. 125 Default: TRUE 127 2.2. Router Configuration 129 A router must be configurable by a system administrator so that the 130 choice of mechanism used for host configuration of inter-link scope 131 addresses can be controlled. Thus, a router must allow the following 132 variable to be configured by a system administrator per interface: 134 Perform_Auto_Address 136 If and only if TRUE, the router must send an Address Prefix exten- 137 sion in every Router Advertisement. 139 Default: TRUE 141 All router interfaces advertising a given subnet prefix on a link 142 must be configured to advertise the same address autoconfiguration 143 mode to hosts. 145 2.3. Host Address Autoconfiguration Procedure 147 A host must perform the following procedure for each interface when 148 booting or whenever an interface needs to be initialised: 150 When a host boots or at any time when a host has no address for an 151 autoconfigurable interface, e.g. when an interface is enabled 152 after being disabled, the host forms an address of intra-link 153 scope and adds it to the list of addresses. Section 3 specifies 154 how a host forms an intra-link scope address. 156 The host must send a Router Solicitation so that inter-link scope 157 addresses can be formed (or verified) as soon as possible. 159 When a solicited or unsolicited Router Advertisement is received over 160 an interface, the host must perform the following address configura- 161 tion processing: 163 If an Address Prefix extension exists, the host forms or verifies 164 its inter-link addresses autonomously as specified in Section 4. 166 Otherwise, the implication is that the host must use DHCPv6 for 167 address autoconfiguration. If no address exists on the interface, 168 the host must initiate a request to a DHCPv6 server to acquire a 169 new address. (Verification and renewal of existing addresses is 170 performed at DHCPv6-specified times.) If DHCPv6 fails for any rea- 171 son, the host falls back to using an intra-link scope address or a 172 manually configured inter-link scope address until a DHCPv6 server 173 request is successful. 175 Note that the above procedure should continue to operate when a sys- 176 tem administrator decides to change the autoconfiguration mode from 177 the autonomous mode (the host forms the address) to DHCPv6, and vice 178 versa. The requirement during a changeover is that the system 179 administrator must ensure that a DHCPv6 server is configured to hand 180 out addresses that are unique per subnet, particularly with respect 181 to addresses that hosts configure autonomously. To avoid problems 182 during a changeover, it is recommended that a DHCP server should use 183 exactly the same algorithm to form a host address as that used in the 184 autonomous mode, particularly when the subnet prefix used is the 185 same. Otherwise, further precautionary measures will need to be 186 taken to ensure correct operation. 188 To support the changeover from autonomous mode to DHCPv6 mode, DHCPv6 189 should provide the ability for a host to specify in a request previ- 190 ously configured inter-link addresses. A DHCPv6 server can then 191 validate, deprecate or forbid the use of the autonomously formed 192 addresses. 194 Changing from DHCPv6 mode to autonomous mode is somewhat tricky. 195 Normal autonomous mode processing should support the changeover from 196 DHCPv6 mode to autonomous mode assuming the above recommendation is 197 followed. DHCPv6-assigned addresses can be validated or deprecated 198 as a normal part of host processing when an Address Prefix extension 199 is heard in a Router Advertisement. The Drop Address Prefix can be 200 used to invalidate DHCPv6 addresses, if desired. 202 3. FORMING AN IEEE 802 IPv6 ADDRESS 204 A host forms an IEEE 802 IPv6 address for an interface by concatenat- 205 ing an 80-bit subnet prefix with the 48-bit IEEE 802 address of the 206 interface as follows: 208 | 80 bits | 48 bits | 209 +---------------------------------------+------------------------+ 210 | subnet prefix | IEEE 802 address | 211 +----------------------------------------------------------------+ 213 In the case of an intra-link scope prefix, the subnet prefix is 214 well-defined (TBD). 216 In the case of an inter-link scope prefix, the subnet prefix is con- 217 figurable (typically in a router). 219 4. FORMING INTER-LINK SCOPE IPv6 ADDRESSES AUTONOMOUSLY 221 4.1. Router Operation 223 4.1.1. Sending Router Advertisements with Address Extensions 225 A router may be configured to advertise address configuration infor- 226 mation in extensions of Router Advertisements. Two extensions are 227 defined for address configuration: the Address Prefix extension which 228 advertises valid subnet prefixes to enable hosts to form their own 229 addresses autonomously, and the Drop Address Prefix Extension which 230 indicates that a subnet prefix (and hence an address formed from such 231 a subnet prefix) is unrouteable. 233 ED'S NOTE: I have used two new extensions here for illustrative 234 purposes. It is likely the case that the Address Prefix Extension 235 and the Drop Prefix Extension can be supported using the Routing 236 Information Extensions and Change Prefix extensions defined in 237 neighbor discovery, respectively. The details of combining the 238 semantics of the existing extensions with that of the following 239 extensions still need to be worked out. 241 4.1.2. Address Prefix Extension Format 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Extension | Length | Reserved |M| Prefix Size | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Subnet Prefix | 247 | | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Extension TBD 252 Length 18 254 Reserved Must be zero 256 M When set, indicates more IPv6 parameters to 257 configure besides address. 259 Use DHCPv6 to acquire these parameters. 261 Prefix Size Length of subnet prefix in bits. 263 Subnet Prefix Valid subnet prefix for this link. 265 This extension is found in Router Advertisements. 267 4.1.3. Drop Address Prefix Extension Format 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Extension | Length | Reserved | Prefix Size | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Subnet Prefix | 273 | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Extension TBD 278 Length 18 279 Reserved Must be zero 281 Prefix Size Length of subnet prefix in bits. 283 Subnet Prefix Subnet prefix for this link to be invalidated. 285 This extension is found in Router Advertisements. 287 4.2. Host Operation 289 4.2.1. Processing Router Advertisements with Address Extensions 291 On hearing a Router Advertisement on an interface, a host checks for 292 an Address Prefix extension and a Drop Address Prefix extension. A 293 host processes an Address Prefix extension as described in Section 294 4.2.2 below and a Drop Address Prefix extension as in Section 4.2.3. 296 4.2.2. Address Prefix Extension Processing 298 For each address prefix advertised on an autoconfigurable interface, 299 the host updates the list of addresses as follows: 301 1. If the prefix advertised matches the prefix of an address 302 already in the list, then set the lifetime to infinity. 304 2. If the prefix advertised does not match the prefix of an address 305 already in the list, then form an inter-link scope address using 306 this network prefix. Section 3 specifies how to form an inter- 307 link scope address. 309 Add this address to the list with an infinite lifetime. 311 3. All other autoconfigured inter-link addresses in the list have 312 their lifetimes set to zero. 314 An inter-link scope address is valid for as long as the subnet prefix 315 is advertised in the appropriate extension of a Router Advertisement. 316 A lifetime of infinity is used in the above algorithm to indicate 317 this. An address is deprecated when the subnet prefix is no longer 318 advertised in the Address Prefix extension of the Router Advertise- 319 ment, but the subnet prefix has not been explicitly invalidated by a 320 Drop Address Prefix extension. An address is also deprecated when a 321 new Router Advertisement is not heard before the old advertisement 322 times out. A lifetime of zero is used in the above algorithm to 323 indicate that the address has been deprecated. 325 A deprecated address is likely to be routable, although it is not 326 guaranteed to be. In the case where a subnet prefix that has been 327 previously advertised is no longer advertised in a Router Advertise- 328 ment (this assumes that a host is hearing Router Advertisements), a 329 host should prepare for the time when the address becomes invalid: a 330 host should stop using the address as a source address in communica- 331 tions, if other addresses are available, and should stop advertising 332 the address to others in DNS. Also, it should refuse to accept new 333 connections to this address. However, the address may still be used 334 to accept incoming datagrams and to avoid breaking existing connec- 335 tions. When an address becomes deprecated because no Router Adver- 336 tisements are heard (because the router is down, for example), the 337 host may still continue to use the address as normal until the next 338 Router Advertisement is heard. 340 Note that the 'M' bit of an address prefix extension may indicate to 341 the host that it must use DHCPv6 to acquire other IPv6 configuration 342 parameters (besides the address). 344 4.2.3. Drop Address Prefix Extension Processing 346 For each address prefix advertised, the host updates the list of 347 addresses as follows: 349 1. If the prefix advertised matches the prefix of an address 350 already in the list, then remove address from list. 352 When an address is invalidated, it should no longer be used at all in 353 communications since the subnet prefix is no longer routable. 355 5. TRANSITION IMPLICATIONS 357 IPv4-compatible IPv6 addresses are required by IPv6 hosts for the 358 following purposes in the SIT scheme[IPv6-TRANS]: 1) to communicate 359 off a link when an IPv6 neighboring router is not present on the link 360 and 2) to communicate with IPv4-only hosts. 362 In order that dual IPv4/IPv6 hosts can communicate using IPv6 without 363 the presence of an IPv6 neighboring router, such a host should be 364 able to form an IPv4-compatible IPv6 address autonomously. This is 365 done by concatenating the well-defined IPv4-compatibility prefix to 366 the host's IPv4 address. (It is not defined here how the host gets an 367 IPv4 address; the IPv4 address may have been manually configured or 368 autoconfigured using BOOTP, DHCP[RFC1531],etc). An IPv4-compatible 369 IPv6 address should be formed on an interface if no Router Advertise- 370 ment is heard within a reasonable timeframe. 372 On hearing an IPv6 Router Advertisement, however, the host must carry 373 out the IPv6 address autoconfiguration procedure as normal. In the 374 case where the router advertises subnet prefixes for autoconfigura- 375 tion purposes, it is possible to tell from the value of the subnet 376 prefix advertised what form of address is to be used. The subnet 377 prefix advertised may contain the IPv4-compatibility prefix in which 378 case the IPv4-compatible form of the address is used. Otherwise, an 379 IPv6-only address must be formed to replace any IPv4-compatible 380 address previously formed as described in Section 3. 382 6. SECURITY CONSIDERATIONS 384 To be completed. 386 7. APPENDIX - UNIQUENESS OF HOST TOKENS 388 One of the basic assumptions of the autoconfiguration schemes out- 389 lined in this memo is that the host token is at least unique per 390 link. The only feasible choice for the token is the link layer 391 address in most cases. In practice, two hosts on the same link may 392 have the same link layer address because of an assignment error, in 393 which case the resulting IPv6 addresses will not be unique. There is 394 no automatic detection of such occurrences. The use of DNS to regis- 395 ter name to address mappings may help system administrators detect 396 when such a problem occurs since two different hosts will register 397 the same IPv6 address. 399 The above problem may occur in any particular network topology. One 400 particular scenario deserves further mention though. Consider a 401 topology consisting of two links with singly-homed hosts attached to 402 each, a multi-homed host attached to both and no router. In this 403 case, because no router is present, hosts will form intra-link 404 addresses only on all interfaces. It is imperative that hosts have 405 interface tokens that are unique across both links, which is not true 406 if a host token is defined to be a link layer address and the address 407 is only defined to be unique per link as is true in some cases. 408 Strictly speaking, we require that host tokens are globally unique to 409 ensure correct operation in these topologies. In practice, link 410 layer addresses are frequently globally unique and so the uniqueness 411 problems in this scenario should not be appreciably worse than in 412 more traditional topologies as described above. If two intra-link 413 scope addresses are detected to be the same in this scenario, there 414 are two solutions: one is to make the multihomed host a router, the 415 other is to manually configure the intra-link scope address of an 416 offending host. 418 8. REFERENCES 420 [RFC1531] 421 R. Droms, "Dynamic Host Configuration Protocol", RFC 1531, Buck- 422 nell University, October 1993. 424 [IPv6-TRANS] 425 Robert E. Gilligan and E. Nordmark, "Transition Mechanisms for 426 IPv6 Hosts and Routers", Internet Draft, November 1994, 429 [IPv6-SPEC] 430 R. Hinden, "Internet Protocol Version 6 (IPv6) Specification", 431 Internet Draft, February 1994, 434 [IPv6-ROAD] 436 [IPv6-ICMP] 437 A. Conta and S. Deering, "ICMP and IGMP for IPv6", Internet 438 Draft, September 1994, 440 [IPv6-DISC-FORM] 441 W. A. Simpson, "IPv6 Neighbor Discovery -- ICMP Message For- 442 mats", Internet Draft, November 1994, 445 [IPv6-DISC-PROC] 446 W. A. Simpson, "IPv6 Neighbor Discovery -- Processing", Internet 447 Draft, November 1994, 449 [IPv6-DHCP] 450 J. Bound, Y. Rekhter and S. Thomson, Internet Draft in progress. 452 Acknowledgements 454 The author would like to thank the members of both the IPNG and ADDRCONF 455 working groups for their input. 457 Author's Addresses 459 Susan Thomson 460 Bellcore 461 445 South Street 462 Morristown, NJ 07960 463 U.S.A. 465 Phone: +1 201-829-4514 466 Email: set@thumper.bellcore.com