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