idnits 2.17.1 draft-iab-ip-config-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors 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-05 -- 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 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 12 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 Loa Andersson 5 Expires: September 5, 2009 Stuart Cheshire 6 23 February 2009 Internet Architecture Board 8 Principles of Internet Host Configuration 9 draft-iab-ip-config-11.txt 11 Status of This Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 27, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This document describes principles of Internet host configuration. 49 It covers issues relating to configuration of Internet layer 50 parameters, as well as parameters affecting higher layer protocols. 52 Table of Contents 54 1. Introduction.............................................. 3 55 1.1 Terminology ........................................ 3 56 1.2 Internet Host Configuration ........................ 4 57 2. Principles ............................................... 6 58 2.1 Minimize Configuration ............................. 7 59 2.2 Less is More ....................................... 7 60 2.3 Minimize Diversity ................................. 8 61 2.4 Lower Layer Independence ........................... 9 62 2.5 Configuration is Not Access Control ................ 11 63 3. Additional Discussion .................................... 11 64 3.1 Reliance on General Purpose Mechanisms ............. 11 65 3.2 Relationship between IP Configuration and 66 Service Discovery .................................. 12 67 3.3 Discovering Names vs. Addresses .................... 14 68 3.4 Dual Stack Issues .................................. 15 69 3.5 Relationship between Per-Interface and 70 Per-Host Configuration ............................. 16 71 4. Security Considerations .................................. 17 72 4.1 Configuration Authentication ....................... 17 73 5. IANA Considerations ...................................... 19 74 6. References ............................................... 19 75 6.1 Informative References ............................. 19 76 Acknowledgments .............................................. 23 77 Appendix A - IAB Members ..................................... 23 78 Authors' Addresses ........................................... 24 80 1. Introduction 82 This document describes principles of Internet host [STD3] 83 configuration. It covers issues relating to configuration of 84 Internet layer parameters, as well as parameters affecting higher 85 layer protocols. 87 In recent years, a number of architectural questions have arisen, for 88 which we provide guidance to protocol developers: 90 o What protocol layers and general approaches are most appropriate 91 for configuration of various parameters. 93 o The relationship between parameter configuration and 94 service discovery. 96 o The relationship between per-interface and per-host 97 configuration. 99 o The relationship between network access authentication and 100 host configuration. 102 o The desirability of supporting self-configuration of parameters 103 or avoiding parameter configuration altogether. 105 o The role of link-layer protocols and tunneling protocols 106 in Internet host configuration. 108 The role of the link-layer and tunneling protocols is particularly 109 important, since it can affect the properties of a link as seen by 110 higher layers (for example, whether privacy extensions [RFC4941] are 111 available to applications). 113 1.1. Terminology 115 link A communication facility or medium over which nodes can 116 communicate at the link-layer, i.e., the layer immediately 117 below IP. Examples are Ethernets (simple or bridged), PPP 118 links, X.25, Frame Relay, or ATM networks as well as 119 Internet (or higher) layer "tunnels", such as tunnels over 120 IPv4 or IPv6 itself. 122 on link An address that is assigned to an interface on a specified 123 link. 125 off link The opposite of "on link"; an address that is not assigned 126 to any interfaces on the specified link. 128 mobility agent 129 Either a home agent or a foreign agent [RFC3344][RFC3775]. 131 1.2. Internet Host Configuration 133 1.2.1. Internet Layer Configuration 135 Internet layer configuration is defined as the configuration required 136 to support the operation of the Internet layer. This includes 137 configuration of per-interface and per-host parameters, including IP 138 address(es), subnet prefix(es), default gateway(s), mobility 139 agent(s), boot service configuration and other parameters: 141 IP address(es) 142 Internet Protocol (IP) address configuration includes both 143 configuration of link-scope addresses as well as global 144 addresses. Configuration of IP addresses is a vital step, 145 since practically all of IP networking relies on the 146 assumption that hosts have IP address(es) associated with 147 (each of) their active network interface(s). Used as the 148 source address of an IP packet, these IP addresses 149 indicate the sender of the packet; used as the destination 150 address of a unicast IP packet, these IP addresses 151 indicate the intended receiver. 153 The only common example of IP-based protocols operating 154 without an IP address involves address configuration, such 155 as the use of DHCPv4 [RFC2131] to obtain an address. In 156 this case, by definition, DHCPv4 is operating before the 157 host has an IPv4 address, so the DHCP protocol designers 158 had the choice of either using IP without an IP address, 159 or not using IP at all. The benefits of making IPv4 self- 160 reliant, configuring itself using its own IPv4 packets, 161 instead of depending on some other protocol, outweighed 162 the drawbacks of having to use IP in this constrained 163 mode. Use of IP for purposes other than address 164 configuration can safely assume that the host will have 165 one or more IP addresses, which may be self-configured 166 link-local addresses [RFC3927][RFC4862], or other 167 addresses configured via DHCP or other means. 169 Subnet prefix(es) 170 Once a subnet prefix is configured on an interface, hosts 171 with an IP address can exchange unicast IP packets 172 directly with on-link hosts within the same subnet prefix. 174 Default gateway(s) 175 Once a default gateway is configured on an interface, 176 hosts with an IP address can send unicast IP packets to 177 that gateway for forwarding to off-link hosts. 179 Mobility agent(s) 180 While Mobile IPv4 [RFC3344] and Mobile IPv6 [RFC3775] 181 include their own mechanisms for locating home agents, it 182 is also possible for mobile nodes to utilize dynamic home 183 agent configuration. 185 Boot service configuration 186 Boot service configuration is defined as the configuration 187 necessary for a host to obtain and perhaps also to verify 188 an appropriate boot image. This is appropriate for disk- 189 less hosts looking to obtain a boot image via mechanisms 190 such as the Trivial File Transfer Protocol (TFTP) 191 [RFC1350], Network File System (NFS) [RFC3530] and 192 Internet Small Computer Systems Interface (iSCSI) 193 [RFC3720][RFC4173]. It also may be useful in situations 194 where it is necessary to update the boot image of a host 195 that supports a disk, such as in the Preboot eXecution 196 Environment (PXE) [PXE][RFC4578]. While strictly speaking 197 boot services operate above the Internet layer, where boot 198 service is used to obtain the Internet layer code, it may 199 be considered part of Internet layer configuration. While 200 boot service parameters may be provided on a per-interface 201 basis, loading and verification of a boot image affects 202 behavior of the host as a whole. 204 Other IP parameters 205 Internet layer parameter configuration also includes 206 configuration of per-host parameters (e.g. hostname) and 207 per-interface parameters (e.g. IP Time-To-Live (TTL) to 208 use in outgoing packets, enabling/disabling of IP 209 forwarding and source routing, and Maximum Transmission 210 Unit (MTU)). 212 1.2.2. Higher Layer Configuration 214 Higher layer configuration is defined as the configuration required 215 to support the operation of other components above the Internet 216 layer. This includes, for example: 218 Name Service Configuration 219 The configuration required for the host to resolve names. 220 This includes configuration of the addresses of name 221 resolution servers, including IEN 116 [IEN116], Domain 222 Name System (DNS), Windows Internet Name Service (WINS), 223 Internet Storage Name Service (iSNS) [RFC4171][RFC4174] 224 and Network Information Service (NIS) servers [RFC3898], 225 and the setting of name resolution parameters such as the 226 DNS domain and search list [RFC3397], the NetBIOS node 227 type, etc. It may also include the transmission or 228 setting of the host's own name. Note that link local name 229 resolution services (such as NetBIOS [RFC1001], Link-Local 230 Multicast Name Resolution (LLMNR) [RFC4795] and multicast 231 DNS (mDNS) [mDNS]) typically do not require configuration. 233 Once the host has completed name service configuration, it 234 is capable of resolving names using name resolution 235 protocols that require configuration. This not only 236 allows the host to communicate with off-link hosts whose 237 IP address is not known, but to the extent that name 238 services requiring configuration are utilized for service 239 discovery, this also enables the host to discover services 240 available on the network or elsewhere. While name service 241 parameters can be provided on a per-interface basis, their 242 configuration will typically affect behavior of the host 243 as a whole. 245 Time Service Configuration 246 Time service configuration includes configuration of 247 servers for protocols such as the Simple Network Time 248 Protocol (SNTP) and the Network Time Protocol (NTP). 249 Since accurate determination of the time may be important 250 to operation of the applications running on the host 251 (including security services), configuration of time 252 servers may be a prerequisite for higher layer operation. 253 However, it is typically not a requirement for Internet 254 layer configuration. While time service parameters can be 255 provided on a per-interface basis, their configuration 256 will typically affect behavior of the host as a whole. 258 Other service configuration 259 This can include discovery of additional servers and 260 devices, such as printers, Session Initiation Protocol 261 (SIP) proxies, etc. This configuration will typically 262 apply to the entire host. 264 2. Principles 266 This section describes basic principles of Internet host 267 configuration. 269 2.1. Minimize Configuration 271 Anything that can be configured can be misconfigured. "Architectural 272 Principles of the Internet" [RFC1958] Section 3.8 states: "Avoid 273 options and parameters whenever possible. Any options and parameters 274 should be configured or negotiated dynamically rather than manually." 276 That is, to minimize the possibility of configuration errors, 277 parameters should be automatically computed (or at least have 278 reasonable defaults) whenever possible. For example, the Path 279 Maximum Transmission Unit (PMTU) can be discovered, as described in 280 "Packetization Layer Path MTU Discovery" [RFC4821], "TCP Problems 281 with Path MTU Discovery" [RFC2923], "Path MTU discovery" [RFC1191] 282 and "Path MTU Discovery for IP version 6" [RFC1981]. 284 Having a protocol design with many configurable parameters increases 285 the possibilities for misconfiguration of those parameters, resulting 286 in failures or other sub-optimal operation. Eliminating or reducing 287 configurable parameters helps lessen this risk. Where configurable 288 parameters are necessary or desirable, protocols can reduce the risk 289 of human error by making these parameters self-configuring, such as 290 by using capability negotiation within the protocol, or by automated 291 discovery of other hosts that implement the same protocol. 293 2.2. Less is More 295 The availability of standardized, simple mechanisms for general- 296 purpose Internet host configuration is highly desirable. 297 "Architectural Principles of the Internet" [RFC1958] states, 298 "Performance and cost must be considered as well as functionality" 299 and "Keep it simple. When in doubt during design, choose the 300 simplest solution." 302 To allow protocol support in many types of devices, it is important 303 to minimize the footprint requirement. For example, IP-based 304 protocols are used on a wide range of devices, from supercomputers 305 to small low-cost devices running "embedded" operating systems. 306 Since the resources (e.g. memory and code size) available for host 307 configuration may be very small, it is desirable for a host to be 308 able to configure itself in as simple a manner as possible. 310 One interesting example is IP support in pre-boot execution 311 environments. Since by definition boot configuration is required in 312 hosts that have not yet fully booted, it is often necessary for pre- 313 boot code to be executed from Read Only Memory (ROM), with minimal 314 available memory. Many hosts do not have enough space in this ROM 315 for even a simple implementation of TCP, so in the Pre-boot Execution 316 Environment (PXE) the task of obtaining a boot image is performed 317 using the User Datagram Protocol over IP (UDP/IP) [RFC768] instead. 318 This is one reason why Internet layer configuration mechanisms 319 typically depend only on IP and UDP. After obtaining the boot image, 320 the host will have the full facilities of TCP/IP available to it, 321 including support for reliable transport protocols, IPsec, etc. 323 In order to reduce complexity, it is desirable for Internet layer 324 configuration mechanisms to avoid dependencies on higher layers. 325 Since embedded devices may be severely constrained on how much code 326 they can fit within their ROM, designing a configuration mechanism in 327 such a way that it requires the availability of higher layer 328 facilities may make that configuration mechanism unusable in such 329 devices. In fact, it cannot even be guaranteed that all Internet 330 layer facilities will be available. For example, the minimal version 331 of IP in a host's boot ROM may not implement IP fragmentation and 332 reassembly. 334 2.3. Minimize Diversity 336 The number of host configuration mechanisms should be minimized. 337 Diversity in Internet host configuration mechanisms presents several 338 problems: 340 Interoperability As configuration diversity increases, it becomes 341 likely that a host will not support the 342 configuration mechanism(s) available on the 343 network to which it has attached, creating 344 interoperability problems. 346 Footprint For maximum interoperability, a host would need to 347 implement all configuration mechanisms used on all 348 the link layers it supports. This increases the 349 required footprint, a burden for embedded devices. 350 It also leads to lower quality, since testing 351 resources (both formal testing, and real-world 352 operational use) are spread more thinly -- the 353 more different configuration mechanisms a device 354 supports, the less testing each one is likely to 355 undergo. 357 Redundancy To support diversity in host configuration 358 mechanisms, operators would need to support 359 multiple configuration services to ensure that 360 hosts connecting to their networks could configure 361 themselves. This represents an additional expense 362 for little benefit. 364 Latency As configuration diversity increases, hosts 365 supporting multiple configuration mechanisms may 366 spend increasing effort to determine which 367 mechanism(s) are supported. This adds to 368 configuration latency. 370 Conflicts Whenever multiple mechanisms are available, it is 371 possible that multiple configuration(s) will be 372 returned. To handle this, hosts would need to 373 merge potentially conflicting configurations. 374 This would require conflict resolution logic, such 375 as ranking of potential configuration sources, 376 increasing implementation complexity. 378 Additional traffic To limit configuration latency, hosts may 379 simultaneously attempt to obtain configuration by 380 multiple mechanisms. This can result in 381 increasing on-the-wire traffic, both from use of 382 multiple mechanisms as well as from 383 retransmissions within configuration mechanisms 384 not implemented on the network. 386 Security Support for multiple configuration mechanisms 387 increases the attack surface without any potential 388 benefit. 390 2.4. Lower Layer Independence 392 "Architectural Principles of the Internet" [RFC1958] states, 393 "Modularity is good. If you can keep things separate, do so." 395 It is becoming increasingly common for hosts to support multiple 396 network access mechanisms, including dialup, wireless and wired local 397 area networks, wireless metropolitan and wide area networks, etc. 398 The proliferation of network access mechanisms makes it desirable for 399 hosts to be able to configure themselves on multiple networks without 400 adding configuration code specific to each new link layer. 402 As a result, it is highly desirable for Internet host configuration 403 mechanisms to be independent of the underlying lower layer. That is, 404 only the link layer protocol (whether it be a physical link, or a 405 virtual tunnel link) should be explicitly aware of link-layer 406 parameters (although it may configure them). Introduction of lower 407 layer dependencies increases the likelihood of interoperability 408 problems and adds Internet layer configuration mechanisms that hosts 409 need to implement. 411 Lower layer dependencies can be best avoided by keeping Internet host 412 configuration above the link layer, thereby enabling configuration to 413 be handled for any link layer that supports IP. In order to provide 414 media independence, Internet host configuration mechanisms should be 415 link-layer protocol independent. 417 While there are examples of Internet layer configuration within the 418 link layer (such as in the Point-to-Point Protocol (PPP) IPv4CP 419 [RFC1332] and "Mobile radio interface Layer 3 specification; Core 420 network protocols; Stage 3 (Release 5)" [3GPP-24.008]), this approach 421 has disadvantages. These include the extra complexity of 422 implementing different mechanisms on different link layers, and the 423 difficulty in adding new higher-layer parameters which would require 424 defining a mechanism in each link layer protocol. 426 For example, "Internet Protocol Control Protocol (IPCP) Extensions 427 for Name Service Configuration" [RFC1877] was developed prior to the 428 definition of the DHCPINFORM message in "Dynamic Host Configuration 429 Protocol" [RFC2131]; at that time Dynamic Host Configuration Protocol 430 (DHCP) servers had not been widely implemented on access devices or 431 deployed in service provider networks. While the design of IPv4CP 432 was appropriate in 1992, it should not be taken as an example that 433 new link layer technologies should emulate. Indeed, in order to 434 "actively advance PPP's most useful extensions to full standard, 435 while defending against further enhancements of questionable value", 436 "IANA Considerations for the Point-to-Point Protocol (PPP)" [RFC3818] 437 changed the allocation of PPP protocol numbers (including IPv4CP 438 extensions) so as to no longer be "first come first served." 440 In IPv6 where link-layer-independent mechanisms such as stateless 441 autoconfiguration [RFC4862] and stateless DHCPv6 [RFC3736] are 442 available, PPP IPv6CP [RFC5072] configures an Interface-Identifier 443 which is similar to a MAC address. This enables PPP IPv6CP to avoid 444 duplicating DHCPv6 functionality. 446 However, Internet Key Exchange Version 2 (IKEv2) [RFC4306] utilizes 447 the same approach as PPP IPv4CP by defining a Configuration Payload 448 for Internet host configuration for both IPv4 and IPv6. While the 449 IKEv2 approach reduces the number of exchanges, "Dynamic Host 450 Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode" 451 [RFC3456] points out that leveraging DHCP has advantages in terms of 452 address management integration, address pool management, 453 reconfiguration and fail-over. 455 Extensions to link layer protocols for the purpose of Internet, 456 transport or application layer configuration (including server 457 configuration) should be avoided. Such extensions can negatively 458 affect the properties of a link as seen by higher layers. For 459 example, if a link layer protocol (or tunneling protocol) configures 460 individual IPv6 addresses and precludes using any other addresses, 461 then applications that want to use privacy extensions [RFC4941] may 462 not function well. Similar issues may arise for other types of 463 addresses, such as Cryptographically Generated Addresses [RFC3972]. 465 Avoiding lower layer dependencies is desirable even where the lower 466 layer is link independent. For example, while the Extensible 467 Authentication Protocol (EAP) may be run over any link satisfying its 468 requirements (see [RFC3748] Section 3.1), many link layers do not 469 support EAP and therefore Internet layer configuration mechanisms 470 with EAP dependencies would not be usable on links that support IP 471 but not EAP. 473 2.5. Configuration is Not Access Control 475 Network access authentication and authorization is a distinct problem 476 from Internet host configuration. Therefore network access 477 authentication and authorization is best handled independently of the 478 Internet and higher layer configuration mechanisms. 480 Having an Internet (or higher) layer protocol authenticate clients is 481 appropriate to prevent resource exhaustion of a scarce resource on 482 the server (such as IP addresses or prefixes), but not for preventing 483 hosts from obtaining access to a link. If the user can manually 484 configure the host, requiring authentication in order to obtain 485 configuration parameters (such as an IP address) has little value. 486 Network administrators who wish to control access to a link can 487 achieve this better using technologies like Port Based Network Access 488 Control [IEEE-802.1X]. Note that client authentication is not 489 required for Stateless DHCPv6 [RFC3736] since it does not result in 490 allocation of any limited resources on the server. 492 3. Additional Discussion 494 3.1. Reliance on General Purpose Mechanisms 496 Protocols should either be self-configuring (especially where fate 497 sharing is important), or use general-purpose configuration 498 mechanisms (such as DHCP or a service discovery protocol, as noted in 499 Section 3.2). The choice should be made taking into account the 500 architectural principles discussed in Section 2. 502 Taking into account the general-purpose configuration mechanisms 503 currently available, we see little need for development of additional 504 general-purpose configuration mechanisms. 506 When defining a new host parameter, protocol designers should first 507 consider whether configuration is indeed necessary (see Section 2.1). 509 If configuration is necessary, in addition to considering fate 510 sharing (see Section 3.2.1), protocol designers should consider: 512 1. The organizational implications for administrators. For 513 example, routers and servers are often administered by 514 different sets of individuals, so that configuring a router 515 with server parameters may require cross-group collaboration. 517 2. Whether the need is to configure a set of interchangeable 518 servers or to select a server satisfying a particular set 519 of criteria. See Section 3.2. 521 3. Whether IP address(es) should configured or name(s). 522 See Section 3.3. 524 4. If IP address(es) are configured, whether IPv4 and 525 IPv6 addresses should be configured simultaneously or 526 separately. See Section 3.4. 528 5. Whether the parameter is a per-interface or a per-host 529 parameter. For example, configuration protocols 530 such as DHCP run on a per-interface basis and hence 531 are more appropriate for per-interface parameters. 533 6. How per-interface configuration affects host-wide behavior. 534 For example, whether the host should select a subset 535 of the per-interface configurations, or whether the 536 configurations are to merged, and if so, how this is 537 done. See Section 3.5. 539 3.2. Relationship between IP Configuration and Service Discovery 541 Higher-layer configuration often includes configuring server 542 addresses. The question arises as to how this differs from "service 543 discovery" as provided by Service Discovery protocols such as the 544 Service Location Protocol Version 2 (SLPv2) [RFC2608] or DNS-Based 545 Service Discovery (DNS-SD) [DNS-SD]. 547 In Internet host configuration mechanisms such as DHCP, if multiple 548 server instances are provided, they are considered interchangeable. 549 For example, in a list of time servers, the servers are considered 550 interchangeable because they all provide the exact same service -- 551 telling you the current time. In a list of local caching DNS 552 servers, the servers are considered interchangeable because they all 553 should give you the same answer to any DNS query. In service 554 discovery protocols, on the other hand, a host desires to find a 555 server satisfying a particular set of criteria, which may vary by 556 request. When printing a document, it is not the case that any 557 printer will do. The speed, capabilities, and physical location of 558 the printer matter to the user. 560 Information learned via DHCP is typically learned once, at boot time, 561 and after that may be updated only infrequently (e.g. on DHCP lease 562 renewal), if at all. This makes it appropriate for information that 563 is relatively static and unchanging over these time intervals. Boot- 564 time discovery of server addresses is appropriate for service types 565 where there are a small number of interchangeable servers that are of 566 interest to a large number of clients. For example, listing time 567 servers in a DHCP packet is appropriate because an organization may 568 typically have only two or three time servers, and most hosts will be 569 able to make use of that service. Listing all the printers or file 570 servers at an organization is a lot less useful, because the list may 571 contain hundreds or thousands of entries, and on a given day a given 572 user may not use any of the printers in that list. 574 Service discovery protocols can support discovery of servers on the 575 Internet, not just those within the local administrative domain. For 576 example, see "Remote Service Discovery in the Service Location 577 Protocol (SLP) via DNS SRV" [RFC3832] and DNS-Based Service Discovery 578 [DNS-SD]. Internet host configuration mechanisms such as DHCP, on 579 the other hand, typically assume the server(s) in the local 580 administrative domain contain the authoritative set of information. 582 For the service discovery problem (i.e., where the criteria varies on 583 a per-request basis, even from the same host), protocols should 584 either be self-discovering (if fate sharing is critical), or use 585 general purpose service discovery mechanisms. 587 In order to avoid a dependency on multicast routing, it is necessary 588 for a host to either restrict discovery to services on the local link 589 or to discover the location of a Directory Agent (DA). Since the DA 590 may not be available on the local link, service discovery beyond the 591 local link is typically dependent on a mechanism for configuring the 592 DA address or name. As a result, service discovery protocols can 593 typically not be relied upon for obtaining basic Internet layer 594 configuration, although they can be used to obtain higher-layer 595 configuration parameters. 597 3.2.1. Fate Sharing 599 If a server (or set of servers) is needed to get a set of 600 configuration parameters, "fate sharing" ([RFC1958], Section 2.3) is 601 preserved if those parameters are ones that cannot be usefully used 602 without those servers being available. In this case, successfully 603 obtaining those parameters via other means has little benefit if they 604 cannot be used because the required servers are not available. The 605 possibility of incorrect information being configured is minimized if 606 there is only one machine which is authoritative for the information 607 (i.e., there is no need to keep multiple authoritative servers in 608 sync). For example, learning default gateways via Router 609 Advertisements provides perfect fate sharing. That is, gateway 610 addresses can be obtained if and only if they can actually be used. 611 Similarly, obtaining DNS server configuration from a DNS server would 612 provide fate sharing since the configuration would only be obtainable 613 if the DNS server were available. 615 While fate sharing is a desirable property of a configuration 616 mechanism, in a number of situations fate sharing may not be 617 possible. When utilized to discover services on the local link, 618 service discovery protocols typically provide for fate sharing, since 619 hosts providing service information typically also provide the 620 services. However, this is no longer the case when service discovery 621 is assisted by a Directory Agent (DA). First of all, the DA's list 622 of operational servers may not be current, so that it is possible for 623 the DA to provide clients with service information that is out of 624 date. For example, a DA's response to a client's service discovery 625 query may contain stale information about servers that are no longer 626 operational. Similarly, recently introduced servers might not yet 627 have registered themselves with the DA. Furthermore, the use of a DA 628 for service discovery also introduces a dependency on whether the DA 629 is operational, even though the DA is typically not involved in the 630 delivery of the service. 632 Similar limitations exist for other server-based configuration 633 mechanisms such as DHCP. Typically DHCP servers do not check for the 634 liveness of the configuration information they provide, or do not 635 discover new configuration information automatically. As a result, 636 there is no guarantee that configuration information will be current. 638 "IPv6 Host configuration of DNS Server Information Approaches" 639 [RFC4339] Section 3.3 discusses the use of well-known anycast 640 addresses for discovery of DNS servers. The use of anycast addresses 641 enables fate sharing, even where the anycast address is provided by 642 an unrelated server. However, in order to be universally useful, 643 this approach would require allocation of one or more well-known 644 anycast addresses for each service. Configuration of more than one 645 anycast address is desirable to allow the client to fail over faster 646 than would be possible from routing protocol convergence. 648 3.3. Discovering Names vs. Addresses 650 In discovering servers other than name resolution servers, it is 651 possible to either discover the IP addresses of the server(s), or to 652 discover names, each of which may resolve to a list of addresses. 654 It is typically more efficient to obtain the list of addresses 655 directly, since this avoids the extra name resolution steps and 656 accompanying latency. On the other hand, where servers are mobile, 657 the name to address binding may change, requiring a fresh set of 658 addresses to be obtained. Where the configuration mechanism does not 659 support fate sharing (e.g. DHCP), providing a name rather than an 660 address can simplify operations, assuming that the server's new 661 address is manually or automatically updated in the DNS; in this case 662 there is no need to re-do parameter configuration, since the name is 663 still valid. Where fate sharing is supported (e.g. service discovery 664 protocols), a fresh address can be obtained by re-initiating 665 parameter configuration. 667 In providing the IP addresses for a set of servers, it is desirable 668 to distinguish which IP addresses belong to which servers. If a 669 server IP address is unreachable, this enables the host to try the IP 670 address of another server, rather than another IP address of the same 671 server, in case the server is down. This can be enabled by 672 distinguishing which addresses belong to the same server. 674 3.4. Dual Stack Issues 676 One use for learning a list of interchangeable server addresses is 677 for fault tolerance, in case one or more of the servers are 678 unresponsive. Hosts will typically try the addresses in turn, only 679 attempting to use the second and subsequent addresses in the list if 680 the first one fails to respond quickly enough. In such cases, having 681 the list sorted in order of expected likelihood of success will help 682 clients get results faster. For hosts that support both IPv4 and 683 IPv6, it is desirable to obtain both IPv4 and IPv6 server addresses 684 within a single list. Obtaining IPv4 and IPv6 addresses in separate 685 lists, without indicating which server(s) they correspond to, 686 requires the host to use a heuristic to merge the lists. 688 For example, assume there are two servers, A and B, each with one 689 IPv4 address and one IPv6 address. If the first address the host 690 should try is (say) the IPv6 address of server A, then the second 691 address the host should try, if the first one fails, would generally 692 be the IPv4 address of server B. This is because the failure of the 693 first address could either be due to server A being down, or due to 694 some problem with the host's IPv6 address, or due to a problem with 695 connectivity to server A. Trying the IPv4 address next is preferred 696 since the reachability of the IPv4 address is independent of all 697 potential failure causes. 699 If the list of IPv4 server addresses were obtained separate from the 700 list of IPv6 server addresses, a host trying to merge the lists would 701 not know which IPv4 addresses belonged to the same server as the IPv6 702 address it just tried. This can be solved either by explicitly 703 distinguishing which addresses belong to which server or, more 704 simply, by configuring the host with a combined list of both IPv4 and 705 IPv6 addresses. Note that the same issue can arise with any 706 mechanism (e.g. DHCP, DNS, etc.) for obtaining server IP addresses. 708 Configuring a combined list of both IPv4 and IPv6 addresses gives the 709 configuration mechanism control over the ordering of addresses, as 710 compared with configuring a name and allowing the host resolver to 711 determine the address list ordering. See "DHCP Dual-Stack Issues" 712 [RFC4477] for more discussion of dual-stack issues in the context of 713 DHCP. 715 3.5. Relationship between Per-Interface and Per-Host Configuration 717 Parameters that are configured or acquired on a per-interface basis 718 can affect behavior of the host as a whole. Where only a single 719 configuration can be applied to a host, the host may need to 720 prioritize the per-interface configuration information in some way 721 (e.g. most trusted to least trusted). If the host needs to merge 722 per-interface configuration to produce a host-wide configuration, it 723 may need to take the union of the per-host configuration parameters 724 and order them in some way (e.g. highest speed interface to lowest 725 speed interface). Which procedure is to be applied and how this is 726 accomplished may vary depending on the parameter being configured. 727 Examples include: 729 Boot service configuration 730 While boot service configuration can be provided on 731 multiple interfaces, a given host may be limited in the 732 number of boot loads that it can handle simultaneously. 733 For example, a host not supporting virtualization may only 734 be capable of handling a single boot load at a time, or a 735 host capable of supporting N virtual machines may only be 736 capable of handling up to N simultaneous boot loads. As a 737 result, a host may need to select which boot load(s) it 738 will act on, out of those configured on a per-interface 739 basis. This requires that the host prioritize them (e.g. 740 most trusted to least trusted). 742 Name service configuration 743 While name service configuration is provided on a per- 744 interface basis, name resolution configuration typically 745 will affect behavior of the host as a whole. For example, 746 given the configuration of DNS server addresses and 747 searchlist parameters on each interface, the host 748 determines what sequence of name service queries is to be 749 sent on which interfaces. 751 Since the algorithms used to determine per-host behavior based on 752 per-interface configuration can affect interoperability, it is 753 important for these algorithms to be understood by implementers. We 754 therefore recommend that documents defining per-interface mechanisms 755 for acquiring per-host configuration (e.g. DHCP or IPv6 Router 756 Advertisement options) include guidance on how to deal with multiple 757 interfaces. This may include discussions of the following items: 759 1. Merging. How are per-interface configurations combined to 760 produce a per-host configuration? Is a single configuration 761 selected, or is the union of the configurations taken? 763 2. Prioritization. Are the per-interface configurations 764 prioritized as part of the merge process? If so, what are 765 some of the considerations to be taken into account in 766 prioritization? 768 4. Security Considerations 770 Secure IP configuration presents a number of challenges. In addition 771 to denial-of-service and man-in-the-middle attacks, attacks on 772 configuration mechanisms may target particular parameters. For 773 example, attackers may target DNS server configuration in order to 774 support subsequent phishing or pharming attacks such as those 775 described in "New trojan in mass DNS hijack" [DNSTrojan]. A number 776 of issues exist with various classes of parameters, as discussed in 777 Section 2.6, "IPv6 Neighbor Discovery (ND) Trust Models and Threats" 778 [RFC3756] Section 4.2.7, "Authentication for DHCP Messages" [RFC3118] 779 Section 1.1, and "Dynamic Host Configuration Protocol for IPv6 780 (DHCPv6)" [RFC3315] Section 23. Given the potential vulnerabilities, 781 hosts often restrict support for DHCP options to the minimum set 782 required to provide basic TCP/IP configuration. 784 Since boot configuration determines the boot image to be run by the 785 host, a successful attack on boot configuration could result in an 786 attacker gaining complete control over a host. As a result, it is 787 particularly important that boot configuration be secured. 788 Approaches to boot configuration security are described in 789 "Bootstrapping Clients using the Internet Small Computer System 790 Interface (iSCSI) Protocol" [RFC4173] and "Preboot Execution 791 Environment (PXE) Specification" [PXE]. 793 4.1. Configuration Authentication 795 The techniques available for securing Internet layer configuration 796 are limited. While it is technically possible to perform a very 797 limited subset of IP networking operations without an IP address, the 798 capabilities are severely restricted. A host without an IP address 799 cannot receive conventional unicast IP packets, only IP packets sent 800 to the broadcast or a multicast address. Configuration of an IP 801 address enables the use of IP fragmentation; packets sent from the 802 unknown address cannot be reliably reassembled, since fragments from 803 multiple hosts using the unknown address might be reassembled into a 804 single IP packet. Without an IP address, it is not possible to take 805 advantage of security facilities such as IPsec, specified in 806 "Security Architecture for the Internet Protocol" [RFC4301], or 807 Transport Layer Security (TLS) [RFC5246]. As a result, configuration 808 security is typically implemented within the configuration protocols 809 themselves. 811 PPP [RFC1661] does not support secure negotiation within IPv4CP 812 [RFC1332] or IPv6CP [RFC5072], enabling an attacker with access to 813 the link to subvert the negotiation. In contrast, IKEv2 [RFC4306] 814 provides encryption, integrity and replay protection for 815 configuration exchanges. 817 Where configuration packets are only expected to originate on 818 particular links or from particular hosts, filtering can help control 819 configuration spoofing. For example, a Network Access Server (NAS) 820 might only permit incoming configuration traffic (such as IPv6 Router 821 Advertisement packets (ICMP Type 134), or DHCP packets sent to the 822 client port (68 for DHCPv4, 546 for DHCPv6)) originating over a link 823 towards authorized configuration sources. To prevent spoofing, 824 communication between the DHCP relay and servers can be authenticated 825 and integrity protected using a mechanism such as IPsec. 827 Internet layer secure configuration mechanisms include SEcure 828 Neighbor Discovery (SEND) [RFC3971] for IPv6 stateless address 829 autoconfiguration [RFC4862], or DHCP authentication for stateful 830 address configuration. DHCPv4 [RFC2131] initially did not include 831 support for security; this was added in "Authentication for DHCP 832 Messages" [RFC3118]. DHCPv6 [RFC3315] included security support. 833 However, DHCP authentication is not widely implemented for either 834 DHCPv4 or DHCPv6. 836 Higher layer configuration can make use of a wider range of security 837 techniques. When DHCP authentication is supported, higher-layer 838 configuration parameters provided by DHCP can be secured. However, 839 even if a host does not support DHCPv6 authentication, higher-layer 840 configuration via Stateless DHCPv6 [RFC3736] can still be secured 841 with IPsec. 843 Possible exceptions can exist where security facilities are not 844 available until later in the boot process. It may be difficult to 845 secure boot configuration even once the Internet layer has been 846 configured, if security functionality is not available until after 847 boot configuration has been completed. For example, it is possible 848 that Kerberos, IPsec or TLS will not be available until later in the 849 boot process; see "Bootstrapping Clients using the Internet Small 850 Computer System Interface (iSCSI) Protocol" [RFC4173] for discussion. 852 Where public key cryptography is used to authenticate and integrity- 853 protect configuration, hosts need to be configured with trust anchors 854 in order to validate received configuration messages. For a node 855 that visits multiple administrative domains, acquiring the required 856 trust anchors may be difficult. 858 5. IANA Considerations 860 This document has no actions for IANA. 862 6. References 864 6.1. Informative References 866 [3GPP-24.008] 867 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 868 specification; Core network protocols; Stage 3 (Release 5)", 869 June 2003. 871 [DNSTrojan] 872 Goodin, D., "New trojan in mass DNS hijack", The Register, 873 December 5, 2008, http://www.theregister.co.uk/2008/12/05/ 874 new_dnschanger_hijacks/ 876 [IEN116] J. Postel, "Internet Name Server", IEN 116, August 1979, 877 http://www.ietf.org/rfc/ien/ien116.txt 879 [IEEE-802.1X] 880 Institute of Electrical and Electronics Engineers, "Local and 881 Metropolitan Area Networks: Port-Based Network Access 882 Control", IEEE Standard 802.1X-2004, December 2004. 884 [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service Discovery", 885 Internet-Draft (work in progress), draft-cheshire-dnsext-dns- 886 sd-05.txt, September 2008. 888 [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", June 2005. 889 http://files.multicastdns.org/draft-cheshire-dnsext- 890 multicastdns.txt 892 [PXE] Henry, M. and M. Johnston, "Preboot Execution Environment 893 (PXE) Specification", September 1999, 894 http://www.pix.net/software/pxeboot/archive/pxespec.pdf 896 [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August, 1980. 898 [RFC1001] NetBIOS Working Group in the Defense Advanced Research 899 Projects Agency, Internet Activities Board, and End-to-End 900 Services Task Force, "Protocol standard for a NetBIOS service 901 on a TCP/UDP transport: Concepts and methods", STD 19, RFC 902 1001, March 1987. 904 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 905 November 1990. 907 [RFC1332] McGregor, G., "PPP Internet Control Protocol", RFC 1332, 908 Merit, May 1992. 910 [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 911 1350, July 1992. 913 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 914 1661, July 1994. 916 [RFC1877] Cobb, S., "PPP Internet Protocol Control Protocol Extensions 917 for Name Server Addresses", RFC 1877, December 1995. 919 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 920 1958, June 1996. 922 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for 923 IP version 6", RFC 1981, August 1996. 925 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 926 March 1997. 928 [RFC2608] Guttman, E., et al., "Service Location Protocol, Version 2", 929 RFC 2608, June 1999. 931 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, 932 September 2000. 934 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 935 RFC 3118, June 2001. 937 [RFC3315] Droms, R., Ed., Bound, J., Volz,, B., Lemon, T., Perkins, C. 938 and M. Carney, "Dynamic Host Configuration Protocol for IPv6 939 (DHCPv6)", RFC 3315, July 2003. 941 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 942 2002. 944 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 945 Protocol (DHCP) Domain Search Option", RFC 3397, November 946 2002. 948 [RFC3456] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host 949 Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel 950 Mode", RFC 3456, January 2003. 952 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, 953 C., Eisler, M. and D. Noveck, "Network File System (NFS) 954 version 4 Protocol", RFC 3530, April 2003. 956 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C. Chadalapaka, M. and E. 957 Zeidner, "Internet Small Computer Systems Interface (iSCSI)", 958 RFC 3720, April 2004. 960 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 961 (DHCP) Service for IPv6", RFC 3736, April 2004. 963 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 964 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 965 3748, June 2004. 967 [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 968 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 970 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 971 IPv6", RFC 3775, June 2004. 973 [RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point 974 Protocol (PPP)", RFC 3818, BCP 88, June 2004. 976 [RFC3832] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C. and W. 977 Jerome, "Remote Service Discovery in the Service Location 978 Protocol (SLP) via DNS SRV", RFC 3832, July 2004. 980 [RFC3898] Kalusivalingam, V., "Networking Information Service (NIS) 981 Configuration Options for Dynamic Host Configuration Protocol 982 for IPv6 (DHCPv6)", RFC 3898, October 2004. 984 [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration 985 of IPv4 Link-Local Addresses", RFC 3927, May 2005. 987 [RFC3971] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. 988 Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 989 2005. 991 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 992 3972, March 2005. 994 [RFC4171] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C. and J. 995 Souza, "Internet Storage Name Service (iSNS), RFC 4171, 996 September 2005. 998 [RFC4173] Sarkar, P., Missimer, D. and C. Sapuntzakis, "Bootstrapping 999 Clients using the iSCSI Protocol", RFC 4173, September 2005. 1001 [RFC4174] Monia, C., Tseng, J. and K. Gibbons, "The IPv4 Dynamic Host 1002 Configuration Protocol (DHCP) Option for the Internet Storage 1003 Name Service", RFC 4174, September 2005. 1005 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet 1006 Protocol", RFC 4301, December 2005. 1008 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 1009 4306, December 2005. 1011 [RFC4339] Jeong, J., "IPv6 Host Configuration of DNS Server Information 1012 Approaches", RFC 4339, February 2006. 1014 [RFC4477] Chown, T., Venaas, S. and C. Strauf, "Dynamic Host 1015 Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack 1016 Issues", RFC 4477, May 2006. 1018 [RFC4578] Johnston, M. and S. Venaas, "Dynamic Host Configuration 1019 Protocol (DHCP) Options for the Intel Preboot eXecution 1020 Environment (PXE)", RFC 4578, November 2006. 1022 [RFC4795] Aboba, B., Thaler, D. and L. Esibov, "Link-Local Multicast 1023 Name Resolution (LLMNR)", RFC 4795, January 2007. 1025 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1026 Discovery", RFC 4821, March 2007. 1028 [RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless Address 1029 Autoconfiguration", RFC 4862, September 2007. 1031 [RFC4941] Narten, T., Draves, R. and S. Krishnan, "Privacy Extensions 1032 for Stateless Address Autoconfiguration in IPv6", RFC 4941, 1033 September 2007. 1035 [RFC5072] Varada, S., Haskins D. and E. Allen, "IP Version 6 over PPP", 1036 RFC 5072, September 2007. 1038 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1039 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1041 [STD3] Braden, R., "Requirements for Internet Hosts -- Communication 1042 Layers", STD 3, RFC 1122, and "Requirements for Internet Hosts 1043 -- Application and Support", STD 3, RFC 1123, October 1989. 1045 Acknowledgments 1047 Elwyn Davies, Bob Hinden, Pasi Eronen, Jari Arkko, Pekka Savola, 1048 James Kempf, Ted Hardie and Alfred Hoenes provided valuable input on 1049 this document. 1051 Appendix A - IAB Members at the time of this writing 1053 Loa Andersson 1054 Gonzalo Camarillo 1055 Stuart Cheshire 1056 Russ Housley 1057 Olaf Kolkman 1058 Gregory Lebovitz 1059 Barry Leiba 1060 Kurtis Lindqvist 1061 Andrew Malis 1062 Danny McPherson 1063 David Oran 1064 Dave Thaler 1065 Lixia Zhang 1067 Authors' Addresses 1069 Bernard Aboba 1070 Microsoft Corporation 1071 One Microsoft Way 1072 Redmond, WA 98052 1074 EMail: bernarda@microsoft.com 1076 Dave Thaler 1077 Microsoft Corporation 1078 One Microsoft Way 1079 Redmond, WA 98052 1081 EMail: dthaler@microsoft.com 1083 Loa Andersson 1084 Acreo AB 1086 EMail: loa@pi.nu 1088 Stuart Cheshire 1089 Apple Computer, Inc. 1090 1 Infinite Loop 1091 Cupertino, CA 95014 1093 EMail: cheshire@apple.com