idnits 2.17.1 draft-iab-ip-config-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 989. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1000. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1007. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1013. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-cheshire-dnsext-dns-sd-04 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3530 (Obsoleted by RFC 7530) -- Obsolete informational reference (is this intentional?): RFC 3720 (Obsoleted by RFC 7143) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Aboba 3 INTERNET-DRAFT D. Thaler 4 Category: Informational Loa Andersson 5 Expires: March 3, 2009 Stuart Cheshire 6 26 August 2008 Internet Architecture Board 8 Principles of Internet Host Configuration 9 draft-iab-ip-config-06.txt 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of 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 March 3, 2009. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2008). 38 Abstract 40 This document describes principles of Internet host configuration. 41 It covers issues relating to configuration of Internet layer 42 parameters, as well as parameters affecting higher layer protocols. 44 Table of Contents 46 1. Introduction.............................................. 3 47 1.1 Terminology ........................................ 3 48 1.2 Internet Host Configuration ........................ 4 49 2. Principles ............................................... 6 50 2.1 Minimize Configuration ............................. 6 51 2.2 Less is More ....................................... 7 52 2.3 Minimize Diversity ................................. 8 53 2.4 Lower Layer Independence ........................... 9 54 2.5 Configuration is Not Access Control ................ 10 55 3. Additional Discussion .................................... 11 56 3.1 Reliance on General Purpose Mechanisms ............. 11 57 3.2 Relationship between IP Configuration and 58 Service Discovery .................................. 11 59 4. Security Considerations .................................. 15 60 4.1 Configuration Authentication ....................... 16 61 5. IANA Considerations ...................................... 17 62 6. References ............................................... 17 63 6.1 Informative References ............................. 17 64 Acknowledgments .............................................. 21 65 Appendix A - IAB Members ..................................... 21 66 Authors' Addresses ........................................... 21 67 Full Copyright Statement ..................................... 22 68 Intellectual Property ........................................ 22 69 1. Introduction 71 This document describes principles of Internet host [STD3] 72 configuration. It covers issues relating to configuration of 73 Internet layer parameters, as well as parameters affecting higher 74 layer protocols. 76 In recent years, a number of architectural questions have arisen, for 77 which we provide guidance to protocol developers: 79 o What protocol layers and general approaches are most appropriate 80 for configuration of various parameters. 82 o The relationship between parameter configuration and service 83 discovery. 85 o The relationship between network access authentication and host 86 configuration. 88 o The desirability of avoiding parameter configuration or 89 supporting self-configuration. 91 o The role of link-layer protocols and tunneling protocols 92 in Internet host configuration. 94 The role of the link-layer and tunneling protocols is particularly 95 important, since it can affect the properties of a link as seen by 96 higher layers (for example, whether privacy extensions specified in 97 "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" 98 [RFC4941] are available to applications). 100 1.1. Terminology 102 link A communication facility or medium over which nodes can 103 communicate at the link-layer, i.e., the layer immediately 104 below IP. Examples are Ethernets (simple or bridged), PPP 105 links, X.25, Frame Relay, or ATM networks as well as 106 Internet (or higher) layer "tunnels", such as tunnels over 107 IPv4 or IPv6 itself. 109 on link An address that is assigned to an interface on a specified 110 link. 112 off link The opposite of "on link"; an address that is not assigned 113 to any interfaces on the specified link. 115 mobility agent 116 Either a home agent or a foreign agent. 118 1.2. Internet Host Configuration 120 Internet layer configuration is defined as the configuration required 121 to support the operation of the Internet layer. This includes IP 122 address(es), subnet prefix(es), default gateway(s), mobility 123 agent(s), boot service configuration and other parameters: 125 IP address(es) 126 Internet Protocol (IP) address configuration includes both 127 configuration of link-scope addresses as well as global 128 addresses. Configuration of IP addresses is a vital step, 129 since practically all of IP networking relies on the 130 assumption that hosts have IP address(es) associated with 131 (each of) their active network interface(s). Used as the 132 source address of an IP packet, these IP addresses 133 indicate the sender of the packet; used as the destination 134 address of a unicast IP packet, these IP addresses 135 indicate the intended receiver. 137 The only common example of IP-based protocols operating 138 without an IP address involves address configuration, such 139 as the use of DHCPv4 [RFC2131] to obtain an address. In 140 this case, by definition, DHCPv4 is operating before the 141 client has an IPv4 address, so the DHCP protocol designers 142 had the choice of either using IP without an IP address, 143 or not using IP at all. The benefits of making IPv4 self- 144 reliant, configuring itself using its own IPv4 packets, 145 instead of depending on some other protocol, outweighed 146 the drawbacks of having to use IP in this constrained 147 mode. Use of IP for purposes other than address 148 configuration can safely assume that the host will have 149 one or more IP addresses, which may be self-configured 150 link-local addresses, or other addresses configured via 151 DHCP or other means. 153 Subnet prefix(es) 154 Once a subnet prefix is configured, hosts with an IP 155 address can exchange unicast IP packets directly with on- 156 link hosts within the same subnet prefix. 158 Default gateway(s) 159 Once a default gateway is configured, hosts with an IP 160 address can send unicast IP packets to that gateway for 161 forwarding to off-link hosts. 163 Mobility agent(s) 164 While Mobile IPv4 [RFC3344] and Mobile IPv6 [RFC3775] 165 include their own mechanisms for locating home agents, it 166 is also possible for mobile nodes to utilize dynamic home 167 agent configuration. 169 Boot service configuration 170 Boot service configuration is defined as the configuration 171 necessary for a host to obtain and perhaps also to verify 172 an appropriate boot image. This is appropriate for disk- 173 less hosts looking to obtain a boot image via mechanisms 174 such as the Trivial File Transfer Protocol (TFTP) 175 [RFC1350], Network File System (NFS) [RFC3530] and 176 Internet Small Computer Systems Interface (iSCSI) 177 [RFC3720][RFC4173]. It also may be useful in situations 178 where it is necessary to update the boot image of a host 179 that supports a disk, such as in the Preboot eXecution 180 Environment (PXE) [PXE][RFC4578]. While strictly speaking 181 boot services operate above the Internet layer, where boot 182 service is used to obtain the Internet layer code, it may 183 be considered part of Internet layer configuration. 185 Other parameters 186 Internet layer parameter configuration also includes 187 configuration of per-host parameters (e.g. hostname) and 188 per-interface parameters (e.g. IP Time-To-Live (TTL) to 189 use in outgoing packets, enabling/disabling of IP 190 forwarding and source routing, and Maximum Transmission 191 Unit (MTU)). 193 Higher-layer configuration is defined as the configuration required 194 to support the operation of other components above the Internet 195 layer. This includes, for example: 197 Name Service Configuration 198 The configuration required for the host to resolve names. 199 This includes configuration of the addresses of name 200 resolution servers, including IEN 116 [IEN116], Domain 201 Name Service (DNS), Windows Internet Name Service (WINS), 202 Internet Storage Name Service (iSNS) [RFC4171][RFC4174] 203 and Network Information Service (NIS) servers [RFC3898], 204 and the setting of name resolution parameters such as the 205 NetBIOS node type, the DNS domain and search list 206 [RFC3397], etc. It may also include the transmission or 207 setting of the host's own name. Note that link local name 208 resolution services (such as NetBIOS [RFC1001], Link-Local 209 Multicast Name Resolution (LLMNR) [RFC4795] and multicast 210 DNS (mDNS) [mDNS]) typically do not require configuration. 212 Once the host has completed name service configuration, it 213 is capable of resolving names using name resolution 214 protocols that require configuration. This not only 215 allows the host to communicate with off-link hosts whose 216 IP address is not known, but to the extent that name 217 services requiring configuration are utilized for service 218 discovery, this also enables the host to discover services 219 available on the network or elsewhere. 221 Time Service Configuration 222 Time service configuration includes configuration of 223 servers for protocols such as the Simple Network Time 224 Protocol (SNTP) and the Network Time Protocol (NTP). 225 Since accurate determination of the time may be important 226 to operation of the applications running on the host 227 (including security services), configuration of time 228 servers may be a prerequisite for higher layer operation. 229 However, it is typically not a requirement for Internet 230 layer configuration. 232 Other service configuration 233 This can include discovery of additional servers and 234 devices, such as printers, Session Initiation Protocol 235 (SIP) proxies, etc. 237 2. Principles 239 This section describes basic principles of Internet host 240 configuration. 242 2.1. Minimize Configuration 244 Anything that can be configured can be misconfigured. "Architectural 245 Principles of the Internet" [RFC1958] Section 3.8 states: "Avoid 246 options and parameters whenever possible. Any options and parameters 247 should be configured or negotiated dynamically rather than manually." 249 That is, to minimize the possibility of configuration errors, 250 parameters should be automatically computed (or at least have 251 reasonable defaults) whenever possible. For example, the Path 252 Maximum Transmission Unit (PMTU) can be discovered, as described in 253 "Packetization Layer Path MTU Discovery" [RFC4821], "TCP Problems 254 with Path MTU Discovery" [RFC2923], "Path MTU discovery" [RFC1191] 255 and "Path MTU Discovery for IP version 6" [RFC1981]. 257 Having a protocol design with many configurable parameters increases 258 the possibilities for misconfiguration of those parameters, resulting 259 in failures or other sub-optimal operation. Eliminating or reducing 260 configurable parameters helps lessen this risk. Where configurable 261 parameters are necessary or desirable, protocols can reduce the risk 262 of human error by making these parameters self-configuring, such as 263 by using capability negotiation within the protocol, or by discovery 264 of other hosts that implement the same protocol. 266 2.2. Less is More 268 The availability of standardized, simple mechanisms for general- 269 purpose Internet host configuration is highly desirable. RFC 1958 270 [RFC1958] states, "Performance and cost must be considered as well as 271 functionality" and "Keep it simple. When in doubt during design, 272 choose the simplest solution." 274 To allow protocol support in more types of devices, it is important 275 to minimize the footprint requirement. For example, IP-based 276 protocols are used on a wide range of devices, from supercomputers 277 to small low-cost devices running "embedded" operating systems. 278 Since the resources (e.g. memory and code size) available for host 279 configuration may be very small, it is desirable for a host to be 280 able to configure itself in as simple a manner as possible. 282 One interesting example is IP support in pre-boot execution 283 environments. Since by definition boot configuration is required in 284 hosts that have not yet fully booted, it is often necessary for pre- 285 boot code to be executed from Read Only Memory (ROM), with minimal 286 available memory. Many hosts do not have enough space in this ROM 287 for even a simple implementation of TCP, so in the Pre-boot Execution 288 Environment (PXE) the task of obtaining a boot image has to be 289 performed using the User Datagram Protocol over IP (UDP/IP) [RFC768] 290 instead. This is one reason why Internet layer configuration 291 mechanisms typically depend only on IP and UDP. After obtaining the 292 boot image, the host will have the full facilities of TCP/IP 293 available to it, including support for reliable transport protocols, 294 IPsec, etc. 296 In order to reduce complexity, it is desirable for Internet layer 297 configuration mechanisms to avoid dependencies on higher layers. 298 Since embedded devices may be severely constrained on how much code 299 they can fit within their ROM, designing a configuration mechanism in 300 such a way that it requires the availability of higher layer 301 facilities may make that configuration mechanism unusable in such 302 devices. In fact, it cannot even be guaranteed that all Internet 303 layer facilities will be available. For example, the minimal version 304 of IP in a host's boot ROM may not implement IP fragmentation and 305 reassembly. 307 2.3. Minimize Diversity 309 The number of host configuration mechanisms should be minimized. 310 Diversity in Internet host configuration mechanisms presents several 311 problems: 313 Interoperability As configuration diversity increases, it becomes 314 likely that a host will not support the 315 configuration mechanism(s) available on the 316 network to which it has attached, creating 317 interoperability problems. 319 Footprint For maximum interoperability, a host would need to 320 implement all configuration mechanisms used on all 321 the link layers it supports. This increases the 322 required footprint, a burden for embedded devices. 323 It also leads to lower quality, since testing 324 resources (both formal testing, and real-world 325 operational use) are spread more thinly -- the 326 more different configuration mechanisms a device 327 supports, the less testing each one is likely to 328 undergo. 330 Redundancy To support diversity in host configuration 331 mechanisms, operators would need to support 332 multiple configuration services to ensure that 333 hosts connecting to their networks could configure 334 themselves. This represents an additional expense 335 for little benefit. 337 Latency As configuration diversity increases, hosts 338 supporting multiple configuration mechanisms may 339 spend increasing effort to determine which 340 mechanism(s) are supported. This adds to 341 configuration latency. 343 Conflicts Whenever multiple mechanisms are available, it is 344 possible that multiple configuration(s) will be 345 returned. To handle this, hosts would need to 346 merge potentially conflicting configurations. 347 This would require conflict resolution logic, such 348 as ranking of potential configuration sources, 349 increasing implementation complexity. 351 Additional traffic To limit configuration latency, hosts may 352 simultaneously attempt to obtain configuration by 353 multiple mechanisms. This can result in 354 increasing on-the-wire traffic, both from use of 355 multiple mechanisms as well as from 356 retransmissions within configuration mechanisms 357 not implemented on the network. 359 Security Support for multiple configuration mechanisms 360 increases the attack surface without any potential 361 benefit. 363 2.4. Lower Layer Independence 365 "Architectural Principles of the Internet" [RFC1958] states, 366 "Modularity is good. If you can keep things separate, do so." 368 It is becoming increasingly common for hosts to support multiple 369 network access mechanisms, including dialup, wireless and wired local 370 area networks, wireless metropolitan and wide area networks, etc. 371 The proliferation of network access mechanisms makes it desirable for 372 hosts to be able to configure themselves on multiple networks without 373 adding configuration code specific to a new link layer. 375 As a result, it is highly desirable for Internet host configuration 376 mechanisms to be independent of the underlying lower layer. That is, 377 only the link layer protocol (whether it be a physical link, or a 378 virtual tunnel link) should be explicitly aware of link-layer 379 parameters (although it may configure them). Introduction of lower 380 layer dependencies increases the likelihood of interoperability 381 problems and adds Internet layer configuration mechanisms that hosts 382 need to implement. 384 Lower layer dependencies can be best avoided by keeping Internet host 385 configuration above the link layer, thereby enabling configuration to 386 be handled for any link layer that supports IP. In order to provide 387 media independence, Internet host configuration mechanisms should be 388 link-layer protocol independent. 390 While there are examples of IP address assignment within the link 391 layer (such as in the Point-to-Point Protocol (PPP) IPv4CP [RFC1332] 392 and "Mobile radio interface Layer 3 specification; Core network 393 protocols; Stage 3 (Release 5)" [3GPP-24.008]), the disadvantages of 394 this approach have now become apparent. This includes the extra 395 complexity of implementing different mechanisms on different link 396 layers, and the difficulty in adding new parameters which would 397 require defining a mechanism in each link layer protocol. 399 For example, PPP IPv4CP and "Internet Protocol Control Protocol 400 (IPCP) Extensions for Name Service Configuration" [RFC1877] were 401 developed at a time when the Dynamic Host Configuration Protocol 402 (DHCP) [RFC2131] had not yet been widely implemented on access 403 devices or in service provider networks. However, the world has 404 changed since 1995, and if we were designing IPv4CP today, it would 405 probably make use of DHCP instead of duplicating that functionality. 406 Indeed, in IPv6 where link layer independent mechanisms such as "IPv6 407 Stateless Address Autoconfiguration" [RFC4862] and "Stateless Dynamic 408 Host Configuration Protocol (DHCP) Service for IPv6" [RFC3736] are 409 available, PPP IPv6CP [RFC5072] instead simply configures an 410 Interface-Identifier which is similar to a MAC address. This enables 411 PPP IPv6CP to avoid duplicating DHCPv6 functionality. The design of 412 IPv4CP was appropriate in 1995, but should not be taken as an example 413 that new link layer technologies should emulate. 415 In contrast, Internet Key Exchange Version 2 (IKEv2) [RFC4306] 416 utilizes the same approach as PPP IPv4CP by defining a Configuration 417 Payload for Internet host configuration for both IPv4 and IPv6. As 418 pointed out in "Dynamic Host Configuration Protocol (DHCPv4) 419 Configuration of IPsec Tunnel Mode" [RFC3456], leveraging DHCP has 420 advantages in terms of address management integration, address pool 421 management, reconfiguration and fail-over. On the other hand, the 422 IKEv2 approach reduces the number of exchanges. 424 Extensions to link layer protocols for the purpose of Internet, 425 transport or application layer configuration (including server 426 configuration) should be avoided. Such extensions can negatively 427 affect the properties of a link as seen by higher layers. For 428 example, if a link layer protocol (or tunneling protocol) configures 429 individual IPv6 addresses and precludes using any other addresses, 430 then applications that desire "Privacy Extensions for Stateless 431 Address Autoconfiguration in IPv6" [RFC4941] may not function well. 432 Similar issues may arise for other types of addresses, such as 433 Cryptographically Generated Addresses [RFC3972]. 435 Avoiding lower layer dependencies is desirable even where the lower 436 layer is link independent. For example, while the Extensible 437 Authentication Protocol (EAP) may be run over any link satisfying its 438 requirements (see [RFC3748] Section 3.1), many link layers do not 439 support EAP and therefore Internet layer configuration mechanisms 440 with EAP dependencies would not be usable on all links that support 441 IP. 443 2.5. Configuration is Not Access Control 445 Network access authentication and authorization is a distinct problem 446 from Internet host configuration. Therefore network access 447 authentication and authorization is best handled independently of the 448 Internet and higher layer configuration mechanisms. 450 Having an Internet (or higher) layer protocol authenticate clients is 451 appropriate to prevent resource exhaustion of a scarce resource on 452 the server (such as IP addresses or prefixes), but not for preventing 453 hosts from obtaining access to a link. If the user can manually 454 configure the host, requiring authentication in order to obtain 455 configuration parameters (such as an IP address) has little value. 456 Network administrators who wish to control access to a link can 457 achieve this better using technologies like Port Based Network Access 458 Control [IEEE-802.1X]. Note that client authentication is not 459 required for Stateless DHCPv6 [RFC3736] since it does not result in 460 allocation of any limited resources on the server. 462 3. Additional Discussion 464 3.1. Reliance on General Purpose Mechanisms 466 Protocols should either be self-configuring (especially where fate 467 sharing is important), or use general-purpose configuration 468 mechanisms (such as DHCP or a service discovery protocol, as noted in 469 Section 3.2). The choice should be made taking into account the 470 architectural principles discussed in Section 2. 472 Taking into account the availability of existing general-purpose 473 configuration mechanisms, we see little need for development of 474 additional general-purpose configuration mechanisms. 476 When defining a new host parameter, protocol designers should first 477 consider whether configuration is indeed necessary (see Section 2.1). 478 If configuration is necessary, in addition to considering fate 479 sharing (see Section 3.3), protocol designers should consider: 481 1. The organizational implications for administrators. For 482 example, routers and servers are often administered by 483 different sets of individuals, so that configuring a router 484 with server parameters may require cross-group collaboration. 486 2. Whether the parameter is a per-interface or a per-host 487 parameter. For example, configuration protocols 488 such as DHCP run on a per-interface basis and hence 489 are more appropriate for per-interface parameters. 491 3.2. Relationship between IP Configuration and Service Discovery 493 Higher-layer configuration often includes configuring server 494 addresses. The question arises as to how this differs from "service 495 discovery" as provided by Service Discovery protocols such as the 496 Service Location Protocol Version 2 (SLPv2) [RFC2608] or DNS-Based 497 Service Discovery (DNS-SD) [DNS-SD]. 499 In Internet host configuration mechanisms such as DHCP, if multiple 500 server instances are provided, they are considered interchangeable. 501 For example, in a list of time servers, the servers are considered 502 interchangeable because they all provide the exact same service -- 503 telling you the current time. In a list of local caching DNS 504 servers, the servers are considered interchangeable because they all 505 should give you the same answer to any DNS query. In service 506 discovery protocols, on the other hand, a host desires to find a 507 server satisfying a particular set of criteria, which may vary by 508 request. When printing a document, it is not the case that any 509 printer will do. The speed, capabilities, and physical location of 510 the printer matter to the user. 512 Information learned via DHCP is typically learned once, at boot time, 513 and after that may be updated only infrequently (e.g. on DHCP lease 514 renewal), if at all. This makes it appropriate for information that 515 is relatively static and unchanging over these time intervals. Boot- 516 time discovery of server addresses is appropriate for service types 517 where there are a small number of interchangeable servers that are of 518 interest to a large number of clients. For example, listing time 519 servers in a DHCP packet is appropriate because an organization may 520 typically have only two or three time servers, and most hosts will be 521 able to make use of that service. Listing all the printers or file 522 servers at an organization is a lot less useful, because the list may 523 contain hundreds or thousands of entries, and on a given day a given 524 user may not use any of the printers in that list. 526 Service discovery protocols can support discovery of servers on the 527 Internet, not just those within the local administrative domain. For 528 example, see "Remote Service Discovery in the Service Location 529 Protocol (SLP) via DNS SRV" [RFC3832] and DNS-Based Service Discovery 530 [DNS-SD]. Internet host configuration mechanisms such as DHCP, on 531 the other hand, typically assume the server(s) in the local 532 administrative domain contain the authoritative set of information. 534 For the service discovery problem (i.e., where the criteria varies on 535 a per-request basis, even from the same host), protocols should 536 either be self-discovering (if fate sharing is critical), or use 537 general purpose service discovery mechanisms. 539 In order to avoid a dependency on multicast routing, it is necessary 540 for a host to either restrict discovery to services on the local link 541 or to discover the location of a Directory Agent (DA). Since the DA 542 may not be available on the local link, service discovery beyond the 543 local link is typically dependent on a mechanism for configuring the 544 DA address or name. As a result, service discovery protocols can 545 typically not be relied upon for obtaining basic Internet layer 546 configuration, although they can be used to obtain higher-layer 547 configuration parameters. 549 3.2.1. Fate Sharing 551 If a server (or set of servers) is needed to get a set of 552 configuration parameters, "fate sharing" ([RFC1958], Section 2.3) is 553 preserved if the servers are ones without which the parameters could 554 not be used, even if they were obtained via other means. The 555 possibility of incorrect information being configured is minimized if 556 there is only one machine which is authoritative for the information 557 (i.e., there is no need to keep multiple authoritative servers in 558 sync). For example, learning default gateways via Router 559 Advertisements provides perfect fate sharing. That is, gateway 560 addresses can be obtained if and only if they can actually be used. 561 Similarly, obtaining DNS server configuration from a DNS server would 562 provide fate sharing since the configuration would only be obtainable 563 if the DNS server were available. 565 While fate sharing is a desirable property of a configuration 566 mechanism, in a number of situations fate sharing may be unavailable. 567 When utilized to discover services on the local link, service 568 discovery protocols typically provide for fate sharing, since hosts 569 providing service information typically also provide the services. 570 However, this is no longer the case when service discovery is 571 assisted by a Directory Agent (DA). First of all, the DA's list of 572 operational servers may not be current, so that it is possible for 573 the DA to provide clients with service information that is out of 574 date. For example, a DA's response to a client's service discovery 575 query may contain stale information about servers that are no longer 576 operational. Similarly, recently introduced servers might not yet 577 have registered themselves with the DA. Furthermore, the use of a DA 578 for service discovery also introduces a dependency on whether the DA 579 is operational, even though the DA is typically not involved in the 580 delivery of the service. 582 Similar limitations exist for other server-based configuration 583 mechanisms such as DHCP. Typically DHCP servers do not check for the 584 liveness of the configuration information they provide, or do not 585 discover new configuration information automatically. As a result, 586 there is no guarantee that configuration information will be current. 588 "IPv6 Host configuration of DNS Server Information Approaches" 589 [RFC4339] Section 3.3 discusses the use of well-known anycast 590 addresses for discovery of DNS servers. The use of anycast addresses 591 enables fate sharing, even where the anycast address is provided by 592 an unrelated server. However, in order to be universally useful, 593 this approach would require allocation of one or more well-known 594 anycast addresses for each service. Configuration of more than one 595 anycast address is desirable to allow the client to fail over faster 596 than would be possible from routing protocol convergence. 598 3.2.2. Discovering Names vs. Addresses 600 In discovering servers other than name resolution servers, it is 601 possible to either discover the IP addresses of the server(s), or to 602 discover names, each of which may resolve to a list of addresses. 604 It is typically more efficient to obtain the list of addresses 605 directly, since this avoids the extra name resolution steps and 606 accompanying latency. On the other hand, where servers are mobile, 607 the name to address binding may change, requiring a fresh set of 608 addresses to be obtained. Where the configuration mechanism does not 609 support fate sharing (e.g. DHCP), providing a name rather than an 610 address can simplify operations, assuming that the server's new 611 address is manually or automatically updated in the DNS; in this case 612 there is no need to re-do parameter configuration, since the name is 613 still valid. Where fate sharing is supported (e.g. service discovery 614 protocols), a fresh address can be obtained by re-initiating 615 parameter configuration. 617 In providing the IP addresses for a set of servers, it is desirable 618 to distinguish which IP addresses belong to which servers. If a 619 server IP address is unreachable, this enables the host to try the IP 620 address of another server, rather than another IP address of the same 621 server, in case the server is down. This can be enabled by 622 distinguishing which addresses belong to the same server. 624 3.2.3. Dual Stack Issues 626 One use for learning a list of interchangeable server addresses is 627 for fault tolerance, in case one or more of the servers are 628 unresponsive. Hosts will typically try the addresses in turn, only 629 attempting to use the second and subsequent addresses in the list if 630 the first one fails to respond quickly enough. In such cases, having 631 the list sorted in order of expected likelihood of success will help 632 clients get results faster. For hosts that support both IPv4 and 633 IPv6, it is desirable to obtain both IPv4 and IPv6 server addresses 634 within a single list. Obtaining IPv4 and IPv6 addresses in separate 635 lists, without indicating which server(s) they correspond to, 636 requires the host to use a heuristic to merge the lists. 638 For example, assume there are two servers, A and B, each with one 639 IPv4 address and one IPv6 address. If the first address the host 640 should try is (say) the IPv6 address of server A, then the second 641 address the host should try, if the first one fails, would generally 642 be the IPv4 address of server B. This is because the failure of the 643 first address could either be due to server A being down, or due to 644 some problem with the host's IPv6 address. Trying the IPv4 address 645 next is preferred since the reachability of the IPv4 address is 646 independent of both potential failure causes. 648 If the list of IPv4 server addresses were obtained separate from the 649 list of IPv6 server addresses, a host trying to merge the lists would 650 not know which IPv4 addresses belonged to the same server as the IPv6 651 address it just tried. This can be solved either by explicitly 652 distinguishing which addresses belong to which server or, more 653 simply, by configuring the host with a combined list of both IPv4 and 654 IPv6 addresses. Note that the same issue can arise with any 655 mechanism (e.g. DHCP, DNS, etc.) for obtaining server IP addresses. 657 Configuring a combined list of both IPv4 and IPv6 addresses gives the 658 configuration mechanism control over the ordering of addresses, as 659 compared with configuring a name and allowing the host resolver to 660 determine the address list ordering. See "DHCP Dual-Stack Issues" 661 [RFC4477] for more discussion of dual-stack issues in the context of 662 DHCP. 664 4. Security Considerations 666 Secure IP configuration presents a number of challenges. In addition 667 to denial-of-service and man-in-the-middle attacks, attacks on 668 configuration mechanisms may target particular parameters. For 669 example, attackers may target DNS server configuration in order to 670 support subsequent phishing or pharming attacks. A number of issues 671 exist with various classes of parameters, as discussed in Section 672 2.6, "IPv6 Neighbor Discovery (ND) Trust Models and Threats" 673 [RFC3756] Section 4.2.7, "Authentication for DHCP Messages" [RFC3118] 674 Section 1.1, and "Dynamic Host Configuration Protocol for IPv6 675 (DHCPv6)" [RFC3315] Section 23. Given the potential vulnerabilities 676 resulting from implementation of these options, it is currently 677 common for hosts to restrict support for DHCP options to the minimum 678 set required to provide basic TCP/IP configuration. 680 Since boot configuration determines the boot image to be run by the 681 host, a successful attack on boot configuration could result in an 682 attacker gaining complete control over a host. As a result, it is 683 particularly important that boot configuration be secured. 684 Approaches to boot configuration security are described in 685 "Bootstrapping Clients using the Internet Small Computer System 686 Interface (iSCSI) Protocol" [RFC4173] and "Preboot Execution 687 Environment (PXE) Specification" [PXE]. 689 4.1. Configuration Authentication 691 The techniques available for securing Internet layer configuration 692 are limited. While it is technically possible to perform a very 693 limited subset of IP networking operations without an IP address, the 694 capabilities are severely restricted; a host without an IP address 695 can only receive IP packets sent to the broadcast or multicast 696 address. Configuration of an IP address enables the use of IP 697 fragmentation; packets sent from the unknown address cannot be 698 reliably reassembled, since fragments from multiple hosts using the 699 unknown address might be reassembled into a single IP packet. 700 Without an IP address, it is not possible to take advantage of 701 security facilities such as IPsec, specified in "Security 702 Architecture for the Internet Protocol" [RFC4301], or Transport Layer 703 Security (TLS) [RFC5246]. As a result, configuration security is 704 typically implemented within the configuration protocols themselves. 706 PPP [RFC1661] does not support secure negotiation within IPv4CP 707 [RFC1332] or IPv6CP [RFC5072], enabling an attacker with access to 708 the link to subvert the negotiation. In contrast, IKEv2 [RFC4306] 709 provides encryption, integrity and replay protection for 710 configuration exchanges. 712 In situations where link layer security is provided, and the Network 713 Access Server (NAS) acts as a DHCP relay or server, protection can be 714 provided against rogue DHCP servers, provided that the NAS filters 715 incoming DHCP packets from unauthorized sources. However, explicit 716 dependencies on lower layer security mechanisms are limited by the 717 "lower layer independence" principle (see Section 2.4). 719 Internet layer secure configuration mechanisms include SEcure 720 Neighbor Discovery (SEND) [RFC3971] for IPv6 stateless address 721 autoconfiguration [RFC4862], or DHCP authentication for stateful 722 address configuration. DHCPv4 [RFC2131] initially did not include 723 support for security; this was added in "Authentication for DHCP 724 Messages" [RFC3118]. DHCPv6 [RFC3315] included security support. 725 However, DHCP authentication is not widely implemented for either 726 DHCPv4 or DHCPv6. 728 Higher layer configuration can make use of a wider range of security 729 techniques. When DHCP authentication is supported, higher-layer 730 configuration parameters provided by DHCP can be secured. However, 731 even if a host does not support DHCPv6 authentication, higher-layer 732 configuration via Stateless DHCPv6 [RFC3736] can still be secured 733 with IPsec. 735 Possible exceptions can exist where security facilities are not 736 available until later in the boot process. It may be difficult to 737 secure boot configuration even once the Internet layer has been 738 configured, if security functionality is not available until after 739 boot configuration has been completed. For example, it is possible 740 that Kerberos, IPsec or TLS will not be available until later in the 741 boot process; see "Bootstrapping Clients using the Internet Small 742 Computer System Interface (iSCSI) Protocol" [RFC4173] for discussion. 744 Where public key cryptography is used to authenticate and integrity- 745 protect configuration, hosts need to be configured with trust anchors 746 in order to validate received configuration messages. For a node 747 that visits multiple administrative domains, acquiring the required 748 trust anchors may be difficult. This is left as an area for future 749 work. 751 5. IANA Considerations 753 This document has no actions for IANA. 755 6. References 757 6.1. Informative References 759 [3GPP-24.008] 760 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 761 specification; Core network protocols; Stage 3 (Release 5)", 762 June 2003. 764 [IEN116] J. Postel, "Internet Name Server", IEN 116, August 1979, 765 http://www.ietf.org/rfc/ien/ien116.txt 767 [IEEE-802.1X] 768 Institute of Electrical and Electronics Engineers, "Local and 769 Metropolitan Area Networks: Port-Based Network Access 770 Control", IEEE Standard 802.1X-2004, December 2004. 772 [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service Discovery", 773 Internet-Draft (work in progress), draft-cheshire-dnsext-dns- 774 sd-04.txt, August 2006. 776 [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", June 2005. 777 http://files.multicastdns.org/draft-cheshire-dnsext- 778 multicastdns.txt 780 [PXE] Henry, M. and M. Johnston, "Preboot Execution Environment 781 (PXE) Specification", September 1999, 782 http://www.pix.net/software/pxeboot/archive/pxespec.pdf 784 [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August, 1980. 786 [RFC1001] NetBIOS Working Group in the Defense Advanced Research 787 Projects Agency, Internet Activities Board, and End-to-End 788 Services Task Force, "Protocol standard for a NetBIOS service 789 on a TCP/UDP transport: Concepts and methods", STD 19, RFC 790 1001, March 1987. 792 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 793 November 1990. 795 [RFC1332] McGregor, G., "PPP Internet Control Protocol", RFC 1332, 796 Merit, May 1992. 798 [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 799 1350, July 1992. 801 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 802 1661, July 1994. 804 [RFC1877] Cobb, S., "PPP Internet Protocol Control Protocol Extensions 805 for Name Server Addresses", RFC 1877, December 1995. 807 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 808 1958, June 1996. 810 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for 811 IP version 6", RFC 1981, August 1996. 813 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 814 March 1997. 816 [RFC2608] Guttman, E., et al., "Service Location Protocol, Version 2", 817 RFC 2608, June 1999. 819 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, 820 September 2000. 822 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 823 RFC 3118, June 2001. 825 [RFC3315] Droms, R., Ed., Bound, J., Volz,, B., Lemon, T., Perkins, C. 826 and M. Carney, "Dynamic Host Configuration Protocol for IPv6 827 (DHCPv6)", RFC 3315, July 2003. 829 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 830 2002. 832 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 833 Protocol (DHCP) Domain Search Option", RFC 3397, November 834 2002. 836 [RFC3456] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host 837 Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel 838 Mode", RFC 3456, January 2003. 840 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, 841 C., Eisler, M. and D. Noveck, "Network File System (NFS) 842 version 4 Protocol", RFC 3530, April 2003. 844 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C. Chadalapaka, M. and E. 845 Zeidner, "Internet Small Computer Systems Interface (iSCSI)", 846 RFC 3720, April 2004. 848 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 849 (DHCP) Service for IPv6", RFC 3736, April 2004. 851 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 852 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 853 3748, June 2004. 855 [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 856 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 858 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 859 IPv6", RFC 3775, June 2004. 861 [RFC3832] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C. and W. 862 Jerome, "Remote Service Discovery in the Service Location 863 Protocol (SLP) via DNS SRV", RFC 3832, July 2004. 865 [RFC3898] Kalusivalingam, V., "Networking Information Service (NIS) 866 Configuration Options for Dynamic Host Configuration Protocol 867 for IPv6 (DHCPv6)", RFC 3898, October 2004. 869 [RFC3971] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. 870 Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 871 2005. 873 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 874 3972, March 2005. 876 [RFC4171] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C. and J. 877 Souza, "Internet Storage Name Service (iSNS), RFC 4171, 878 September 2005. 880 [RFC4173] Sarkar, P., Missimer, D. and C. Sapuntzakis, "Bootstrapping 881 Clients using the iSCSI Protocol", RFC 4173, September 2005. 883 [RFC4174] Monia, C., Tseng, J. and K. Gibbons, "The IPv4 Dynamic Host 884 Configuration Protocol (DHCP) Option for the Internet Storage 885 Name Service", RFC 4174, September 2005. 887 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet 888 Protocol", RFC 4301, December 2005. 890 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 891 4306, December 2005. 893 [RFC4339] Jeong, J., "IPv6 Host Configuration of DNS Server Information 894 Approaches", RFC 4339, February 2006. 896 [RFC4477] Chown, T., Venaas, S. and C. Strauf, "Dynamic Host 897 Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack 898 Issues", RFC 4477, May 2006. 900 [RFC4578] Johnston, M. and S. Venaas, "Dynamic Host Configuration 901 Protocol (DHCP) Options for the Intel Preboot eXecution 902 Environment (PXE)", RFC 4578, November 2006. 904 [RFC4795] Aboba, B., Thaler, D. and L. Esibov, "Link-Local Multicast 905 Name Resolution (LLMNR)", RFC 4795, January 2007. 907 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 908 Discovery", RFC 4821, March 2007. 910 [RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless Address 911 Autoconfiguration", RFC 4862, September 2007. 913 [RFC4941] Narten, T., Draves, R. and S. Krishnan, "Privacy Extensions 914 for Stateless Address Autoconfiguration in IPv6", RFC 4941, 915 September 2007. 917 [RFC5072] Varada, S., Haskins D. and E. Allen, "IP Version 6 over PPP", 918 RFC 5072, September 2007. 920 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 921 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 923 [STD3] Braden, R., "Requirements for Internet Hosts -- Communication 924 Layers", STD 3, RFC 1122, and "Requirements for Internet Hosts 925 -- Application and Support", STD 3, RFC 1123, October 1989. 927 Acknowledgments 929 Elwyn Davies, Bob Hinden, Pasi Eronen, Jari Arkko, Pekka Savola and 930 James Kempf provided valuable input on this document. 932 Appendix A - IAB Members at the time of this writing 934 Loa Andersson 935 Gonzalo Camarillo 936 Stuart Cheshire 937 Olaf Kolkman 938 Gregory Lebovitz 939 Barry Leiba 940 Kurtis Lindqvist 941 Andrew Malis 942 Danny McPherson 943 David Oran 944 Dave Thaler 945 Lixia Zhang 947 Authors' Addresses 949 Bernard Aboba 950 Microsoft Corporation 951 One Microsoft Way 952 Redmond, WA 98052 954 EMail: bernarda@microsoft.com 956 Dave Thaler 957 Microsoft Corporation 958 One Microsoft Way 959 Redmond, WA 98052 961 EMail: dthaler@microsoft.com 963 Loa Andersson 964 Acreo AB 966 EMail: loa@pi.se 968 Stuart Cheshire 969 Apple Computer, Inc. 970 1 Infinite Loop 971 Cupertino, CA 95014 973 EMail: rfc [at] stuartcheshire [dot] org 975 Full Copyright Statement 977 Copyright (C) The IETF Trust (2008). 979 This document is subject to the rights, licenses and restrictions 980 contained in BCP 78, and except as set forth therein, the authors 981 retain all their rights. 983 This document and the information contained herein are provided on an 984 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 985 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 986 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 987 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 988 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 989 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 991 Intellectual Property 993 The IETF takes no position regarding the validity or scope of any 994 Intellectual Property Rights or other rights that might be claimed to 995 pertain to the implementation or use of the technology described in 996 this document or the extent to which any license under such rights 997 might or might not be available; nor does it represent that it has 998 made any independent effort to identify any such rights. Information 999 on the procedures with respect to rights in RFC documents can be 1000 found in BCP 78 and BCP 79. 1002 Copies of IPR disclosures made to the IETF Secretariat and any 1003 assurances of licenses to be made available, or the result of an 1004 attempt made to obtain a general license or permission for the use of 1005 such proprietary rights by implementers or users of this 1006 specification can be obtained from the IETF on-line IPR repository at 1007 http://www.ietf.org/ipr. 1009 The IETF invites any interested party to bring to its attention any 1010 copyrights, patents or patent applications, or other proprietary 1011 rights that may cover technology that may be required to implement 1012 this standard. Please address the information to the IETF at 1013 ietf-ipr@ietf.org. 1015 Acknowledgment 1017 Funding for the RFC Editor function is currently provided by the 1018 Internet Society.