idnits 2.17.1 draft-iab-link-encaps-05.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 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1092. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1069. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1076. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1082. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1098), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (9 October 2006) is 6408 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC1122' is mentioned on line 307, but not defined == Missing Reference: 'IEEE-802.11' is mentioned on line 470, but not defined == Unused Reference: 'IEEE-802.1D.2004' is defined on line 896, but no explicit reference was found in the text == Unused Reference: 'IEEE-802.3.2002' is defined on line 906, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 960, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1972 (Obsoleted by RFC 2464) -- Obsolete informational reference (is this intentional?): RFC 2472 (Obsoleted by RFC 5072, RFC 5172) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Aboba, Ed. 3 INTERNET-DRAFT Elwyn Davies 4 Category: Informational D. Thaler 5 Internet Architecture Board 6 9 October 2006 8 Multiple Encapsulation Methods Considered Harmful 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 1, 2007. 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). All Rights Reserved. 37 Abstract 39 This document describes architectural and operational issues that 40 arise from link layer protocols supporting multiple Internet Protocol 41 encapsulation methods. 43 Table of Contents 45 1. Introduction .......................................... 3 46 1.1 Terminology .................................... 3 47 1.2 Ethernet Experience ............................ 4 48 1.3 PPP Experience ................................. 7 49 1.4 Potential Mitigations .......................... 8 50 2. Evaluation of Arguments for Multiple Encapsulations ... 9 51 2.1 Efficiency ..................................... 9 52 2.2 Multicast/Broadcast ............................ 10 53 2.3 Multiple Uses .................................. 11 54 3. Additional Issues ..................................... 12 55 3.1 Generality ..................................... 13 56 3.2 Layer Interdependence .......................... 14 57 3.3 Inspection of Payload Contents ................. 14 58 3.4 Interoperability Guidance ...................... 15 59 3.5 Service Consistency ............................ 16 60 3.6 Implementation Complexity ...................... 16 61 3.7 Negotiation .................................... 17 62 3.8 Roaming ........................................ 17 63 4. Security Considerations ............................... 18 64 5. IANA Considerations ................................... 19 65 6. Conclusion ............................................ 19 66 7. References ............................................ 19 67 7.1 Informative References .......................... 19 68 Acknowledgments .............................................. 22 69 Appendix A - IAB Members ..................................... 23 70 Authors' Addresses ........................................... 23 71 Intellectual Property Statement .............................. 24 72 Disclaimer of Validity ....................................... 24 73 Copyright Statement .......................................... 24 74 1. Introduction 76 This document describes architectural and operational issues arising 77 from use of multiple ways of encapsulating IP packets on the same 78 link. 80 While typically a link layer protocol supports only a single Internet 81 Protocol (IP) encapsulation method, this is not always the case. For 82 example, on the same cable it is possible to encapsulate an IPv4 83 packet using Ethernet [DIX] encapsulation as defined in "A Standard 84 for the Transmission of IP Datagrams over Ethernet Networks" [RFC894] 85 or IEEE 802 [IEEE-802.1A.1990] encapsulation as defined in "A 86 Standard for the Transmission of IP Datagrams over IEEE 802 Networks" 87 [RFC1042]. Historically, a further encapsulation method was used on 88 some Ethernet systems as specified in "Trailer Encapsulations" 89 [RFC893]. 91 Similarly, both Point-to-Point Protocol (PPP) [RFC1661] and IEEE 92 802.16 [IEEE-802.16.2004] support multiple encapsulation mechanisms. 94 1.1. Terminology 96 Broadcast domain 97 The set of all endpoints that receive broadcast frames sent by an 98 endpoint in the set. 100 Classification 101 As defined in [IEEE-802.16e.2005], the process by which a Medium 102 Access Control (MAC) Service Data Unit (SDU) is mapped into a 103 particular transport connection for transmission between MAC peers. 105 Connection Identifier (CID) 106 In [IEEE-802.16e.2005] the connection identifier is a 16-bit value 107 that identifies a transport connection or a uplink (UL)/downlink 108 (DL) pair of associated management connections. A connection is a 109 unidirectional mapping between base station (BS) and subscriber 110 station (SS) MAC peers. Each transport connection has a particular 111 set of associated parameters indicating characteristics such as the 112 ciphersuite and quality-of-service. 114 Link A communication facility or medium over which nodes can communicate 115 at the link layer, i.e., the layer immediately below IP. 117 Link Layer 118 The conceptual layer of control or processing logic that is 119 responsible for maintaining control of the link. The link layer 120 functions provide an interface between the higher-layer logic and 121 the link. The link layer is the layer immediately below IP. 123 1.2. Ethernet Experience 125 The fundamental issues with multiple encapsulation methods on the 126 same link are described in [RFC1042] and "Requirements for Internet 127 Hosts -- Communication Layers" [RFC1122]. This section summarizes 128 the concerns articulated in those documents and also describes the 129 limitations of approaches suggested to mitigate the problems, 130 including encapsulation negotiation and use of routers. 132 [RFC1042] described the potential issues resulting from 133 contemporaneous use of Ethernet and IEEE 802.3 encapsulation on the 134 same physical cable: 136 Interoperation with Ethernet 138 It is possible to use the Ethernet link level protocol [DIX] on 139 the same physical cable with the IEEE 802.3 link level 140 protocol. A computer interfaced to a physical cable used in 141 this way could potentially read both Ethernet and 802.3 packets 142 from the network. If a computer does read both types of 143 packets, it must keep track of which link protocol was used 144 with each other computer on the network and use the proper link 145 protocol when sending packets. 147 One should note that in such an environment, link level 148 broadcast packets will not reach all the computers attached to 149 the network, but only those using the link level protocol used 150 for the broadcast. 152 Since it must be assumed that most computers will read and send 153 using only one type of link protocol, it is recommended that if 154 such an environment (a network with both link protocols) is 155 necessary, an IP gateway be used as if there were two distinct 156 networks. 158 Note that the MTU for the Ethernet allows a 1500 octet IP 159 datagram, with the MTU for the 802.3 network allows only a 1492 160 octet IP datagram. 162 When multiple IP encapsulation methods were supported on a given 163 link, all hosts could not be assumed to support the same set of 164 encapsulation methods. This in turn implied that the broadcast 165 domain might not include all hosts on the link. Where a single 166 encapsulation does not reach all hosts on the link, a host needs to 167 determine the appropriate encapsulation prior to sending. While a 168 host supporting reception of multiple encapsulations could keep track 169 of the encapsulations it receives, this does not enable initiation of 170 communication; supporting initiation requires a host to support 171 sending of multiple encapsulations in order to determine which one to 172 use. However, requiring hosts to send and receive multiple 173 encapsulations is a potentially onerous requirement. 175 [RFC1122], Section 2.3.3 notes the difficulties with this approach: 177 Furthermore, it is not useful or even possible for a dual-format 178 host to discover automatically which format to send, because of 179 the problem of link-layer broadcasts. 181 To enable hosts that only support sending and receiving of a single 182 encapsulation to communicate with each other, a router can be 183 utilized to segregate the hosts by encapsulation. Here only the 184 router needs to support sending and receiving of multiple 185 encapsulations. This requires assigning a separate unicast prefix to 186 each encapsulation, or else all hosts in the broadcast domain would 187 not be reachable with a single encapsulation. 189 [RFC1122] Section 2.3.3 provided guidance on encapsulation support: 191 Every Internet host connected to a 10Mbps Ethernet cable: 193 o MUST be able to send and receive packets using RFC-894 194 encapsulation; 196 o SHOULD be able to receive RFC-1042 packets, intermixed 197 with RFC-894 packets; and 199 o MAY be able to send packets using RFC-1042 encapsulation. 201 An Internet host that implements sending both the RFC-894 and 202 the RFC-1042 encapsulation MUST provide a configuration switch 203 to select which is sent, and this switch MUST default to RFC- 204 894. 206 By making Ethernet encapsulation mandatory to implement for both send 207 and receive, and also the default for sending, [RFC1122] recognized 208 Ethernet as the predominant encapsulation, heading off potential 209 interoperability problems. 211 1.2.1. Trailer Encapsulation 213 As noted in "Trailer Encapsulations" [RFC893], trailer encapsulation 214 was an optimization developed to minimize memory-to-memory copies on 215 reception. By placing variable length IP and transport headers at 216 the end of the packet, page alignment of data could be more easily 217 maintained. Trailers were implemented in 4.2 Berkeley System 218 Distribution (BSD) (among others). While in theory trailer 219 encapsulation could have been applied to both Ethernet and IEEE 802 220 encapsulations (creating four potential encapsulations of IP!), in 221 practice trailer encapsulation was only supported for Ethernet. A 222 separate Ethertype was utilized in order to enable IP packets in 223 trailer encapsulation to be distinguished from [RFC894] 224 encapsulation. 226 [RFC1122] Section 2.3.1 described the issues with trailer 227 encapsulation: 229 DISCUSSION 231 The trailer protocol is a link-layer encapsulation technique 232 that rearranges the data contents of packets sent on the 233 physical network. In some cases, trailers improve the 234 throughput of higher layer protocols by reducing the amount of 235 data copying within the operating system. Higher layer 236 protocols are unaware of trailer use, but both the sending and 237 receiving host MUST understand the protocol if it is used. 238 Improper use of trailers can result in very confusing symptoms. 239 Only packets with specific size attributes are encapsulated 240 using trailers, and typically only a small fraction of the 241 packets being exchanged have these attributes. Thus, if a 242 system using trailers exchanges packets with a system that does 243 not, some packets disappear into a black hole while others are 244 delivered successfully. 246 IMPLEMENTATION: 248 On an Ethernet, packets encapsulated with trailers use a 249 distinct Ethernet type [RFC893], and trailer negotiation is 250 performed at the time that ARP is used to discover the link- 251 layer address of a destination system. 253 Specifically, the ARP exchange is completed in the usual manner 254 using the normal IP protocol type, but a host that wants to 255 speak trailers will send an additional "trailer ARP reply" 256 packet, i.e., an ARP reply that specifies the trailer 257 encapsulation protocol type but otherwise has the format of a 258 normal ARP reply. If a host configured to use trailers 259 receives a trailer ARP reply message from a remote machine, it 260 can add that machine to the list of machines that understand 261 trailers, e.g., by marking the corresponding entry in the ARP 262 cache. 264 Hosts wishing to receive trailers send trailer ARP replies 265 whenever they complete exchanges of normal ARP messages for IP. 266 Thus, a host that received an ARP request for its IP protocol 267 address would send a trailer ARP reply in addition to the 268 normal IP ARP reply; a host that sent the IP ARP request would 269 send a trailer ARP reply when it received the corresponding IP 270 ARP reply. In this way, either the requesting or responding 271 host in an IP ARP exchange may request that it receive 272 trailers. 274 This scheme, using extra trailer ARP reply packets rather than 275 sending an ARP request for the trailer protocol type, was 276 designed to avoid a continuous exchange of ARP packets with a 277 misbehaving host that, contrary to any specification or common 278 sense, responded to an ARP reply for trailers with another ARP 279 reply for IP. This problem is avoided by sending a trailer ARP 280 reply in response to an IP ARP reply only when the IP ARP reply 281 answers an outstanding request; this is true when the hardware 282 address for the host is still unknown when the IP ARP reply is 283 received. A trailer ARP reply may always be sent along with an 284 IP ARP reply responding to an IP ARP request. 286 Since trailer encapsulation negotiation depends on ARP, it can only 287 be used where all hosts on the link are within the same broadcast 288 domain. It was assumed that all hosts supported sending and 289 receiving ARP packets in standard Ethernet encapsulation [RFC894], so 290 that negotiation between Ethernet and IEEE 802 encapsulation was not 291 required, only negotiation between standard Ethernet [RFC894] and 292 trailer [RFC893] encapsulation. Had hosts supporting trailer 293 encapsulation also supported IEEE 802 framing, the negotiation would 294 have been complicated still further. 296 [RFC1122] Section 2.3.1 provided the following guidance for use of 297 trailer encapsulation: 299 The trailer protocol for link-layer encapsulation MAY be used, but 300 only when it has been verified that both systems (host or gateway) 301 involved in the link-layer communication implement trailers. If 302 the system does not dynamically negotiate use of the trailer 303 protocol on a per-destination basis, the default configuration 304 MUST disable the protocol. 306 4.2BSD did not support dynamic negotiation, only configuration of 307 trailer encapsulation at boot time, and therefore [RFC1122] required 308 that the trailer encapsulation be disabled by default on those 309 systems. 311 1.3. PPP Experience 313 PPP can support both encapsulation of IEEE 802 frames as defined in 314 [RFC3518], as well as IPv4 and IPv6 [RFC2472] packets. Multiple 315 compression schemes are also supported. 317 In addition to PPP Data Link Layer (DLL) protocol numbers allocated 318 for IPv4 (0x0021) and IPv6 (0x0057), Bridging PDU (0x0031), two 319 codepoints have been assigned for RObust Header Compression (ROHC) 320 [RFC3095] (ROHC small-CID (0x0003), ROHC large-CIDE (0x0005)), two 321 for Van Jacobson compression [RFC1144] (Compressed TCP/IP (0x002d), 322 Uncompressed TCP/IP (002f)), one for IPv6 Header Compression 323 [RFC2507] (0x004f) and nine codepoints for RTP IP Header Compression 324 [RFC3544], (Full Header (0x0061), Compressed TCP (0x0063), Compressed 325 Non TCP (0x0065), UDP 8 (0x0067), RTP 8 (0x0069), Compressed TCP No 326 Delta (0x2063), Context State (0x2065), UDP 16 (0x2067), RTP 16 327 (0x2069)). 329 Although PPP can encapsulate IP packets in multiple ways, typically 330 multiple encapsulation schemes are not operational on the same link 331 and therefore the issues described in this document rarely arise. 332 For example, while PPP can support both encapsulation of IEEE 802 333 frames as defined in [RFC3518], as well as IPv4 and IPv6 [RFC2472] 334 packets, in practice multiple encapsulation mechanisms are not 335 operational on the same link. Similarly, only a single compression 336 scheme is typically negotiated for use on a link. 338 1.4. Potential Mitigations 340 In order to mitigate problems arising from multiple encapsulation 341 methods, it may be possible to use switches or routers, or to attempt 342 to negotiate the encapsulation method to be used. As described 343 below, neither approach may be completely satisfactory. 345 The use of switches or routers to enable communication between hosts 346 utilizing multiple encapsulation methods is not a panacea. If 347 separate unicast prefixes are used for each encapsulation, then the 348 choice of encapsulation can be determined from the routing table. If 349 the same unicast prefix is used for each encapsulation method, it is 350 necessary to keep state for each destination host. However, this may 351 not work in situations where hosts using different encapsulations 352 respond to the same anycast address. 354 In situations where multiple encapsulation methods are enabled on a 355 single link, negotiation may be supported to allow hosts to determine 356 how to encapsulate a packet for a particular destination host. 358 Negotiating the encapsulation above the link layer is potentially 359 problematic since the negotiation itself may need to be carried out 360 using multiple encapsulations. In theory it is possible to negotiate 361 an encapsulation method by sending negotiation packets over all 362 encapsulation methods supported, and keeping state for each 363 destination host. However, if the encapsulation method must be 364 dynamically negotiated for each new on-link destination, 365 communication to new destinations may be delayed. If most 366 communication is short, and the negotiation requires an extra round 367 trip beyond link-layer address resolution, this can become a 368 noticeable factor in performance. Also, the negotiation may result 369 in consumption of additional bandwidth. 371 2. Evaluation of Arguments for Multiple Encapsulations 373 There are several reasons often given in support of multiple 374 encapsulation methods. We discuss each in turn, below. 376 2.1. Efficiency 378 Claim: Multiple encapsulation methods allow for greater efficiency. 379 For example, it has been argued that IEEE 802 or Ethernet 380 encapsulation of IP results in excessive overhead due to the size of 381 the data frame headers, and that this can adversely affect 382 performance on wireless networks, particularly in situations where 383 support of Voice over IP (VOIP) is required. 385 Discussion: Even where these performance concerns are valid, 386 solutions exist that do not require defining multiple IP 387 encapsulation methods. For example, links may support Ethernet frame 388 compression so that Ethernet Source and Destination Address fields 389 are not sent with every packet. 391 It is possible for link layers to negotiate compression without 392 requiring higher layer awareness; the Point-to-Point Protocol (PPP) 393 [RFC1661] is an example. "The PPP Compression Control Protocol 394 (CCP)" [RFC1962] enables negotiation of data compression mechanisms, 395 and "Robust Header Compression (ROHC) over PPP" [RFC3241] and "IP 396 Header Compression over PPP" [RFC3544] enable negotiation of header 397 compression, without Internet layer awareness. Any frame can be 398 "decompressed" based on the content of the frame, and prior state 399 based on previous control messages or data frames. Use of 400 compression is a good way to solve the efficiency problem without 401 introducing problems at higher layers. 403 There are also situations in which use of multiple encapsulations can 404 degrade performance or result in packet loss. The use of multiple 405 encapsulation methods with differing Maximum Transfer Units (MTUs) 406 can result in differing MTUs for on-link destinations. If the link- 407 layer protocol does not provide per-destination MTUs to the IP layer, 408 it will need to use a default MTU; to avoid fragmentation this must 409 be less than or equal to the minimum MTU of on-link destinations. If 410 the default MTU is too low, the full bandwidth may not be achievable. 412 If the default MTU is too high, packet loss will result unless or 413 until IP Path MTU Discovery is used to discover the correct MTU. 415 Recommendation: Where encapsulation is an efficiency issue, use 416 header compression. Where the encapsulation method, or the use of 417 compression, must be negotiated, negotiation should either occur as 418 part of bringing up the link, or be piggybacked in the link-layer 419 address resolution exchange; only a single compression scheme should 420 be negotiated on a link. Where the MTU may vary among destinations 421 on the same link, the link layer protocol should provide a per 422 destination MTU to IP. 424 2.2. Multicast/Broadcast 426 Claim: Support for Ethernet encapsulation requires layer 2 support 427 for distribution of IP multicast/broadcast packets. In situations 428 where this is difficult, support for Ethernet is problematic and 429 other encapsulations are necessary. 431 Discussion: Irrespective of the encapsulation used, IP packets sent 432 to multicast (IPv4/IPv6) or broadcast addresses (IPv4) need to reach 433 all potential on-link receivers. Use of alternative encapsulations 434 cannot remove this requirement, although there is considerable 435 flexibility in how it can be met. Non-Broadcast Multiple Access 436 (NBMA) networks can still support the broadcast/multicast service via 437 replication of unicast frames. 439 Techniques are also available for improving the efficiency of IP 440 multicast/broadcast delivery in wireless networks. In order to be 441 receivable by any host within listening range, an IP 442 multicast/broadcast packet sent as link layer multicast/broadcast 443 over a wireless link needs to be sent at the lowest rate supported by 444 listeners. If the sender does not keep track of the rates negotiated 445 by group listeners, by default multicast/broadcast traffic is sent 446 at the lowest supported rate, resulting in increased overhead. 447 However, a sender can also deliver an IP multicast/broadcast packet 448 using unicast frame(s) where this would be more efficient. For 449 example, in IEEE 802.11, multicast/broadcast traffic sent from the 450 Station (STA) to the Access Point (AP) is always sent as unicast, and 451 the AP tracks the negotiated rate for each STA, so that it can send 452 unicast frames at a rate appropriate for each station. 454 In order to limit the propagation of link-scope multicast or 455 broadcast traffic, it is possible to assign a separate prefix to each 456 host. 458 Unlike broadcasts, which are received by all hosts on the link 459 regardless of the protocol they are running, multicasts only need be 460 received by those hosts belonging to the multicast group. In wired 461 networks, it is possible to avoid forwarding multicast traffic on 462 switch ports without group members, by snooping of Internet Group 463 Management Protocol (IGMP) and Multicast Listener Discovery (MLD) 464 traffic as described in "Considerations for IGMP and MLD Snooping 465 Switches" [RFC4541]. 467 In wireless media where data rates to specific destinations are 468 negotiated and may vary over a wide range, it may be more efficient 469 to send multiple frames via link layer unicast than to send a single 470 multicast/broadcast frame. For example, in [IEEE-802.11] 471 multicast/broadcast traffic from the client station (STA) to the 472 Access Point (AP) is sent via link layer unicast. 474 Recommendation: Where support for link layer multicast/broadcast is 475 problematic, limit the propagation of link-scope multicast and 476 broadcast traffic by assignment of separate prefixes to hosts. In 477 some circumstances, it may be more efficient to distribute 478 multicast/broadcast traffic as multiple link-layer unicast frames. 480 2.3. Multiple Uses 482 Claim: No single encapsulation is optimal for all purposes. 483 Therefore where a link layer is utilized in disparate scenarios (such 484 as both fixed and mobile deployments), multiple encapsulations are a 485 practical requirement. 487 Discussion: "Architectural Principles of the Internet" [RFC1958] 488 point 3.2 states: 490 If there are several ways of doing the same thing, choose one. If 491 a previous design, in the Internet context or elsewhere, has 492 successfully solved the same problem, choose the same solution 493 unless there is a good technical reason not to. Duplication of 494 the same protocol functionality should be avoided as far as 495 possible, without of course using this argument to reject 496 improvements. 498 Existing encapsulations have proven themselves capable of supporting 499 disparate usage scenarios. For example, the Point-to-Point Protocol 500 (PPP) has been utilized by wireless link layers such as GPRS, as well 501 as in wired networks in applications such as "PPP over SONET/SDH" 502 [RFC2615]. PPP can even support bridging, as described in "Point-to- 503 Point Protocol (PPP) Bridging Control Protocol (BCP)" [RFC3518]. 505 Similarly, Ethernet encapsulation has been used in wired networks as 506 well as Wireless Local Area Networks (LANs) such as IEEE 802.11 507 [IEEE-802.11.2003]. Ethernet can also support Virtual LANs (VLANs) 508 and Quality of Service (QoS) [IEEE-802.1Q.2003]. 510 Therefore disparate usage scenarios can be addressed by choice of a 511 single encapsulation, rather than multiple encapsulations. Where an 512 existing encapsulation is suitable, this is preferable to creating a 513 new encapsulation. 515 Where encapsulations other than IP over Point-to-Point Protocol (PPP) 516 [RFC1661], Ethernet or IEEE 802 are supported, difficulties in 517 operating system integration can lead to interoperability problems. 519 In order to take advantage of operating system support for IP 520 encapsulation over PPP, Ethernet or IEEE 802, it may be tempting for 521 a driver supporting an alternative encapsulation to emulate PPP, 522 Ethernet or IEEE 802 support. Typically, PPP emulation requires that 523 the driver implement PPP, enabling translation of PPP control and 524 data frames to the equivalent native facilities. Similarly, Ethernet 525 or IEEE 802 emulation typically requires that the driver implement 526 Dynamic Host Configuration Protocol (DHCP)v4 or v6, Router 527 Solicitation/Router Advertisement (RS/RA), Address Resolution 528 Protocol (ARP) or IPv6 Neighbor Discovery (ND) in order to enable 529 translation of these frames to and from native facilities. 531 Where drivers are implemented in kernel mode, the work required to 532 provide faithful emulation may be substantial. This creates the 533 temptation to cut corners, potentially resulting in interoperability 534 problems. 536 For example, it might be tempting for driver implementations to 537 neglect IPv6 support. A driver emulating PPP might support only 538 IPCP, but not IPCPv6; a driver emulating Ethernet or IEEE 802 might 539 support only DHCPv4 and ARP, but not DHCPv6, RS/RA or ND. As a 540 result, an IPv6 host connecting to a network supporting IPv6 might 541 find itself unable to use IPv6 due to lack of driver support. 543 Recommendation: Support a single existing encapsulation where 544 possible. Emulation of PPP, Ethernet or IEEE 802 on top of 545 alternative encapsulations should be avoided. 547 3. Additional Issues 549 There are a number of additional issues arising from use of multiple 550 encapsulation methods, as hinted at in section 1. We discuss each of 551 these below. 553 3.1. Generality 555 Link layer protocols such as [IEEE-802.1A.1990] and [DIX] inherently 556 support the ability to add support for a new packet type without 557 modification to the link layer protocol. 559 IEEE 802.16 [IEEE-802.16.2004] splits the Media Access Control (MAC) 560 layer into a number of sublayers. For the uppermost of these, the 561 standard defines the concept of a service-specific Convergence 562 Sublayer (CS). The two underlying sublayers (the MAC Common Part 563 Sublayer and the Security Sublayer) provide common services for all 564 instantiations of the CS. 566 While [IEEE-802.16.2004] defined support for the Asynchronous 567 Transfer Mode (ATM) CS and the Packet CS for raw IPv4, raw IPv6 and 568 Ethernet with a choice of six different classifieres, 569 [IEEE-802.16e.2005] added support for raw and Ethernet-framed ROHC 570 and ECRTP-compressed packets. As a result, [IEEE-802.16e.2005] 571 defines the ATM CS and multiple versions of the Packet CS for the 572 transmission of raw IPv4, raw IPv6, 802.3/Ethernet, 802.1Q VLAN, IPv4 573 over 802.3/Ethernet, IPv6 over 802.3/Ethernet, IPv4 over 802.1Q VLAN, 574 IPv6 over 802.1Q VLAN, raw ROHC compressed packets, raw ECRTP 575 compressed packets, ROHC compressed packets over 802.3/Ethernet and 576 ECRTP compressed packets over 802.3/Ethernet. 578 As noted in [Generic], [IEEE-802.16.2004] appears to imply that the 579 standard will need to be modified to support new packet types: 581 We are concerned that the 802.16 protocol cannot easily be 582 extendable to transport new protocols over the 802.16 air 583 interface. It would appear that a Convergence Sublayer is needed 584 for every type of protocol transported over the 802.16 MAC. Every 585 time a new protocol type needs to be transported over the 802.16 586 air interface, the 802.16 standard needs to be modified to define 587 a new CS type. We need to have a generic Packet Convergence 588 Sublayer that can support multi-protocols and which does not 589 require further modification to the 802.16 standard to support new 590 protocols. We believe that this was the original intention of the 591 Packet CS. Furthermore, we believe it is difficult for the 592 industry to agree on a set of CSes that all devices must implement 593 to claim "compliance". 595 The use of IP and/or upper layer protocol specific classification and 596 encapsulation methods, rather than a 'neutral' general purpose 597 encapsulation may give rise to a number of undesirable effects 598 explored in the following subsections. 600 If the link layer does not provide a general purpose encapsulation 601 method, deployment of new IP and/or upper layer protocols will be 602 dependent on deployment of the corresponding new encapsulation 603 support in the link layer. 605 Even if a single encapsulation method is used, problems can still 606 occur if de-multiplexing of ARP, IPv4, IPv6, and any other protocols 607 in use, is not supported at the link layer. While it is possible to 608 demultiplex such packets based on the Version field (first four bits 609 on the packet), this assumes that IPv4-only implementations will be 610 able to properly handle IPv6 packets. As a result, a more robust 611 design is to demultiplex protocols in the link layer, such as by 612 assigning a different protocol type, as is done in IEEE 802 media 613 where a Type of 0x0800 is used for IPv4, and 0x86DD for IPv6. 615 Recommendations: Link layer protocols should enable network packets 616 (IPv4, IPv6, ARP, etc.) to be de-multiplexed in the link layer. 618 3.2. Layer Interdependence 620 Within IEEE 802.16, the process by which frames are selected for 621 transmission on a connection identifier (CID) is known as 622 "classification". Fields in the Ethernet, IP and UDP/TCP headers can 623 be used for classification; for a particular CS a defined subset of 624 header fields may be applied for that purpose. 626 Utilizing IP and/or upper layer headers in link layer classification 627 will almost inevitably lead to interdependencies between link layer 628 and upper layer specifications. Although this might appear to be 629 desirable in terms of providing a highly specific (and hence 630 interoperable) mapping between the capabilities provided by the link 631 layer (e.g., quality of service support) and those that are needed by 632 upper layers, this sort of capability is probably better provided by 633 a more comprehensive service interface (Application Programming 634 Interface) in conjunction with a single encapsulation mechanism. 636 IPv6, in particular, provides an extensible header system. An upper 637 layer specific classification scheme would still have to provide a 638 degree of generality in order to cope with future extensions of IPv6 639 that might wish to make use of some of the link layer services 640 already provided. 642 Recommendations: Upper layer specific classification schemes should 643 be avoided. 645 3.3. Inspection of Payload Contents 647 If a classification scheme utilizing higher layer headers proposes to 648 inspect the contents of the packet being encapsulated (e.g., IEEE 649 802.16 IP CS mechanisms for determining the connection identifier 650 (CID) to use to transmit a packet), the fields available for 651 inspection may be limited if the packet is compressed or encrypted 652 before passing to the link layer. This may prevent the link layer 653 from utilizing existing compression mechanisms, such as Van Jacobson 654 Compression [RFC1144], ROHC [RFC3095][RFC3759], Compressed RTP (CRTP) 655 [RFC2508], Enhanced Compressed RTP (ECRTP) [RFC3545] or IP Header 656 Compression [RFC2507]. 658 Recommendations: Link layer classification schemes should not rely on 659 the contents of higher layer headers. 661 3.4. Interoperability Guidance 663 In situations where multiple encapsulation methods are operational 664 and capable of carrying IP traffic, interoperability problems are 665 possible in the absence of clear implementation guidelines. For 666 example, there is no guarantee that other hosts on the link will 667 support the same set of encapsulation methods, or that if they do, 668 that their routing tables will result in identical preferences. 670 In IEEE 802.16 the Subscriber Station (SS) indicates the Convergence 671 Sublayers it supports to the Base Station (BS), which selects from 672 the list one or more that it will support on the link. Therefore it 673 is possible for multiple CSes to be operational. 675 Note that IEEE 802.16 does not provide multiple encapsulation methods 676 for the same kind of data payload; it defines exactly one 677 encapsulation scheme for each data payload. For example, there is 678 one way to encapsulate a raw IPv4 packet into an IEEE 802.16 MAC 679 frame, one encapsulation scheme for a raw IPv6 packet, etc. There is 680 also one way to encapsulate an Ethernet frame, even when there are 681 multiple possibilities for classifying an Ethernet frame for 682 forwarding over a connection identifier (CID). Since support for 683 multiple CSes enables IEEE 802.16 to encapsulate layer 2 frames as 684 well as layer 3 packets, IP packets may be directly encapsulated in 685 IEEE 802.16 MAC frames as well as framed with Ethernet headers in 686 IEEE 802.16 MAC frames. Where CSes supporting both layer 2 frames as 687 well as layer 3 packets are operational on the same link, a number of 688 issues may arise, including: 690 Use of Address Resolution Protocol (ARP) 691 Where both IPv4 CS and Ethernet CS are operational on the same 692 link, it may not be obvious how address resolution should be 693 implemented. For example, should an ARP frame be encapsulated over 694 the Ethernet CS, or should alternative mechanisms be used for 695 address resolution, utilizing the IPv4 CS? 697 Data Frame Encapsulation 698 When sending an IP packet, which CS should be used? Where multiple 699 encapsulations are operational, multiple connection identifiers 700 (CIDs) will also be present. The issue can therefore be treated as 701 a multi-homing problem, with each CID constituting its own 702 interface. Since a given CID may have associated bandwidth or 703 quality of service constraints, routing metrics could be adjusted 704 to take this into account, allowing the routing layer to choose 705 based on which CID (and encapsulation) appears more attractive. 707 This could lead to interoperability problems or routing asymmetry. 708 For example, consider the effects on IPv6 Neighbor Discovery: 710 [a] If hosts choose to send IPv6 Neighbor Discovery traffic on 711 different CSes, it is possible that a host sending an IPv6 Neighbor 712 Discovery packet will not receive a reply, even though the target 713 host is reachable over another CS. 715 [b] Where hosts all support the same set of CSes, but have different 716 routing preferences, it is possible for a host to send an IPv6 717 Neighbor Discovery packet over one CS and receive a reply over 718 another CS. 720 Recommendations: Given these issues, it is strongly recommended that 721 only a single kind of CS supporting a single encapsulation method 722 should be usable on a particular link. 724 3.5. Service Consistency 726 If a link layer protocol provides multiple encapsulation methods, the 727 services offered to the IP and upper layer protocols may differ 728 qualitatively between the different encapsulation methods. For 729 example, the 802.16 [IEEE-802.16.2004] link layer protocol offers 730 both 'native' encapsulation for raw IPv4 and IPv6 packets, and 731 Ethernet encapsulation. In the raw case, the IP layer can be 732 directly mapped to the quality of service (QoS) capabilities of the 733 IEEE 802.16 transmission channels, whereas using the Ethernet 734 encapsulation an IP over Ethernet CS has to be deployed to circumvent 735 the mapping of the IP QoS to the Ethernet header fields to avoid the 736 limitations of Ethernet QoS. Consequently, the service offered to an 737 application depends on the classification method employed and may be 738 inconsistent between sessions. This may be confusing for the user 739 and the application. 741 Recommendations: If multiple encapsulation methods for IP packets on 742 a single link layer technology are deemed to be necessary, care 743 should be taken to match the services available between encapsulation 744 methods as closely as possible. 746 3.6. Implementation Complexity 748 Support of multiple encapsulation methods results in additional 749 implementation complexity. Lack of uniform encapsulation support 750 also results in potential interoperability problems. To avoid 751 interoperability issues, devices with limited resources may be 752 required to implement multiple encapsulation mechanisms, which may 753 not be practical. 755 When encapsulation methods require hardware support, implementations 756 may choose to support different encapsulation sets, resulting in 757 market fragmentation. This can prevent users from benefiting from 758 economies of scale, precluding some uses of the technology entirely. 760 Recommendations: Choose a single mandatory to implement 761 encapsulation mechanism for both sending and receiving, and make that 762 encapsulation mechanism the default for sending. 764 3.7. Negotiation 766 The complexity of negotiation within ARP or IP can be reduced by 767 performing encapsulation negotiation within the link layer. 769 However, unless the link layer allows the negotiation of the 770 encapsulation between any two hosts, then interoperability problems 771 can still result if more than one encapsulation is possible on a 772 given link. In general, a host cannot assume that all other hosts on 773 a link support the same set of encapsulation methods, so that unless 774 a link layer protocol only supports point-to-point communication, 775 negotiation of multiple potential encapsulation methods will be 776 problematic. To avoid this problem, it is desirable for link layer 777 encapsulation negotiation to determine a single IP encapsulation, not 778 merely to indicate which encapsulation methods are possible. 780 Recommendations: Encapsulation negotiation is best handled in the 781 link layer. In order to avoid dependencies on the data frame 782 encapsulation mechanism, it is preferable for the negotiation to be 783 carried out using management frames, if they are supported. If 784 multiple encapsulations are required and negotiation is provided, 785 then the negotiation should result in a single encapsulation method 786 being negotiated on the link. 788 3.8. Roaming 790 Where a mobile node roams between base stations or to a fixed 791 infrastructure and the base stations and fixed infrastructure do not 792 all support the same set of encapsulations, then it may be necessary 793 to alter the encapsulation method, potentially in mid-conversation. 795 Even if the change can be handled seamlessly at the link and IP layer 796 so that applications are not affected, unless the services offered 797 over the different encapsulations are equivalent (see Section 3.5) 798 the service experienced by the application may change as the mobile 799 node crosses boundaries. If the service is significantly different, 800 it might even require 'in-flight' renegotiation which most 801 applications are not equipped to manage. 803 Recommendations: Ensure uniformity of the encapsulation set 804 (preferably only a single encapsulation) within a given mobile 805 domain, between mobile domains, and between mobile domains and fixed 806 infrastructure. If a link layer protocol offers multiple 807 encapsulation methods for IP packets, it is strongly recommended that 808 only one of these encapsulation methods should be in use on any given 809 link or within a single wireless transmission domain. 811 4. Security Considerations 813 The use of multiple encapsulation methods does not appear to have 814 significant security implications. 816 An attacker might be able to utilize an encapsulation method which 817 was not in normal use on a link to cause a Denial of Service attack 818 which would exhaust the processing resources of interfaces if packets 819 utilizing this encapsulation were passed up the stack to any 820 significant degree before being discarded. 822 An attacker might be able to force a more cumbersome encapsulation 823 method between two endpoints, even when a lighter weight one is 824 available, hence forcing higher resource consumption on the link and 825 within those endpoints, or causing fragmentation. Since IP fragments 826 are more difficult to classify than non-fragments, this may result in 827 packet loss or may even expose security vulnerabilities [WEP]. 829 If different methods have different security properties, an attacker 830 might be able to force a less secure method as an elevation path to 831 get access to some other resource or data. Similarly, if one method 832 is rarely used, that method is potentially more likely to have 833 exploitable implementation bugs. 835 Since lower layer classification methods may need to inspect fields 836 in the packet being encapsulated, this might deter the deployment of 837 end-to-end security which is undesireable. Where encryption of 838 upper layer headers (e.g. IPsec tunnel mode) is required, this may 839 obscure headers required for classification. As a result, it may be 840 necessary for all encrypted traffic to flow over a single connection. 842 5. IANA Considerations 844 This document has no actions for IANA. 846 6. Conclusion 848 The use of multiple encapsulation methods on the same link is 849 problematic, as discussed above. 851 Although multiple IP encapsulation methods were defined on Ethernet 852 cabling, recent implementations support only the Ethernet 853 encapsulation of IPv4 defined in [RFC894]. In order to avoid a 854 repeat of the experience with IPv4, for operation of IPv6 on IEEE 855 802.3 media, only the Ethernet encapsulation was defined in "A Method 856 for the Transmission of IPv6 Packets over Ethernet Networks" 857 [RFC1972], later updated in [RFC2464]. 859 In addition to the recommendations given earlier, we give the 860 following general recommendations to avoid problems resulting from 861 use of multiple IP encapsulation methods: 863 When developing standards for encapsulating IP packets on a link 864 layer technology, it is desirable that only a single encapsulation 865 method should be standardized for each link layer technology; 867 If a link layer protocol offers multiple encapsulation methods for 868 IP packets, it is strongly recommended that only one of these 869 encapsulation methods should be in use within any given link; 871 Where multiple encapsulation methods are supported on a link, a 872 single encapsulation should be mandatory to implement for send and 873 receive. 875 7. References 877 7.1. Informative References 879 [DIX] Digital Equipment Corporation, Intel Corporation, 880 and Xerox Corporation, "The Ethernet -- A Local Area 881 Network: Data Link Layer and Physical Layer (Version 882 2.0)", November 1982. 884 [Generic] Wang, L. et al, "A Generic Packet Convergence 885 Sublayer (GPCS) for Supporting Multiple Protocols 886 over 802.16 Air Interface", Submission to IEEE 887 802.16g: CB0216g_05_025r4.pdf, November 2005, 888 . 891 [IEEE-802.1A.1990] Institute of Electrical and Electronics Engineers, 892 "Local Area Networks and Metropolitan Area Networks: 893 Overview and Architecture of Network Standards", 894 IEEE Standard 802.1A, 1990. 896 [IEEE-802.1D.2004] Institute of Electrical and Electronics Engineers, 897 "Information technology - Telecommunications and 898 information exchange between systems - Local area 899 networks - Media access control (MAC) bridges", IEEE 900 Standard 802.1D, 2004. 902 [IEEE-802.1Q.2003] IEEE Standards for Local and Metropolitan Area 903 Networks: Draft Standard for Virtual Bridged Local 904 Area Networks, P802.1Q-2003, January 2003. 906 [IEEE-802.3.2002] Institute of Electrical and Electronics Engineers, 907 "Carrier Sense Multiple Access with Collision 908 Detection (CSMA/CD) Access Method and Physical Layer 909 Specifications", IEEE Standard 802.3, 2002. 911 [IEEE-802.11.2003] Institute of Electrical and Electronics Engineers, 912 "Wireless LAN Medium Access Control (MAC) and 913 Physical Layer (PHY) Specifications", IEEE Standard 914 802.11, 2003. 916 [IEEE-802.16.2004] Institute of Electrical and Electronics Engineers, 917 "Information technology - Telecommunications and 918 information exchange between systems - Local and 919 metropolitan area networks, Part 16: Air Interface 920 for Fixed Broadband Wireless Access Systems", IEEE 921 Standard 802.16-2004, October 2004. 923 [IEEE-802.16e.2005] Institute of Electrical and Electronics Engineers, 924 "Information technology - Telecommunications and 925 information exchange between systems - Local and 926 Metropolitan Area Networks - Part 16: Air Interface 927 for Fixed and Mobile Broadband Wireless Access 928 Systems, Amendment for Physical and Medium Access 929 Control Layers for Combined Fixed and Mobile 930 Operation in Licensed Bands", IEEE P802.16e, 931 September 2005. 933 [RFC893] Leffler, S. and M. Karels, "Trailer encapsulations", 934 RFC 893, April 1984. 936 [RFC894] Hornig, C., "Standard for the transmission of IP 937 datagrams over Ethernet networks", STD 41, RFC 894, 938 April 1984. 940 [RFC1042] Postel, J. and J. Reynolds, "Standard for the 941 transmission of IP datagrams over IEEE 802 942 networks", STD 43, RFC 1042, February 1988. 944 [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low- 945 Speed Serial Links", RFC 1144, February 1990. 947 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", 948 STD 51, RFC 1661, July 1994. 950 [RFC1958] Carpenter, B., "Architectural Principles of the 951 Internet", RFC 1958, June 1996. 953 [RFC1962] Rand, D., "The PPP Compression Control Protocol 954 (CCP)", RFC 1962, June 1996. 956 [RFC1972] Crawford, M., "A Method for the Transmission of IPv6 957 Packets over Ethernet Networks", RFC 1972, August 958 1996. 960 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 961 Requirement Levels", BCP 14, RFC 2119, March 1997. 963 [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", 964 RFC 2472, December 1998. 966 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over 967 Ethernet Networks", RFC 2464, December 1998. 969 [RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header 970 Compression", RFC 2507, February 1999. 972 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 973 Headers for Low-Speed Serial Links", RFC 2508, 974 February 1999. 976 [RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 977 2615, June 1999. 979 [RFC3095] Bormann, C., et. al, "RObust Header Compression 980 (ROHC): Framework and four profiles: RTP, UDP, ESP 981 and uncompressed", RFC 3095, July 2001. 983 [RFC3241] Bormann, C., "Robust Header Compression (ROHC) over 984 PPP", RFC 3241, April 2002. 986 [RFC3518] Higashiyama, M., Baker, F. and T. Liao, "Point-to- 987 Point Protocol (PPP) Bridging Control Protocol 988 (BCP)", RFC 3518, April 2003. 990 [RFC3544] Koren, T., Casner, S. and C. Bormann, "IP Header 991 Compression over PPP", RFC 3544, July 2003. 993 [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, 994 B., and P. Ruddy, "Enhanced Compressed RTP (CRTP) 995 for Links with High Delay, Packet Loss and 996 Reordering", RFC 3545, July 2003. 998 [RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC): 999 Terminology and Channel Mapping Examples", RFC 3759, 1000 April 2004. 1002 [RFC4541] Christensen, M., Kimball, K. and F. Solensky, 1003 "Considerations for Internet Group Management 1004 Protocol (IGMP) and Multicast Listener Discovery 1005 (MLD) Snooping Switches", RFC 4541, May 2006. 1007 [WEP] Bittau, A., Handley, M. and J. Lackey, "The Final 1008 Nail in WEP's Coffin", Proceedings of the 2006 IEEE 1009 Symposium on Security and Privacy, pp. 386-400. 1011 Acknowledgments 1013 The authors would like to acknowledge Jeff Mandin, Bob Hinden, Jari 1014 Arkko, Max Riegel and Phil Roberts for contributions to this 1015 document. 1017 Appendix A - IAB Members at the time of this writing 1019 Bernard Aboba 1020 Loa Andersson 1021 Brian Carpenter 1022 Leslie Daigle 1023 Elwyn Davies 1024 Kevin Fall 1025 Olaf Kolkman 1026 Kurtis Lindqvist 1027 David Meyer 1028 David Oran 1029 Eric Rescorla 1030 Dave Thaler 1031 Lixia Zhang 1033 Authors' Addresses 1035 Bernard Aboba 1036 Microsoft Corporation 1037 One Microsoft Way 1038 Redmond, WA 98052 1040 EMail: bernarda@microsoft.com 1041 Phone: +1 425 706 6605 1042 Fax: +1 425 936 7329 1044 Elwyn B. Davies 1045 Consultant 1046 Soham, Cambs 1047 UK 1049 EMail: elwynd@dial.pipex.com 1050 Phone: +44 7889 488 335 1052 Dave Thaler 1053 Microsoft Corporation 1054 One Microsoft Way 1055 Redmond, WA 98052 1057 EMail: dthaler@microsoft.com 1058 Phone: +1 425 703 8835 1060 Intellectual Property Statement 1062 The IETF takes no position regarding the validity or scope of any 1063 Intellectual Property Rights or other rights that might be claimed to 1064 pertain to the implementation or use of the technology described in 1065 this document or the extent to which any license under such rights 1066 might or might not be available; nor does it represent that it has 1067 made any independent effort to identify any such rights. Information 1068 on the procedures with respect to rights in RFC documents can be 1069 found in BCP 78 and BCP 79. 1071 Copies of IPR disclosures made to the IETF Secretariat and any 1072 assurances of licenses to be made available, or the result of an 1073 attempt made to obtain a general license or permission for the use of 1074 such proprietary rights by implementers or users of this 1075 specification can be obtained from the IETF on-line IPR repository at 1076 http://www.ietf.org/ipr. 1078 The IETF invites any interested party to bring to its attention any 1079 copyrights, patents or patent applications, or other proprietary 1080 rights that may cover technology that may be required to implement 1081 this standard. Please address the information to the IETF at 1082 ietf-ipr@ietf.org. 1084 Disclaimer of Validity 1086 This document and the information contained herein are provided on an 1087 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1088 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1089 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1090 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1091 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1092 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1094 Copyright Statement 1096 Copyright (C) The Internet Society (2006). This document is subject 1097 to the rights, licenses and restrictions contained in BCP 78, and 1098 except as set forth therein, the authors retain all their rights. 1100 Acknowledgment 1102 Funding for the RFC Editor function is currently provided by the 1103 Internet Society.