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