idnits 2.17.1 draft-iab-ip-config-10.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: July 5, 2009 Stuart Cheshire 6 19 December 2008 Internet Architecture Board 8 Principles of Internet Host Configuration 9 draft-iab-ip-config-10.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 July 5, 2009. 34 Copyright Notice 36 Copyright (c) 2008 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 avoiding parameter configuration or 103 supporting self-configuration. 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 specified in 111 "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" 112 [RFC4941] are available to applications). 114 1.1. Terminology 116 link A communication facility or medium over which nodes can 117 communicate at the link-layer, i.e., the layer immediately 118 below IP. Examples are Ethernets (simple or bridged), PPP 119 links, X.25, Frame Relay, or ATM networks as well as 120 Internet (or higher) layer "tunnels", such as tunnels over 121 IPv4 or IPv6 itself. 123 on link An address that is assigned to an interface on a specified 124 link. 126 off link The opposite of "on link"; an address that is not assigned 127 to any interfaces on the specified link. 129 mobility agent 130 Either a home agent or a foreign agent. 132 1.2. Internet Host Configuration 134 1.2.1. Internet Layer Configuration 136 Internet layer configuration is defined as the configuration required 137 to support the operation of the Internet layer. This includes 138 configuration of per-interface and per-host parameters, including IP 139 address(es), subnet prefix(es), default gateway(s), mobility 140 agent(s), boot service configuration and other parameters: 142 IP address(es) 143 Internet Protocol (IP) address configuration includes both 144 configuration of link-scope addresses as well as global 145 addresses. Configuration of IP addresses is a vital step, 146 since practically all of IP networking relies on the 147 assumption that hosts have IP address(es) associated with 148 (each of) their active network interface(s). Used as the 149 source address of an IP packet, these IP addresses 150 indicate the sender of the packet; used as the destination 151 address of a unicast IP packet, these IP addresses 152 indicate the intended receiver. 154 The only common example of IP-based protocols operating 155 without an IP address involves address configuration, such 156 as the use of DHCPv4 [RFC2131] to obtain an address. In 157 this case, by definition, DHCPv4 is operating before the 158 host has an IPv4 address, so the DHCP protocol designers 159 had the choice of either using IP without an IP address, 160 or not using IP at all. The benefits of making IPv4 self- 161 reliant, configuring itself using its own IPv4 packets, 162 instead of depending on some other protocol, outweighed 163 the drawbacks of having to use IP in this constrained 164 mode. Use of IP for purposes other than address 165 configuration can safely assume that the host will have 166 one or more IP addresses, which may be self-configured 167 link-local addresses, or other addresses configured via 168 DHCP or other means. 170 Subnet prefix(es) 171 Once a subnet prefix is configured on an interface, hosts 172 with an IP address can exchange unicast IP packets 173 directly with on-link hosts within the same subnet prefix. 175 Default gateway(s) 176 Once a default gateway is configured on an interface, 177 hosts with an IP address can send unicast IP packets to 178 that gateway for forwarding to off-link hosts. 180 Mobility agent(s) 181 While Mobile IPv4 [RFC3344] and Mobile IPv6 [RFC3775] 182 include their own mechanisms for locating home agents, it 183 is also possible for mobile nodes to utilize dynamic home 184 agent configuration. 186 Boot service configuration 187 Boot service configuration is defined as the configuration 188 necessary for a host to obtain and perhaps also to verify 189 an appropriate boot image. This is appropriate for disk- 190 less hosts looking to obtain a boot image via mechanisms 191 such as the Trivial File Transfer Protocol (TFTP) 192 [RFC1350], Network File System (NFS) [RFC3530] and 193 Internet Small Computer Systems Interface (iSCSI) 194 [RFC3720][RFC4173]. It also may be useful in situations 195 where it is necessary to update the boot image of a host 196 that supports a disk, such as in the Preboot eXecution 197 Environment (PXE) [PXE][RFC4578]. While strictly speaking 198 boot services operate above the Internet layer, where boot 199 service is used to obtain the Internet layer code, it may 200 be considered part of Internet layer configuration. While 201 boot service parameters may be provided on a per-interface 202 basis, loading and verification of a boot image affects 203 behavior of the host as a whole. 205 Other IP parameters 206 Internet layer parameter configuration also includes 207 configuration of per-host parameters (e.g. hostname) and 208 per-interface parameters (e.g. IP Time-To-Live (TTL) to 209 use in outgoing packets, enabling/disabling of IP 210 forwarding and source routing, and Maximum Transmission 211 Unit (MTU)). 213 1.2.2. Higher Layer Configuration 215 Higher layer configuration is defined as the configuration required 216 to support the operation of other components above the Internet 217 layer. This includes, for example: 219 Name Service Configuration 220 The configuration required for the host to resolve names. 221 This includes configuration of the addresses of name 222 resolution servers, including IEN 116 [IEN116], Domain 223 Name System (DNS), Windows Internet Name Service (WINS), 224 Internet Storage Name Service (iSNS) [RFC4171][RFC4174] 225 and Network Information Service (NIS) servers [RFC3898], 226 and the setting of name resolution parameters such as the 227 DNS domain and search list [RFC3397], the NetBIOS node 228 type, etc. It may also include the transmission or 229 setting of the host's own name. Note that link local name 230 resolution services (such as NetBIOS [RFC1001], Link-Local 231 Multicast Name Resolution (LLMNR) [RFC4795] and multicast 232 DNS (mDNS) [mDNS]) typically do not require configuration. 234 Once the host has completed name service configuration, it 235 is capable of resolving names using name resolution 236 protocols that require configuration. This not only 237 allows the host to communicate with off-link hosts whose 238 IP address is not known, but to the extent that name 239 services requiring configuration are utilized for service 240 discovery, this also enables the host to discover services 241 available on the network or elsewhere. While name service 242 parameters can be provided on a per-interface basis, their 243 configuration will typically affect behavior of the host 244 as a whole. 246 Time Service Configuration 247 Time service configuration includes configuration of 248 servers for protocols such as the Simple Network Time 249 Protocol (SNTP) and the Network Time Protocol (NTP). 250 Since accurate determination of the time may be important 251 to operation of the applications running on the host 252 (including security services), configuration of time 253 servers may be a prerequisite for higher layer operation. 254 However, it is typically not a requirement for Internet 255 layer configuration. While time service parameters can be 256 provided on a per-interface basis, their configuration 257 will typically affect behavior of the host as a whole. 259 Other service configuration 260 This can include discovery of additional servers and 261 devices, such as printers, Session Initiation Protocol 262 (SIP) proxies, etc. This configuration will typically 263 apply to the entire host. 265 2. Principles 267 This section describes basic principles of Internet host 268 configuration. 270 2.1. Minimize Configuration 272 Anything that can be configured can be misconfigured. "Architectural 273 Principles of the Internet" [RFC1958] Section 3.8 states: "Avoid 274 options and parameters whenever possible. Any options and parameters 275 should be configured or negotiated dynamically rather than manually." 277 That is, to minimize the possibility of configuration errors, 278 parameters should be automatically computed (or at least have 279 reasonable defaults) whenever possible. For example, the Path 280 Maximum Transmission Unit (PMTU) can be discovered, as described in 281 "Packetization Layer Path MTU Discovery" [RFC4821], "TCP Problems 282 with Path MTU Discovery" [RFC2923], "Path MTU discovery" [RFC1191] 283 and "Path MTU Discovery for IP version 6" [RFC1981]. 285 Having a protocol design with many configurable parameters increases 286 the possibilities for misconfiguration of those parameters, resulting 287 in failures or other sub-optimal operation. Eliminating or reducing 288 configurable parameters helps lessen this risk. Where configurable 289 parameters are necessary or desirable, protocols can reduce the risk 290 of human error by making these parameters self-configuring, such as 291 by using capability negotiation within the protocol, or by discovery 292 of other hosts that implement the same protocol. 294 2.2. Less is More 296 The availability of standardized, simple mechanisms for general- 297 purpose Internet host configuration is highly desirable. RFC 1958 298 [RFC1958] states, "Performance and cost must be considered as well as 299 functionality" and "Keep it simple. When in doubt during design, 300 choose the simplest solution." 302 To allow protocol support in more 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 has to be 317 performed using the User Datagram Protocol over IP (UDP/IP) [RFC768] 318 instead. This is one reason why Internet layer configuration 319 mechanisms typically depend only on IP and UDP. After obtaining the 320 boot image, the host will have the full facilities of TCP/IP 321 available to it, including support for reliable transport protocols, 322 IPsec, etc. 324 In order to reduce complexity, it is desirable for Internet layer 325 configuration mechanisms to avoid dependencies on higher layers. 326 Since embedded devices may be severely constrained on how much code 327 they can fit within their ROM, designing a configuration mechanism in 328 such a way that it requires the availability of higher layer 329 facilities may make that configuration mechanism unusable in such 330 devices. In fact, it cannot even be guaranteed that all Internet 331 layer facilities will be available. For example, the minimal version 332 of IP in a host's boot ROM may not implement IP fragmentation and 333 reassembly. 335 2.3. Minimize Diversity 337 The number of host configuration mechanisms should be minimized. 338 Diversity in Internet host configuration mechanisms presents several 339 problems: 341 Interoperability As configuration diversity increases, it becomes 342 likely that a host will not support the 343 configuration mechanism(s) available on the 344 network to which it has attached, creating 345 interoperability problems. 347 Footprint For maximum interoperability, a host would need to 348 implement all configuration mechanisms used on all 349 the link layers it supports. This increases the 350 required footprint, a burden for embedded devices. 351 It also leads to lower quality, since testing 352 resources (both formal testing, and real-world 353 operational use) are spread more thinly -- the 354 more different configuration mechanisms a device 355 supports, the less testing each one is likely to 356 undergo. 358 Redundancy To support diversity in host configuration 359 mechanisms, operators would need to support 360 multiple configuration services to ensure that 361 hosts connecting to their networks could configure 362 themselves. This represents an additional expense 363 for little benefit. 365 Latency As configuration diversity increases, hosts 366 supporting multiple configuration mechanisms may 367 spend increasing effort to determine which 368 mechanism(s) are supported. This adds to 369 configuration latency. 371 Conflicts Whenever multiple mechanisms are available, it is 372 possible that multiple configuration(s) will be 373 returned. To handle this, hosts would need to 374 merge potentially conflicting configurations. 375 This would require conflict resolution logic, such 376 as ranking of potential configuration sources, 377 increasing implementation complexity. 379 Additional traffic To limit configuration latency, hosts may 380 simultaneously attempt to obtain configuration by 381 multiple mechanisms. This can result in 382 increasing on-the-wire traffic, both from use of 383 multiple mechanisms as well as from 384 retransmissions within configuration mechanisms 385 not implemented on the network. 387 Security Support for multiple configuration mechanisms 388 increases the attack surface without any potential 389 benefit. 391 2.4. Lower Layer Independence 393 "Architectural Principles of the Internet" [RFC1958] states, 394 "Modularity is good. If you can keep things separate, do so." 396 It is becoming increasingly common for hosts to support multiple 397 network access mechanisms, including dialup, wireless and wired local 398 area networks, wireless metropolitan and wide area networks, etc. 399 The proliferation of network access mechanisms makes it desirable for 400 hosts to be able to configure themselves on multiple networks without 401 adding configuration code specific to a new link layer. 403 As a result, it is highly desirable for Internet host configuration 404 mechanisms to be independent of the underlying lower layer. That is, 405 only the link layer protocol (whether it be a physical link, or a 406 virtual tunnel link) should be explicitly aware of link-layer 407 parameters (although it may configure them). Introduction of lower 408 layer dependencies increases the likelihood of interoperability 409 problems and adds Internet layer configuration mechanisms that hosts 410 need to implement. 412 Lower layer dependencies can be best avoided by keeping Internet host 413 configuration above the link layer, thereby enabling configuration to 414 be handled for any link layer that supports IP. In order to provide 415 media independence, Internet host configuration mechanisms should be 416 link-layer protocol independent. 418 While there are examples of Internet layer configuration within the 419 link layer (such as in the Point-to-Point Protocol (PPP) IPv4CP 420 [RFC1332] and "Mobile radio interface Layer 3 specification; Core 421 network protocols; Stage 3 (Release 5)" [3GPP-24.008]), this approach 422 has disadvantages. This includes the extra complexity of 423 implementing different mechanisms on different link layers, and the 424 difficulty in adding new parameters which would require defining a 425 mechanism in each link layer protocol. 427 For example, "Internet Protocol Control Protocol (IPCP) Extensions 428 for Name Service Configuration" [RFC1877] was developed prior to the 429 definition of the DHCPINFORM message in "Dynamic Host Configuration 430 Protocol" [RFC2131]; at that time Dynamic Host Configuration Protocol 431 (DHCP) servers had not been widely implemented on access devices or 432 deployed in service provider networks. While the design of IPv4CP 433 was appropriate in 1992, it should not be taken as an example that 434 new link layer technologies should emulate. Indeed, in order to 435 "actively advance PPP's most useful extensions to full standard, 436 while defending against further enhancements of questionable value", 437 "IANA Considerations for the Point-to-Point Protocol (PPP)" [RFC3818] 438 changed the allocation of PPP protocol numbers (including IPv4CP 439 extensions) so as to no longer be "first come first served." 441 In IPv6 where link layer independent mechanisms such as "IPv6 442 Stateless Address Autoconfiguration" [RFC4862] and "Stateless Dynamic 443 Host Configuration Protocol (DHCP) Service for IPv6" [RFC3736] are 444 available, PPP IPv6CP [RFC5072] configures an Interface-Identifier 445 which is similar to a MAC address. This enables PPP IPv6CP to avoid 446 duplicating DHCPv6 functionality. 448 However, Internet Key Exchange Version 2 (IKEv2) [RFC4306] utilizes 449 the same approach as PPP IPv4CP by defining a Configuration Payload 450 for Internet host configuration for both IPv4 and IPv6. While the 451 IKEv2 approach reduces the number of exchanges, "Dynamic Host 452 Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode" 453 [RFC3456] points out that leveraging DHCP has advantages in terms of 454 address management integration, address pool management, 455 reconfiguration and fail-over. 457 Extensions to link layer protocols for the purpose of Internet, 458 transport or application layer configuration (including server 459 configuration) should be avoided. Such extensions can negatively 460 affect the properties of a link as seen by higher layers. For 461 example, if a link layer protocol (or tunneling protocol) configures 462 individual IPv6 addresses and precludes using any other addresses, 463 then applications that desire "Privacy Extensions for Stateless 464 Address Autoconfiguration in IPv6" [RFC4941] may not function well. 465 Similar issues may arise for other types of addresses, such as 466 Cryptographically Generated Addresses [RFC3972]. 468 Avoiding lower layer dependencies is desirable even where the lower 469 layer is link independent. For example, while the Extensible 470 Authentication Protocol (EAP) may be run over any link satisfying its 471 requirements (see [RFC3748] Section 3.1), many link layers do not 472 support EAP and therefore Internet layer configuration mechanisms 473 with EAP dependencies would not be usable on all links that support 474 IP. 476 2.5. Configuration is Not Access Control 478 Network access authentication and authorization is a distinct problem 479 from Internet host configuration. Therefore network access 480 authentication and authorization is best handled independently of the 481 Internet and higher layer configuration mechanisms. 483 Having an Internet (or higher) layer protocol authenticate clients is 484 appropriate to prevent resource exhaustion of a scarce resource on 485 the server (such as IP addresses or prefixes), but not for preventing 486 hosts from obtaining access to a link. If the user can manually 487 configure the host, requiring authentication in order to obtain 488 configuration parameters (such as an IP address) has little value. 489 Network administrators who wish to control access to a link can 490 achieve this better using technologies like Port Based Network Access 491 Control [IEEE-802.1X]. Note that client authentication is not 492 required for Stateless DHCPv6 [RFC3736] since it does not result in 493 allocation of any limited resources on the server. 495 3. Additional Discussion 497 3.1. Reliance on General Purpose Mechanisms 499 Protocols should either be self-configuring (especially where fate 500 sharing is important), or use general-purpose configuration 501 mechanisms (such as DHCP or a service discovery protocol, as noted in 502 Section 3.2). The choice should be made taking into account the 503 architectural principles discussed in Section 2. 505 Taking into account the availability of existing general-purpose 506 configuration mechanisms, we see little need for development of 507 additional general-purpose configuration mechanisms. 509 When defining a new host parameter, protocol designers should first 510 consider whether configuration is indeed necessary (see Section 2.1). 511 If configuration is necessary, in addition to considering fate 512 sharing (see Section 3.2.1), protocol designers should consider: 514 1. The organizational implications for administrators. For 515 example, routers and servers are often administered by 516 different sets of individuals, so that configuring a router 517 with server parameters may require cross-group collaboration. 519 2. Whether the need is to configure a set of interchangeable 520 servers or to select a server satisfying a particular set 521 of criteria. See Section 3.2. 523 3. Whether IP address(es) should configured or name(s). 524 See Section 3.3. 526 4. If IP address(es) are configured, whether IPv4 and 527 IPv6 addresses should be configured simultaneously or 528 separately. See Section 3.4. 530 5. Whether the parameter is a per-interface or a per-host 531 parameter. For example, configuration protocols 532 such as DHCP run on a per-interface basis and hence 533 are more appropriate for per-interface parameters. 535 6. How per-interface configuration affects host-wide behavior. 536 For example, whether the host should select a subset 537 of the per-interface configurations, or whether the 538 configurations are to merged, and if so, how this is 539 done. See Section 3.5. 541 3.2. Relationship between IP Configuration and Service Discovery 543 Higher-layer configuration often includes configuring server 544 addresses. The question arises as to how this differs from "service 545 discovery" as provided by Service Discovery protocols such as the 546 Service Location Protocol Version 2 (SLPv2) [RFC2608] or DNS-Based 547 Service Discovery (DNS-SD) [DNS-SD]. 549 In Internet host configuration mechanisms such as DHCP, if multiple 550 server instances are provided, they are considered interchangeable. 551 For example, in a list of time servers, the servers are considered 552 interchangeable because they all provide the exact same service -- 553 telling you the current time. In a list of local caching DNS 554 servers, the servers are considered interchangeable because they all 555 should give you the same answer to any DNS query. In service 556 discovery protocols, on the other hand, a host desires to find a 557 server satisfying a particular set of criteria, which may vary by 558 request. When printing a document, it is not the case that any 559 printer will do. The speed, capabilities, and physical location of 560 the printer matter to the user. 562 Information learned via DHCP is typically learned once, at boot time, 563 and after that may be updated only infrequently (e.g. on DHCP lease 564 renewal), if at all. This makes it appropriate for information that 565 is relatively static and unchanging over these time intervals. Boot- 566 time discovery of server addresses is appropriate for service types 567 where there are a small number of interchangeable servers that are of 568 interest to a large number of clients. For example, listing time 569 servers in a DHCP packet is appropriate because an organization may 570 typically have only two or three time servers, and most hosts will be 571 able to make use of that service. Listing all the printers or file 572 servers at an organization is a lot less useful, because the list may 573 contain hundreds or thousands of entries, and on a given day a given 574 user may not use any of the printers in that list. 576 Service discovery protocols can support discovery of servers on the 577 Internet, not just those within the local administrative domain. For 578 example, see "Remote Service Discovery in the Service Location 579 Protocol (SLP) via DNS SRV" [RFC3832] and DNS-Based Service Discovery 580 [DNS-SD]. Internet host configuration mechanisms such as DHCP, on 581 the other hand, typically assume the server(s) in the local 582 administrative domain contain the authoritative set of information. 584 For the service discovery problem (i.e., where the criteria varies on 585 a per-request basis, even from the same host), protocols should 586 either be self-discovering (if fate sharing is critical), or use 587 general purpose service discovery mechanisms. 589 In order to avoid a dependency on multicast routing, it is necessary 590 for a host to either restrict discovery to services on the local link 591 or to discover the location of a Directory Agent (DA). Since the DA 592 may not be available on the local link, service discovery beyond the 593 local link is typically dependent on a mechanism for configuring the 594 DA address or name. As a result, service discovery protocols can 595 typically not be relied upon for obtaining basic Internet layer 596 configuration, although they can be used to obtain higher-layer 597 configuration parameters. 599 3.2.1. Fate Sharing 601 If a server (or set of servers) is needed to get a set of 602 configuration parameters, "fate sharing" ([RFC1958], Section 2.3) is 603 preserved if the servers are ones without which the parameters could 604 not be used, even if they were obtained via other means. 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 available. 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 can only receive IP packets sent to the broadcast or a multicast 800 address. Configuration of an IP address enables the use of IP 801 fragmentation; packets sent from the unknown address cannot be 802 reliably reassembled, since fragments from multiple hosts using the 803 unknown address might be reassembled into a single IP packet. 804 Without an IP address, it is not possible to take advantage of 805 security facilities such as IPsec, specified in "Security 806 Architecture for the Internet Protocol" [RFC4301], or Transport Layer 807 Security (TLS) [RFC5246]. As a result, configuration security is 808 typically implemented within the configuration protocols themselves. 810 PPP [RFC1661] does not support secure negotiation within IPv4CP 811 [RFC1332] or IPv6CP [RFC5072], enabling an attacker with access to 812 the link to subvert the negotiation. In contrast, IKEv2 [RFC4306] 813 provides encryption, integrity and replay protection for 814 configuration exchanges. 816 Where configuration packets are only expected to originate on 817 particular links or from particular hosts, filtering can help control 818 configuration spoofing. For example, a Network Access Server (NAS) 819 acting as a DHCP relay can only permit incoming DHCP packets sent to 820 the client port originating from DHCP server addresses. To prevent 821 spoofing, communication between the DHCP Relay and Server can be 822 authenticated and integrity protected using a mechanism such as 823 IPsec. Where configuration packets can only originate on a wired 824 link, incoming configuration packets on wireless links can be 825 discarded, such as IPv6 Router Advertisement packets (ICMP Type 134), 826 DHCPv4 packets sent to the client port (68), and DHCPv6 packets sent 827 to the client port (546). 829 Internet layer secure configuration mechanisms include SEcure 830 Neighbor Discovery (SEND) [RFC3971] for IPv6 stateless address 831 autoconfiguration [RFC4862], or DHCP authentication for stateful 832 address configuration. DHCPv4 [RFC2131] initially did not include 833 support for security; this was added in "Authentication for DHCP 834 Messages" [RFC3118]. DHCPv6 [RFC3315] included security support. 835 However, DHCP authentication is not widely implemented for either 836 DHCPv4 or DHCPv6. 838 Higher layer configuration can make use of a wider range of security 839 techniques. When DHCP authentication is supported, higher-layer 840 configuration parameters provided by DHCP can be secured. However, 841 even if a host does not support DHCPv6 authentication, higher-layer 842 configuration via Stateless DHCPv6 [RFC3736] can still be secured 843 with IPsec. 845 Possible exceptions can exist where security facilities are not 846 available until later in the boot process. It may be difficult to 847 secure boot configuration even once the Internet layer has been 848 configured, if security functionality is not available until after 849 boot configuration has been completed. For example, it is possible 850 that Kerberos, IPsec or TLS will not be available until later in the 851 boot process; see "Bootstrapping Clients using the Internet Small 852 Computer System Interface (iSCSI) Protocol" [RFC4173] for discussion. 854 Where public key cryptography is used to authenticate and integrity- 855 protect configuration, hosts need to be configured with trust anchors 856 in order to validate received configuration messages. For a node 857 that visits multiple administrative domains, acquiring the required 858 trust anchors may be difficult. This is left as an area for future 859 work. 861 5. IANA Considerations 863 This document has no actions for IANA. 865 6. References 867 6.1. Informative References 869 [3GPP-24.008] 870 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 871 specification; Core network protocols; Stage 3 (Release 5)", 872 June 2003. 874 [DNSTrojan] 875 Goodin, D., "New trojan in mass DNS hijack", The Register, 876 December 5, 2008, http://www.theregister.co.uk/2008/12/05/ 877 new_dnschanger_hijacks/ 879 [IEN116] J. Postel, "Internet Name Server", IEN 116, August 1979, 880 http://www.ietf.org/rfc/ien/ien116.txt 882 [IEEE-802.1X] 883 Institute of Electrical and Electronics Engineers, "Local and 884 Metropolitan Area Networks: Port-Based Network Access 885 Control", IEEE Standard 802.1X-2004, December 2004. 887 [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service Discovery", 888 Internet-Draft (work in progress), draft-cheshire-dnsext-dns- 889 sd-05.txt, September 2008. 891 [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", June 2005. 892 http://files.multicastdns.org/draft-cheshire-dnsext- 893 multicastdns.txt 895 [PXE] Henry, M. and M. Johnston, "Preboot Execution Environment 896 (PXE) Specification", September 1999, 897 http://www.pix.net/software/pxeboot/archive/pxespec.pdf 899 [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August, 1980. 901 [RFC1001] NetBIOS Working Group in the Defense Advanced Research 902 Projects Agency, Internet Activities Board, and End-to-End 903 Services Task Force, "Protocol standard for a NetBIOS service 904 on a TCP/UDP transport: Concepts and methods", STD 19, RFC 905 1001, March 1987. 907 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 908 November 1990. 910 [RFC1332] McGregor, G., "PPP Internet Control Protocol", RFC 1332, 911 Merit, May 1992. 913 [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 914 1350, July 1992. 916 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 917 1661, July 1994. 919 [RFC1877] Cobb, S., "PPP Internet Protocol Control Protocol Extensions 920 for Name Server Addresses", RFC 1877, December 1995. 922 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 923 1958, June 1996. 925 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for 926 IP version 6", RFC 1981, August 1996. 928 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 929 March 1997. 931 [RFC2608] Guttman, E., et al., "Service Location Protocol, Version 2", 932 RFC 2608, June 1999. 934 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, 935 September 2000. 937 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 938 RFC 3118, June 2001. 940 [RFC3315] Droms, R., Ed., Bound, J., Volz,, B., Lemon, T., Perkins, C. 941 and M. Carney, "Dynamic Host Configuration Protocol for IPv6 942 (DHCPv6)", RFC 3315, July 2003. 944 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 945 2002. 947 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 948 Protocol (DHCP) Domain Search Option", RFC 3397, November 949 2002. 951 [RFC3456] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host 952 Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel 953 Mode", RFC 3456, January 2003. 955 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, 956 C., Eisler, M. and D. Noveck, "Network File System (NFS) 957 version 4 Protocol", RFC 3530, April 2003. 959 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C. Chadalapaka, M. and E. 960 Zeidner, "Internet Small Computer Systems Interface (iSCSI)", 961 RFC 3720, April 2004. 963 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 964 (DHCP) Service for IPv6", RFC 3736, April 2004. 966 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 967 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 968 3748, June 2004. 970 [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 971 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 973 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 974 IPv6", RFC 3775, June 2004. 976 [RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point 977 Protocol (PPP)", RFC 3818, BCP 88, June 2004. 979 [RFC3832] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C. and W. 980 Jerome, "Remote Service Discovery in the Service Location 981 Protocol (SLP) via DNS SRV", RFC 3832, July 2004. 983 [RFC3898] Kalusivalingam, V., "Networking Information Service (NIS) 984 Configuration Options for Dynamic Host Configuration Protocol 985 for IPv6 (DHCPv6)", RFC 3898, October 2004. 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: chesire [at] apple [dot] com