idnits 2.17.1 draft-iab-ip-config-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 893. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 904. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 911. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 917. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-cheshire-dnsext-dns-sd-04 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3530 (Obsoleted by RFC 7530) -- Obsolete informational reference (is this intentional?): RFC 3720 (Obsoleted by RFC 7143) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Aboba 3 INTERNET-DRAFT D. Thaler 4 Category: Informational Microsoft Corporation 5 Expires: January 3, 2009 Loa Andersson 6 3 July 2008 Acreo AB 7 Internet Architecture Board 9 Principles of Internet Host Configuration 10 draft-iab-ip-config-05.txt 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 3, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document describes principles of Internet host configuration. 42 It covers issues relating to configuration of Internet layer 43 parameters, as well as parameters affecting higher layer protocols. 45 Table of Contents 47 1. Introduction.............................................. 3 48 1.1 Terminology ........................................ 3 49 1.2 Internet Host Configuration ........................ 4 50 2. Principles ............................................... 6 51 2.1 Minimize Configuration ............................. 6 52 2.2 Less is More ....................................... 6 53 2.3 Minimize Diversity ................................. 7 54 2.4 Lower Layer Independence ........................... 8 55 2.5 Configuration is Not Access Control ................ 10 56 3. Additional Discussion .................................... 10 57 3.1 Reliance on General Purpose Mechanisms ............. 10 58 3.2 Relationship between IP Configuration and 59 Service Discovery .................................. 11 60 4. Security Considerations .................................. 14 61 4.1 Configuration Authentication ....................... 14 62 5. IANA Considerations ...................................... 15 63 6. References ............................................... 15 64 6.1 Informative References ............................. 16 65 Acknowledgments .............................................. 19 66 Appendix A - IAB Members ..................................... 19 67 Authors' Addresses ........................................... 19 68 Full Copyright Statement ..................................... 20 69 Intellectual Property ........................................ 20 70 1. Introduction 72 This document describes principles of Internet host [STD3] 73 configuration. It covers issues relating to configuration of 74 Internet layer parameters, as well as parameters affecting higher 75 layer protocols. 77 In recent years, a number of architectural questions have arisen, for 78 which we provide guidance to protocol developers: 80 o What protocol layers and general approaches are most appropriate 81 for configuration of various parameters. 83 o The relationship between parameter configuration and service 84 discovery. 86 o The relationship between network access authentication and host 87 configuration. 89 o The role of link-layer protocols and tunneling protocols 90 in Internet host configuration. 92 The role of the link-layer and tunneling protocols is particularly 93 important, since it can affect the properties of a link as seen by 94 higher layers (for example, whether privacy extensions specified in 95 "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" 96 [RFC4941] are available to applications). 98 1.1. Terminology 100 link A communication facility or medium over which nodes can 101 communicate at the link-layer, i.e., the layer immediately 102 below IP. Examples are Ethernets (simple or bridged), PPP 103 links, X.25, Frame Relay, or ATM networks as well as 104 Internet (or higher) layer "tunnels", such as tunnels over 105 IPv4 or IPv6 itself. 107 on link An address that is assigned to an interface on a specified 108 link. 110 off link The opposite of "on link"; an address that is not assigned 111 to any interfaces on the specified link. 113 mobility agent 114 Either a home agent or a foreign agent. 116 1.2. Internet Host Configuration 118 Internet layer configuration is defined as the configuration required 119 to support the operation of the Internet layer. This includes IP 120 address(es), subnet prefix(es), default gateway(s), mobility 121 agent(s), boot service configuration and other parameters: 123 IP address(es) 124 Internet Protocol (IP) address configuration includes both 125 configuration of link-scope addresses as well as global 126 addresses. Configuration of IP addresses is an important 127 step, since this enables a host to fill in the source 128 address in the packets it sends, as well as to receive 129 packets destined to that address. As a result, the host 130 can receive unicast IP packets, rather than requiring that 131 IP packets be sent to the broadcast or multicast address. 132 Configuration of an IP address also enables the use of IP 133 fragmentation. Packets sent from the unknown address 134 cannot be reliably reassembled, since fragments from 135 multiple hosts using the unknown address might be 136 reassembled into a single IP packet. Configuration of an 137 IP address also enables use of Internet layer security 138 facilities such as IPsec specified in "Security 139 Architecture for the Internet Protocol" [RFC4301]. 141 Subnet prefix(es) 142 Once a subnet prefix is configured, hosts with an IP 143 address can exchange unicast IP packets directly with on- 144 link hosts within the same subnet prefix. 146 Default gateway(s) 147 Once a default gateway is configured, hosts with an IP 148 address can send unicast IP packets from off-link hosts, 149 assuming unobstructed connectivity. 151 Mobility agent(s) 152 While Mobile IPv4 [RFC3344] and Mobile IPv6 [RFC3775] 153 include their own mechanisms for locating home agents, it 154 is also possible for mobile nodes to utilize dynamic home 155 agent configuration. 157 Other parameters 158 Internet layer parameter configuration also includes 159 configuration of per-host parameters (e.g. hostname) and 160 per-interface parameters (e.g. IP Time-To-Live (TTL) to 161 use in outgoing packets, enabling/disabling of IP 162 forwarding and source routing, and Maximum Transmission 163 Unit (MTU)). 165 Boot service configuration 166 Boot service configuration is defined as the configuration 167 necessary for a host to obtain and perhaps also to verify 168 an appropriate boot image. This is appropriate for disk- 169 less hosts looking to obtain a boot image via mechanisms 170 such as the Trivial File Transfer Protocol (TFTP) 171 [RFC1350], Network File System (NFS) [RFC3530] and 172 Internet Small Computer Systems Interface (iSCSI) 173 [RFC3720][RFC4173]. It also may be useful in situations 174 where it is necessary to update the boot image of a host 175 that supports a disk, such as in the Preboot eXecution 176 Environment (PXE) [PXE][RFC4578]. While strictly speaking 177 boot services operate above the Internet layer, where boot 178 service is used to obtain the Internet layer code, it may 179 be considered part of Internet layer configuration. 181 Higher-layer configuration is defined as the configuration required 182 to support the operation of other components above the Internet 183 layer. This includes, for example: 185 Name Service Configuration 186 The configuration required for the host to resolve names. 187 This includes configuration of the addresses of name 188 resolution servers, including IEN 116, Domain Name Service 189 (DNS), Windows Internet Name Service (WINS), Internet 190 Storage Name Service (iSNS) and Network Information 191 Service (NIS) servers, and the setting of name resolution 192 parameters such as the NetBIOS node type, the DNS domain 193 and search list, etc. It may also include the 194 transmission or setting of the host's own name. Note that 195 link local name resolution services (such as NetBIOS 196 [RFC1001], Link-Local Multicast Name Resolution (LLMNR) 197 [RFC4795] and multicast DNS (mDNS) [mDNS]) typically do 198 not require configuration. 200 Once the host has completed name service configuration, it 201 is capable of resolving names using name resolution 202 protocols that require configuration. This not only 203 allows the host to communicate with off-link hosts whose 204 IP address is not known, but to the extent that name 205 services requiring configuration are utilized for service 206 discovery, this also enables the host to discover services 207 available on the network or elsewhere. 209 Time Service Configuration 210 Time service configuration includes configuration of 211 servers for protocols such as the Simple Network Time 212 Protocol (SNTP) and the Network Time Protocol (NTP). 214 Since accurate determination of the time may be important 215 to operation of the applications running on the host 216 (including security services), configuration of time 217 servers may be a prerequisite for higher layer operation. 218 However, it is typically not a requirement for Internet 219 layer configuration. 221 Other service configuration 222 This can include discovery of additional servers and 223 devices, such as printers, Session Initiation Protocol 224 (SIP) proxies, etc. 226 2. Principles 228 This section describes basic principles of Internet host 229 configuration. 231 2.1. Minimize Configuration 233 Anything that can be configured can be misconfigured. "Architectural 234 Principles of the Internet" [RFC1958] Section 3.8 states: "Avoid 235 options and parameters whenever possible. Any options and parameters 236 should be configured or negotiated dynamically rather than manually." 238 That is, to minimize the possibility of configuration errors, 239 parameters should be automatically computed (or at least have 240 reasonable defaults) whenever possible. For example, the Path 241 Maximum Transmission Unit (PMTU) can be discovered, as described in 242 "Packetization Layer Path MTU Discovery" [RFC4821], "TCP Problems 243 with Path MTU Discovery" [RFC2923], "Path MTU discovery" [RFC1191] 244 and "Path MTU Discovery for IP version 6" [RFC1981]. 246 Some protocols support self-configuration mechanisms, such as 247 capability negotiation or discovery of other hosts that implement the 248 same protocol. 250 2.2. Less is More 252 The availability of standardized, simple mechanisms for general- 253 purpose Internet host configuration is highly desirable. RFC 1958 254 [RFC1958] states, "Performance and cost must be considered as well as 255 functionality" and "Keep it simple. When in doubt during design, 256 choose the simplest solution." 258 To allow protocol support in more types of devices, it is important 259 to minimize the footprint requirement. For example, Internet hosts 260 span a wide range of devices, from embedded devices operating with 261 minimal footprint to supercomputers. Since the resources (e.g. 263 memory and code size) available for host configuration may be very 264 small, it is desirable for a host to be able to configure itself in 265 as simple a manner as possible. 267 One interesting example is IP support in pre-boot execution 268 environments. Since by definition boot configuration is required in 269 hosts that have not yet fully booted, it is often necessary for pre- 270 boot code to be executed from Read Only Memory (ROM), with minimal 271 available memory. In the Pre-boot Execution Environment (PXE), prior 272 to obtaining a boot image, the host is typically only able to 273 communicate using IP and the User Datagram Protocol (UDP). This is 274 one reason why Internet layer configuration mechanisms typically 275 depend only on IP and UDP. After obtaining the boot image, the host 276 will have the full facilities of TCP/IP available to it, including 277 support for reliable transport protocols, IPsec, etc. 279 In order to reduce complexity, it is desirable for Internet layer 280 configuration mechanisms to avoid dependencies on higher layers. 281 Since embedded hosts may wish to minimize the code included within a 282 boot Read-Only Memory (ROM), availability of higher layer facilities 283 cannot be guaranteed during Internet layer configuration. In fact, 284 it cannot even be guaranteed that all Internet layer facilities will 285 be available. For example, IP fragmentation and reassembly may not 286 work reliably until a host has obtained an IP address. 288 2.3. Minimize Diversity 290 The number of host configuration mechanisms should be minimized. 291 Diversity in Internet host configuration mechanisms presents several 292 problems: 294 Interoperability As configuration diversity increases, it becomes 295 likely that a host will not support the 296 configuration mechanism(s) available on the 297 network to which it has attached, creating 298 interoperability problems. 300 Footprint In order to interoperate, hosts need to implement 301 all configuration mechanisms used on the link 302 layers they support. This increases the required 303 footprint, a burden for embedded devices. 305 Redundancy To support diversity in host configuration 306 mechanisms, operators would need to support 307 multiple configuration services to ensure that 308 hosts connecting to their networks could configure 309 themselves. This represents an additional expense 310 for little benefit. 312 Latency As configuration diversity increases, hosts 313 supporting multiple configuration mechanisms may 314 spend increasing effort to determine which 315 mechanism(s) are supported. This adds to 316 configuration latency. 318 Conflicts Whenever multiple mechanisms are available, it is 319 possible that multiple configuration(s) will be 320 returned. To handle this, hosts would need to 321 merge potentially conflicting configurations. 322 This would require conflict resolution logic, such 323 as ranking of potential configuration sources, 324 increasing implementation complexity. 326 Additional traffic To limit configuration latency, hosts may 327 simultaneously attempt to obtain configuration by 328 multiple mechanisms. This can result in 329 increasing on-the-wire traffic, both from use of 330 multiple mechanisms as well as from 331 retransmissions within configuration mechanisms 332 not implemented on the network. 334 Security Support for multiple configuration mechanisms 335 increases the attack surface without any potential 336 benefit. 338 2.4. Lower Layer Independence 340 RFC 1958 [RFC1958] states, "Modularity is good. If you can keep 341 things separate, do so." 343 It is becoming increasingly common for hosts to support multiple 344 network access mechanisms, including dialup, wireless and wired local 345 area networks, wireless metropolitan and wide area networks, etc. 346 The proliferation of network access mechanisms makes it desirable for 347 hosts to be able to configure themselves on multiple networks without 348 adding configuration code specific to a new link layer. 350 As a result, it is highly desirable for Internet host configuration 351 mechanisms to be independent of the underlying lower layer. That is, 352 the link layer protocol (whether it be a physical link, or a virtual 353 tunnel link) should only be explicitly aware of link-layer parameters 354 (although it may configure link-layer parameters). Introduction of 355 lower layer dependencies increases the likelihood of interoperability 356 problems and adds to the number of Internet layer configuration 357 mechanisms that hosts need to implement. 359 Lower layer dependencies can be best avoided by keeping Internet host 360 configuration above the link layer, thereby enabling configuration to 361 be handled for any link layer that supports IP. In order to provide 362 media independence, Internet host configuration mechanisms should be 363 link-layer protocol independent. 365 While there are examples of IP address assignment within the link 366 layer (such as in the Point-to-Point Protocol (PPP) IPv4CP [RFC1332] 367 and "Mobile radio interface Layer 3 specification; Core network 368 protocols; Stage 3 (Release 5)" [3GPP-24.008]), the disadvantages of 369 this approach have now become apparent. This includes the extra 370 complexity of implementing different mechanisms on different link 371 layers, and the difficulty in adding new parameters which would 372 require defining a mechanism in each link layer protocol. 374 For example, PPP IPv4CP and "Internet Protocol Control Protocol 375 (IPCP) Extensions for Name Service Configuration" [RFC1877] were 376 developed at a time when the Dynamic Host Configuration Protocol 377 (DHCP) [RFC2131] had not yet been widely implemented on access 378 devices or in service provider networks. However, in IPv6 where link 379 layer independent mechanisms such as "IPv6 Stateless Address 380 Autoconfiguration" [RFC4862] and DHCPv6 [RFC3736] are available, PPP 381 IPv6CP [RFC5072] instead simply configures an Interface-Identifier 382 which is similar to a MAC address. This enables PPP IPv6CP to avoid 383 duplicating DHCPv6 functionality. 385 In contrast, Internet Key Exchange Version 2 (IKEv2) [RFC4306] 386 utilizes the same approach as PPP IPv4CP by defining a Configuration 387 Payload for Internet host configuration for both IPv4 and IPv6. As 388 pointed out in "Dynamic Host Configuration Protocol (DHCPv4) 389 Configuration of IPsec Tunnel Mode" [RFC3456], leveraging DHCP has 390 advantages in terms of address management integration, address pool 391 management, reconfiguration and fail-over. On the other hand, the 392 IKEv2 approach reduces the number of exchanges. 394 Extensions to link layer protocols for the purpose of Internet, 395 transport or application layer configuration (including server 396 configuration) should be avoided. Such extensions can negatively 397 affect the properties of a link as seen by higher layers. For 398 example, if a link layer protocol (or tunneling protocol) configures 399 individual IPv6 addresses and precludes using any other addresses, 400 then applications that desire "Privacy Extensions for Stateless 401 Address Autoconfiguration in IPv6" [RFC4941] may not function well. 402 Similar issues may arise for other types of addresses, such as 403 Cryptographically Generated Addresses [RFC3972]. 405 Avoiding lower layer dependencies is desirable even where the lower 406 layer is link independent. For example, while the Extensible 407 Authentication Protocol (EAP) [RFC3748] may be run over any link 408 satisfying the requirements of [RFC3748] Section 3.1, many link 409 layers do not support EAP and therefore Internet layer configuration 410 mechanisms with EAP dependencies would not be usable on all links 411 that support IP. 413 2.5. Configuration is Not Access Control 415 Network access authentication and authorization is a distinct problem 416 from Internet host configuration. Therefore network access 417 authentication and authorization is best handled independently of the 418 Internet and higher layer configuration mechanisms. 420 Having an Internet (or higher) layer protocol authenticate clients is 421 appropriate to prevent resource exhaustion of a scarce resource on 422 the server (such as IP addresses or prefixes), but not for preventing 423 hosts from obtaining access to a link. If the user can manually 424 configure the host, requiring authentication in order to obtain 425 configuration parameters (such as an IP address) has little value. 426 Note that client authentication is not required for Stateless DHCPv6 427 [RFC3736] since it does not result in allocation of any limited 428 resources on the server. 430 3. Additional Discussion 432 3.1. Reliance on General Purpose Mechanisms 434 Protocols should either be self-configuring (especially where fate 435 sharing is important), or use general-purpose configuration 436 mechanisms (such as DHCP or a service discovery protocol, as noted in 437 Section 3.2). The choice should be made taking into account the 438 architectural principles discussed in Section 2. 440 Taking into account the availability of existing general-purpose 441 configuration mechanisms, there is no apparent need for the 442 development of additional general-purpose configuration mechanisms. 444 When defining a new host parameter, protocol designers should first 445 consider whether configuration is indeed necessary (see Section 2.1). 446 If configuration is necessary, in addition to considering fate 447 sharing (see Section 3.3), protocol designers should consider: 449 1. The organizational implications for administrators. For 450 example, routers and servers are often administered by 451 different sets of individuals, so that configuring a router 452 with server parameters may require cross-group collaboration. 454 2. Whether the parameter is a per-interface or a per-host 455 parameter. For example, configuration protocols 456 such as DHCP run on a per-interface basis and hence 457 are more appropriate for per-interface parameters. 459 3.2. Relationship between IP Configuration and Service Discovery 461 Higher-layer configuration often includes configuring server 462 addresses. The question arises as to how this differs from "service 463 discovery" as provided by Service Discovery protocols such as the 464 Service Location Protocol Version 2 (SLPv2) [RFC2608] or Domain Name 465 Service Service Discovery (DNS-SD) [DNS-SD]. 467 In Internet host configuration mechanisms such as DHCP, if multiple 468 server instances are provided, they are considered equivalent. In 469 service discovery protocols, on the other hand, a host desires to 470 find a server satisfying a particular set of criteria, which may vary 471 by request. 473 Service discovery protocols can support discovery of servers on the 474 Internet, not just those within the local administrative domain. For 475 example, see "Remote Service Discovery in the Service Location 476 Protocol (SLP) via DNS SRV" [RFC3832] and [DNS-SD]. Internet host 477 configuration mechanisms such as DHCP, on the other hand, typically 478 assume the server(s) in the local administrative domain contain the 479 authoritative set of information. 481 For the service discovery problem (i.e., where the criteria varies on 482 a per-request basis, even from the same host), protocols should 483 either be self-discovering (if fate sharing is critical), or use 484 general purpose service discovery mechanisms. 486 In order to avoid a dependency on multicast routing, it is necessary 487 for a host to either restrict discovery to services on the local link 488 or to discover the location of a Directory Agent (DA). Since the DA 489 may not be available on the local link, service discovery beyond the 490 local link is typically dependent on a mechanism for configuring the 491 DA address or name. As a result, service discovery protocols can 492 typically not be relied upon for obtaining basic Internet layer 493 configuration, although they can be used to obtain higher-layer 494 configuration parameters. 496 3.2.1. Fate Sharing 498 If a server (or set of servers) is needed to get a set of 499 configuration parameters, "fate sharing" ([RFC1958] Section 2.3) is 500 preserved if the servers are ones without which the parameters could 501 not be used, even if they were obtained via other means. The 502 possibility of incorrect information being configured is minimized if 503 there is only one machine which is authoritative for the information 504 (i.e., there is no need to keep multiple authoritative servers in 505 sync). For example, learning default gateways via Router 506 Advertisements provides perfect fate sharing. That is, gateway 507 addresses can be obtained if and only if they can actually be used. 508 Similarly, obtaining DNS server configuration from a DNS server would 509 provide fate sharing since the configuration would only be obtainable 510 if the DNS server were available. 512 While fate sharing is a desirable property of a configuration 513 mechanism, in a number of situations fate sharing may be unavailable. 514 When utilized to discover services on the local link, service 515 discovery protocols typically provide for fate sharing, since hosts 516 providing service information typically also provide the services. 517 However, this is no longer the case when service discovery is 518 assisted by a Directory Agent (DA). First of all, the DA's list of 519 operational servers may not be current, so that it is possible for 520 the DA to provide clients with service information that is out of 521 date. For example, a DA's response to a client's service discovery 522 query may contain stale information about servers that are no longer 523 operational. Similarly, recently introduced servers might not yet 524 have registered themselves with the DA. Furthermore, the use of a DA 525 for service discovery also introduces a dependency on whether the DA 526 is operational, even though the DA is typically not involved in the 527 delivery of the service. 529 Similar limitations exist for other server-based configuration 530 mechanisms such as DHCP. Typically DHCP servers do not check for the 531 liveness of the configuration information they provide, or do not 532 discover new configuration information automatically. As a result, 533 there is no guarantee that configuration information will be current. 535 "IPv6 Host configuration of DNS Server Information Approaches" 536 [RFC4339] Section 3.3 discusses the use of well-known anycast 537 addresses for discovery of DNS servers. The use of anycast addresses 538 enables fate sharing, even where the anycast address is provided by 539 an unrelated server. However, in order to be universally useful, 540 this approach would require allocation of one or more well-known 541 anycast addresses for each service. Configuration of more than one 542 anycast address is desirable to allow the client to fail over faster 543 than would be possible from routing protocol convergence. 545 3.2.2. Discovering Names vs. Addresses 547 In discovering servers other than name resolution servers, it is 548 possible to either discover the IP addresses of the server(s), or to 549 discover names, each of which may resolve to a list of addresses. 551 It is typically more efficient to obtain the list of addresses 552 directly, since this avoids the extra name resolution steps and 553 accompanying latency. On the other hand, where servers are mobile, 554 the name to address binding may change, requiring a fresh set of 555 addresses to be obtained. Where the configuration mechanism does not 556 support fate sharing (e.g. DHCP), providing a name rather than an 557 address can simplify operations, assuming that the server's new 558 address is manually or automatically updated in the DNS; in this case 559 there is no need to re-do parameter configuration, since the name is 560 still valid. Where fate sharing is supported (e.g. service discovery 561 protocols), a fresh address can be obtained by re-initiating 562 parameter configuration. 564 In providing the IP addresses for a set of servers, it is desirable 565 to distinguish which IP addresses belong to which servers. If a 566 server IP address is unreachable, this enables the host to try the IP 567 address of another server, rather than another IP address of the same 568 server, in case the server is down. This can be enabled by 569 distinguishing which addresses belong to the same server. 571 3.2.3. Dual Stack Issues 573 One use for learning a list of server addresses is to enable a host 574 to try them sequentially until one succeeds. In such cases, it is 575 best for the list to be ordered so that subsequent entries are most 576 likely to succeed, assuming that attempts to connect to previous 577 addresses have failed. For hosts that support both IPv4 and IPv6, it 578 is desirable to obtain both IPv4 and IPv6 server addresses within a 579 single list. Obtaining IPv4 and IPv6 addresses in separate lists, 580 without indicating which server(s) they correspond to, requires the 581 host to use a heuristic to merge the lists. 583 For example, assume there are two servers, A and B, each with one 584 IPv4 address and one IPv6 address. If the first address the host 585 should try is (say) the IPv6 address of server A, then the second 586 address the host should try, if the first one fails, would generally 587 be the IPv4 address of server B. This is because the failure of the 588 first address could either be due to server A being down, or due to 589 some problem with the host's IPv6 address. Trying the IPv4 address 590 next is preferred since the reachability of the IPv4 address is 591 independent of both potential failure causes. 593 If the list of IPv4 server addresses were obtained separate from the 594 list of IPv6 server addresses, a host trying to merge the lists would 595 not know which IPv4 addresses belonged to the same server as the IPv6 596 address it just tried. This can be solved either by explicitly 597 distinguishing which addresses belong to which server or, more 598 simply, by configuring the host with a combined list of both IPv4 and 599 IPv6 addresses. Note that the same issue can arise with any 600 mechanism (e.g. DHCP, DNS, etc.) for obtaining server IP addresses. 602 Configuring a combined list of both IPv4 and IPv6 addresses also 603 provides for more predictable ordering of addresses, as compared with 604 configuring a name and allowing the host resolver to determine the 605 address list ordering. See [RFC4477] for more discussion of dual- 606 stack issues in the context of DHCP. 608 4. Security Considerations 610 Secure IP configuration presents a number of challenges. In addition 611 to denial-of-service and man-in-the-middle attacks, attacks on 612 configuration mechanisms may target particular parameters. For 613 example, attackers may target DNS server configuration in order to 614 support subsequent phishing or pharming attacks. A number of issues 615 exist with various classes of parameters, as discussed in Section 616 2.6, "IPv6 Neighbor Discovery (ND) Trust Models and Threats" 617 [RFC3756] Section 4.2.7, "Authentication for DHCP Messages" [RFC3118] 618 Section 1.1, and "Dynamic Host Configuration Protocol for IPv6 619 (DHCPv6)" [RFC3315] Section 23. Given the potential vulnerabilities 620 resulting from implementation of these options, it is currently 621 common for hosts to restrict support for DHCP options to the minimum 622 set required to provide basic TCP/IP configuration. 624 Since boot configuration determines the boot image to be run by the 625 host, a successful attack on boot configuration could result in an 626 attacker gaining complete control over a host. As a result, it is 627 particularly important that boot configuration be secured. 628 Approaches to boot configuration security are described in 629 "Bootstrapping Clients using the Internet Small Computer System 630 Interface (iSCSI) Protocol" [RFC4173] and "Preboot Execution 631 Environment (PXE) Specification" [PXE]. 633 4.1. Configuration Authentication 635 The techniques available for securing Internet layer configuration 636 are limited, since transmission layer security protocols such as 637 IPsec [RFC4301] or Transport Layer Security (TLS) [RFC4346] cannot be 638 used until an IP address has been configured. As a result, 639 configuration security is typically implemented within the 640 configuration protocols themselves. 642 PPP [RFC1661] does not support secure negotiation within IPv4CP 643 [RFC1332] or IPv6CP [RFC5072], enabling an attacker with access to 644 the link to subvert the negotiation. In contrast, IKEv2 [RFC4306] 645 provides encryption, integrity and replay protection for 646 configuration exchanges. 648 In situations where link layer security is provided, and the Network 649 Access Server (NAS) acts as a DHCP relay or server, protection can be 650 provided against rogue DHCP servers, provided that the NAS filters 651 incoming DHCP packets from unauthorized sources. However, explicit 652 dependencies on lower layer security mechanisms are limited by the 653 "lower layer independence" principle (see Section 2.4). 655 Internet layer secure configuration mechanisms include SEcure 656 Neighbor Discovery (SEND) [RFC3971] for IPv6 stateless address 657 autoconfiguration [RFC4862], or DHCP authentication for stateful 658 address configuration. DHCPv4 [RFC2131] initially did not include 659 support for security; this was added in "Authentication for DHCP 660 Messages" [RFC3118]. DHCPv6 [RFC3315] included security support. 661 However, DHCP authentication is not widely implemented for either 662 DHCPv4 or DHCPv6. 664 Higher layer configuration can make use of a wider range of security 665 techniques. When DHCP authentication is supported, higher-layer 666 configuration parameters provided by DHCP can be secured. However, 667 even if a host does not support DHCPv6 authentication, higher-layer 668 configuration via Stateless DHCPv6 [RFC3736] can still be secured 669 with IPsec. 671 Possible exceptions can exist where security facilities are not 672 available until later in the boot process. It may be difficult to 673 secure boot configuration even once the Internet layer has been 674 configured, if security functionality is not available until after 675 boot configuration has been completed. For example, it is possible 676 that Kerberos, IPsec or TLS will not be available until later in the 677 boot process; see "Bootstrapping Clients using the Internet Small 678 Computer System Interface (iSCSI) Protocol" [RFC4173] for discussion. 680 Where public key cryptography is used to authenticate and integrity 681 protect configuration, hosts need to be configured with trust anchors 682 in order to validate received configuration messages. For a node 683 that visits multiple administrative domains, acquiring the required 684 trust anchors may be difficult. This is left as an area for future 685 work. 687 5. IANA Considerations 689 This document has no actions for IANA. 691 6. References 692 6.1. Informative References 694 [3GPP-24.008] 695 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 696 specification; Core network protocols; Stage 3 (Release 5)", 697 June 2003. 699 [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service Discovery", 700 Internet-Draft (work in progress), draft-cheshire-dnsext-dns- 701 sd-04.txt, August 2006. 703 [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", June 2005. 704 http://files.multicastdns.org/draft-cheshire-dnsext- 705 multicastdns.txt 707 [PXE] Henry, M. and M. Johnston, "Preboot Execution Environment 708 (PXE) Specification", September 1999, 709 http://www.pix.net/software/pxeboot/archive/pxespec.pdf 711 [RFC1001] NetBIOS Working Group in the Defense Advanced Research 712 Projects Agency, Internet Activities Board, and End-to-End 713 Services Task Force, "Protocol standard for a NetBIOS service 714 on a TCP/UDP transport: Concepts and methods", STD 19, RFC 715 1001, March 1987. 717 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 718 November 1990. 720 [RFC1332] McGregor, G., "PPP Internet Control Protocol", RFC 1332, 721 Merit, May 1992. 723 [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 724 1350, July 1992. 726 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 727 1661, July 1994. 729 [RFC1877] Cobb, S., "PPP Internet Protocol Control Protocol Extensions 730 for Name Server Addresses", RFC 1877, December 1995. 732 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 733 1958, June 1996. 735 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for 736 IP version 6", RFC 1981, August 1996. 738 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 739 March 1997. 741 [RFC2608] Guttman, E., et al., "Service Location Protocol, Version 2", 742 RFC 2608, June 1999. 744 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, 745 September 2000. 747 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 748 RFC 3118, June 2001. 750 [RFC3315] Droms, R., Ed., Bound, J., Volz,, B., Lemon, T., Perkins, C. 751 and M. Carney, "Dynamic Host Configuration Protocol for IPv6 752 (DHCPv6)", RFC 3315, July 2003. 754 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 755 2002. 757 [RFC3456] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host 758 Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel 759 Mode", RFC 3456, January 2003. 761 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, 762 C., Eisler, M. and D. Noveck, "Network File System (NFS) 763 version 4 Protocol", RFC 3530, April 2003. 765 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C. Chadalapaka, M. and E. 766 Zeidner, "Internet Small Computer Systems Interface (iSCSI)", 767 RFC 3720, April 2004. 769 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 770 (DHCP) Service for IPv6", RFC 3736, April 2004. 772 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 773 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 774 3748, June 2004. 776 [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 777 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 779 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 780 IPv6", RFC 3775, June 2004. 782 [RFC3832] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C. and W. 783 Jerome, "Remote Service Discovery in the Service Location 784 Protocol (SLP) via DNS SRV", RFC 3832, July 2004. 786 [RFC3971] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. 787 Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 788 2005. 790 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 791 3972, March 2005. 793 [RFC4173] Sarkar, P., Missimer, D. and C. Sapuntzakis, "Bootstrapping 794 Clients using the iSCSI Protocol", RFC 4173, September 2005. 796 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet 797 Protocol", RFC 4301, December 2005. 799 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 800 4306, December 2005. 802 [RFC4339] Jeong, J., "IPv6 Host Configuration of DNS Server Information 803 Approaches", RFC 4339, February 2006. 805 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 806 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 808 [RFC4477] Chown, T., Venaas, S. and C. Strauf, "Dynamic Host 809 Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack 810 Issues", RFC 4477, May 2006. 812 [RFC4578] Johnston, M. and S. Venaas, "Dynamic Host Configuration 813 Protocol (DHCP) Options for the Intel Preboot eXecution 814 Environment (PXE)", RFC 4578, November 2006. 816 [RFC4795] Aboba, B., Thaler, D. and L. Esibov, "Link-Local Multicast 817 Name Resolution (LLMNR)", RFC 4795, January 2007. 819 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 820 Discovery", RFC 4821, March 2007. 822 [RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless Address 823 Autoconfiguration", RFC 4862, September 2007. 825 [RFC4941] Narten, T., Draves, R. and S. Krishnan, "Privacy Extensions 826 for Stateless Address Autoconfiguration in IPv6", RFC 4941, 827 September 2007. 829 [RFC5072] Varada, S., Haskins D. and E. Allen, "IP Version 6 over PPP", 830 RFC 5072, September 2007. 832 [STD3] Braden, R., "Requirements for Internet Hosts -- Communication 833 Layers", STD 3, RFC 1122, and "Requirements for Internet Hosts 834 -- Application and Support", STD 3, RFC 1123, October 1989. 836 Acknowledgments 838 Bob Hinden, Pasi Eronen, Jari Arkko, Pekka Savola and James Kempf 839 provided valuable input on this document. 841 Appendix A - IAB Members at the time of this writing 843 Loa Andersson 844 Leslie Daigle 845 Elwyn Davies 846 Kevin Fall 847 Olaf Kolkman 848 Barry Leiba 849 Kurtis Lindqvist 850 Danny McPherson 851 David Oran 852 Eric Rescorla 853 Dave Thaler 854 Lixia Zhang 856 Authors' Addresses 858 Bernard Aboba 859 Microsoft Corporation 860 One Microsoft Way 861 Redmond, WA 98052 863 EMail: bernarda@microsoft.com 864 Phone: +1 425 706 6605 865 Fax: +1 425 936 7329 867 Dave Thaler 868 Microsoft Corporation 869 One Microsoft Way 870 Redmond, WA 98052 872 EMail: dthaler@microsoft.com 874 Loa Andersson 875 Acreo AB 877 EMail: loa@pi.se 879 Full Copyright Statement 881 Copyright (C) The IETF Trust (2008). 883 This document is subject to the rights, licenses and restrictions 884 contained in BCP 78, and except as set forth therein, the authors 885 retain all their rights. 887 This document and the information contained herein are provided on an 888 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 889 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 890 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 891 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 892 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 893 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 895 Intellectual Property 897 The IETF takes no position regarding the validity or scope of any 898 Intellectual Property Rights or other rights that might be claimed to 899 pertain to the implementation or use of the technology described in 900 this document or the extent to which any license under such rights 901 might or might not be available; nor does it represent that it has 902 made any independent effort to identify any such rights. Information 903 on the procedures with respect to rights in RFC documents can be 904 found in BCP 78 and BCP 79. 906 Copies of IPR disclosures made to the IETF Secretariat and any 907 assurances of licenses to be made available, or the result of an 908 attempt made to obtain a general license or permission for the use of 909 such proprietary rights by implementers or users of this 910 specification can be obtained from the IETF on-line IPR repository at 911 http://www.ietf.org/ipr. 913 The IETF invites any interested party to bring to its attention any 914 copyrights, patents or patent applications, or other proprietary 915 rights that may cover technology that may be required to implement 916 this standard. Please address the information to the IETF at 917 ietf-ipr@ietf.org. 919 Acknowledgment 921 Funding for the RFC Editor function is currently provided by the 922 Internet Society.