idnits 2.17.1 draft-iab-link-encaps-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1189. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1200. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1207. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1213. 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.) -- The document date (25 January 2007) is 6272 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '108' on line 242 == Missing Reference: 'IEEE-802.11' is mentioned on line 558, but not defined == Unused Reference: 'IEEE-802.1D.2004' is defined on line 984, but no explicit reference was found in the text == Unused Reference: 'IEEE-802.3.2002' is defined on line 994, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 948 (Obsoleted by RFC 1042) -- Obsolete informational reference (is this intentional?): RFC 1010 (Obsoleted by RFC 1060) -- 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: 1 error (**), 0 flaws (~~), 4 warnings (==), 12 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 25 January 2007 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 July 25, 2007. 33 Copyright Notice 35 Copyright (C) The IETF Trust (2007). 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 ................................. 9 49 1.4 Potential Mitigations .......................... 10 50 2. Evaluation of Arguments for Multiple Encapsulations ... 11 51 2.1 Efficiency ..................................... 11 52 2.2 Multicast/Broadcast ............................ 12 53 2.3 Multiple Uses .................................. 13 54 3. Additional Issues ..................................... 14 55 3.1 Generality ..................................... 14 56 3.2 Layer Interdependence .......................... 16 57 3.3 Inspection of Payload Contents ................. 16 58 3.4 Interoperability Guidance ...................... 17 59 3.5 Service Consistency ............................ 18 60 3.6 Implementation Complexity ...................... 18 61 3.7 Negotiation .................................... 19 62 3.8 Roaming ........................................ 19 63 4. Security Considerations ............................... 20 64 5. IANA Considerations ................................... 20 65 6. Conclusion ............................................ 21 66 7. References ............................................ 21 67 7.1 Informative References .......................... 21 68 Acknowledgments .............................................. 24 69 Appendix A - IAB Members ..................................... 25 70 Authors' Addresses ........................................... 25 71 Intellectual Property Statement .............................. 26 72 Disclaimer of Validity ....................................... 26 73 Copyright Statement .......................................... 26 74 1. Introduction 76 This document describes architectural and operational issues arising 77 from the 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" 85 [RFC894], the IEEE 802.2/802.3 LLC Type 1 encapsulation defined in 86 "Two Methods For The Transmission of IP Datagrams over IEEE 802.3 87 Networks" [RFC948] or the IEEE 802 [IEEE-802.1A.1990] encapsulation 88 defined in "A Standard for the Transmission of IP Datagrams over IEEE 89 802 Networks" [RFC1042]. Historically, a further encapsulation 90 method was used on some Ethernet systems as specified in "Trailer 91 Encapsulations" [RFC893]. Similarly, ATM (e.g. see [RFC2684]), the 92 Point-to-Point Protocol (PPP) [RFC1661] and IEEE 802.16 93 [IEEE-802.16e.2005] also support multiple encapsulation mechanisms. 95 1.1. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 Broadcast domain 102 The set of all endpoints that receive broadcast frames sent by an 103 endpoint in the set. 105 Classification 106 As defined in [IEEE-802.16e.2005], the process by which a Medium 107 Access Control (MAC) Service Data Unit (SDU) is mapped into a 108 particular transport connection for transmission between MAC peers. 110 Connection Identifier (CID) 111 In [IEEE-802.16e.2005] the connection identifier is a 16-bit value 112 that identifies a transport connection or a uplink (UL)/downlink 113 (DL) pair of associated management connections. A connection is a 114 unidirectional mapping between base station (BS) and subscriber 115 station (SS) MAC peers. Each transport connection has a particular 116 set of associated parameters indicating characteristics such as the 117 ciphersuite and quality-of-service. 119 Link A communication facility or medium over which nodes can communicate 120 at the link layer, i.e., the layer immediately below IP. 122 Link Layer 123 The conceptual layer of control or processing logic that is 124 responsible for maintaining control of the link. The link layer 125 functions provide an interface between the higher-layer logic and 126 the link. The link layer is the layer immediately below IP. 128 1.2. Ethernet Experience 130 The fundamental issues with multiple encapsulation methods on the 131 same link are described in [RFC1042] and "Requirements for Internet 132 Hosts -- Communication Layers" [RFC1122]. This section summarizes 133 the concerns articulated in those documents and also describes the 134 limitations of approaches suggested to mitigate the problems, 135 including encapsulation negotiation and use of routers. 137 [RFC1042] described the potential issues resulting from 138 contemporaneous use of Ethernet and IEEE 802.3 encapsulations on the 139 same physical cable: 141 Interoperation with Ethernet 143 It is possible to use the Ethernet link level protocol [DIX] on 144 the same physical cable with the IEEE 802.3 link level protocol. 145 A computer interfaced to a physical cable used in this way could 146 potentially read both Ethernet and 802.3 packets from the network. 147 If a computer does read both types of packets, it must keep track 148 of which link protocol was used with each other computer on the 149 network and use the proper link protocol when sending packets. 151 One should note that in such an environment, link level broadcast 152 packets will not reach all the computers attached to the network, 153 but only those using the link level protocol used for the 154 broadcast. 156 Since it must be assumed that most computers will read and send 157 using only one type of link protocol, it is recommended that if 158 such an environment (a network with both link protocols) is 159 necessary, an IP gateway be used as if there were two distinct 160 networks. 162 Note that the MTU for the Ethernet allows a 1500 octet IP 163 datagram, with the MTU for the 802.3 network allows only a 1492 164 octet IP datagram. 166 When multiple IP encapsulation methods were supported on a given 167 link, all hosts could not be assumed to support the same set of 168 encapsulation methods. This in turn implied that the broadcast 169 domain might not include all hosts on the link. Where a single 170 encapsulation does not reach all hosts on the link, a host needs to 171 determine the appropriate encapsulation prior to sending. While a 172 host supporting reception of multiple encapsulations could keep track 173 of the encapsulations it receives, this does not enable initiation of 174 communication; supporting initiation requires a host to support 175 sending of multiple encapsulations in order to determine which one to 176 use. However, requiring hosts to send and receive multiple 177 encapsulations is a potentially onerous requirement. [RFC1122] 178 Section 2.3.3 notes the difficulties with this approach: 180 Furthermore, it is not useful or even possible for a dual-format 181 host to discover automatically which format to send, because of 182 the problem of link-layer broadcasts. 184 To enable hosts that only support sending and receiving of a single 185 encapsulation to communicate with each other, a router can be 186 utilized to segregate the hosts by encapsulation. Here only the 187 router needs to support sending and receiving of multiple 188 encapsulations. This requires assigning a separate unicast prefix to 189 each encapsulation, or else all hosts in the broadcast domain would 190 not be reachable with a single encapsulation. 192 [RFC1122] Section 2.3.3 provided guidance on encapsulation support: 194 Every Internet host connected to a 10Mbps Ethernet cable: 196 o MUST be able to send and receive packets using RFC-894 197 encapsulation; 199 o SHOULD be able to receive RFC-1042 packets, intermixed 200 with RFC-894 packets; and 202 o MAY be able to send packets using RFC-1042 encapsulation. 204 An Internet host that implements sending both the RFC-894 and the 205 RFC-1042 encapsulation MUST provide a configuration switch to 206 select which is sent, and this switch MUST default to RFC-894. 208 By making Ethernet encapsulation mandatory to implement for both send 209 and receive, and also the default for sending, [RFC1122] recognized 210 Ethernet as the predominant encapsulation, heading off potential 211 interoperability problems. 213 1.2.1. IEEE 802.2/802.3 LLC Type 1 Encapsulation 215 Prior to standardization of the IEEE 802 encapsulation in [RFC1042], 216 an IEEE 802.2/802.3 LLC Type 1 encapsulation was specified in 217 [RFC948], utilizing 6 in the Source Service Access Point (SSAP) and 218 Destination Service Access Point (DSAP) fields of the IEEE 802.2 219 header. However, since the SSAP and DSAP fields are each only a 220 single octet and the Ethertype values for IP, ARP [RFC826] and RARP 221 [RFC903] are greater than 1500, these values cannot be represented in 222 the SSAP and DSAP fields. As a result, the encapsulation described 223 in [RFC948] did not support protocols requiring distinct Ethertypes 224 such as ARP or RARP and implementations typically included support 225 for alternatives to ARP such as the the Probe [PROBE] protocol. 226 Support for ARP, RARP and other IP protocols utilizing distinct 227 Ethertypes was addressed in [RFC1042] which obsoleted [RFC948]. 228 [RFC1042] utilized the Sub-Network Access Protocol (SNAP) form of the 229 IEEE 802.2 Logical Link Control (LLC) with the SSAP and DSAP fields 230 set to 170, including support for the Ethertype field. As noted in 231 "Assigned Numbers" [RFC1010]: 233 At an ad hoc special session on "IEEE 802 Networks and ARP", held 234 during the TCP Vendors Workshop (August 1986), an approach to a 235 consistent way to send DoD-IP datagrams and other IP related 236 protocols on 802 networks was developed. 238 Due to some evolution of the IEEE 802.2 standards and the need to 239 provide for a standard way to do additional DoD-IP related 240 protocols (such as the Address Resolution Protocol (ARP) on IEEE 241 802 network, the following new policy is established, which will 242 replace the old policy (see RFC 960 and RFC 948 [108]). 244 The new policy is for the Internet community to use the IEEE 802.2 245 encapsulation on 802.3, 802.4, and 802.5 networks by using the 246 SNAP with an organization code indicating that the following 16 247 bits specify the EtherType code (where IP = 2048 (0800 hex), see 248 Ethernet Numbers of Interest). 250 Header 251 ...--------+--------+--------+ 252 MAC Header| Length | 802.{3/4/5} MAC 253 ...--------+--------+--------+ 255 +--------+--------+--------+ 256 | Dsap=K1| Ssap=K1| control| 802.2 SAP 257 +--------+--------+--------+ 259 +--------+--------+---------+--------+--------+ 260 |protocol id or org code =K2| Ether Type | 802.2 SNAP 261 +--------+--------+---------+--------+--------+ 263 The total length of the SAP Header and the SNAP header is 264 8-octets, making the 802.2 protocol overhead come out on a nice 265 boundary. 267 K1 is 170. The IEEE likes to talk about things in little-endian 268 bit transmission order and specifies this value as 01010101. In 269 big-endian order, as used in Internet specifications, this becomes 270 10101010 binary, or AA hex, or 170 decimal. 272 K2 is 0 (zero). 274 The use of the IP LSAP (K1 = 6) is to be phased out as quickly as 275 possible. 277 Many of issues involved in coexistence of the [RFC948] and [RFC1042] 278 encapsulations are similar to those described in Section 1.2. For 279 example, due to use of different SSAP/DSAP values, the broadcast 280 domain might not include all hosts on the link, and a host would need 281 to determine the appropriate encapsulation prior to sending. 282 However, the lack of support for ARP within the [RFC948] 283 encapsulation created additional interoperability and implementation 284 issues. For example, the lack of support for ARP in [RFC948] implied 285 that implementations supporting both [RFC948] and [RFC894] or 286 [RFC1042] encapsulations would need to implement both ARP and an 287 alternative address resolution mechanism such as Probe. Also, since 288 the address resolution mechanism for [RFC948] implementations was not 289 standardized, interoperability problems would likely have arisen had 290 [RFC948] been widely implemented. 292 1.2.2. Trailer Encapsulation 294 As noted in "Trailer Encapsulations" [RFC893], trailer encapsulation 295 was an optimization developed to minimize memory-to-memory copies on 296 reception. By placing variable length IP and transport headers at 297 the end of the packet, page alignment of data could be more easily 298 maintained. Trailers were implemented in 4.2 Berkeley System 299 Distribution (BSD) (among others). While in theory trailer 300 encapsulation could have been applied to the Ethernet [RFC894] or 301 IEEE 802 [RFC1042] encapsulations (creating four potential 302 encapsulations of IP!), in practice trailer encapsulation was only 303 supported for Ethernet. A separate Ethertype was utilized in order 304 to enable IP packets in trailer encapsulation to be distinguished 305 from [RFC894] encapsulation. Since the [RFC948] encapsulation did 306 not support the Ethertype field (or ARP), this mechanism could not 307 have been used in RFC 948 implementations. 309 [RFC1122] Section 2.3.1 described the issues with trailer 310 encapsulation: 312 DISCUSSION 314 The trailer protocol is a link-layer encapsulation technique 315 that rearranges the data contents of packets sent on the 316 physical network. In some cases, trailers improve the 317 throughput of higher layer protocols by reducing the amount of 318 data copying within the operating system. Higher layer 319 protocols are unaware of trailer use, but both the sending and 320 receiving host MUST understand the protocol if it is used. 321 Improper use of trailers can result in very confusing symptoms. 322 Only packets with specific size attributes are encapsulated 323 using trailers, and typically only a small fraction of the 324 packets being exchanged have these attributes. Thus, if a 325 system using trailers exchanges packets with a system that does 326 not, some packets disappear into a black hole while others are 327 delivered successfully. 329 IMPLEMENTATION: 331 On an Ethernet, packets encapsulated with trailers use a 332 distinct Ethernet type [RFC893], and trailer negotiation is 333 performed at the time that ARP is used to discover the link- 334 layer address of a destination system. 336 Specifically, the ARP exchange is completed in the usual manner 337 using the normal IP protocol type, but a host that wants to 338 speak trailers will send an additional "trailer ARP reply" 339 packet, i.e., an ARP reply that specifies the trailer 340 encapsulation protocol type but otherwise has the format of a 341 normal ARP reply. If a host configured to use trailers 342 receives a trailer ARP reply message from a remote machine, it 343 can add that machine to the list of machines that understand 344 trailers, e.g., by marking the corresponding entry in the ARP 345 cache. 347 Hosts wishing to receive trailers send trailer ARP replies 348 whenever they complete exchanges of normal ARP messages for IP. 349 Thus, a host that received an ARP request for its IP protocol 350 address would send a trailer ARP reply in addition to the 351 normal IP ARP reply; a host that sent the IP ARP request would 352 send a trailer ARP reply when it received the corresponding IP 353 ARP reply. In this way, either the requesting or responding 354 host in an IP ARP exchange may request that it receive 355 trailers. 357 This scheme, using extra trailer ARP reply packets rather than 358 sending an ARP request for the trailer protocol type, was 359 designed to avoid a continuous exchange of ARP packets with a 360 misbehaving host that, contrary to any specification or common 361 sense, responded to an ARP reply for trailers with another ARP 362 reply for IP. This problem is avoided by sending a trailer ARP 363 reply in response to an IP ARP reply only when the IP ARP reply 364 answers an outstanding request; this is true when the hardware 365 address for the host is still unknown when the IP ARP reply is 366 received. A trailer ARP reply may always be sent along with an 367 IP ARP reply responding to an IP ARP request. 369 Since trailer encapsulation negotiation depends on ARP, it can only 370 be used where all hosts on the link are within the same broadcast 371 domain. It was assumed that all hosts supported sending and 372 receiving ARP packets in standard Ethernet encapsulation [RFC894], so 373 that negotiation between Ethernet and IEEE 802 encapsulations was not 374 required, only negotiation between standard Ethernet [RFC894] and 375 trailer [RFC893] encapsulation. Had hosts supporting trailer 376 encapsulation also supported one or more IEEE 802 framing mechanisms, 377 the negotiation would have been complicated still further. For 378 example, since [RFC948] implementations did not support the Ethertype 379 field or ARP, the trailer negotiation mechanism could not have been 380 utilized, and additional difficulty would have been encountered in 381 distinguishing trailer encapsulated data frames from normally 382 encapsulated frames. 384 [RFC1122] Section 2.3.1 provided the following guidance for use of 385 trailer encapsulation: 387 The trailer protocol for link-layer encapsulation MAY be used, but 388 only when it has been verified that both systems (host or gateway) 389 involved in the link-layer communication implement trailers. If 390 the system does not dynamically negotiate use of the trailer 391 protocol on a per-destination basis, the default configuration 392 MUST disable the protocol. 394 4.2BSD did not support dynamic negotiation, only configuration of 395 trailer encapsulation at boot time, and therefore [RFC1122] required 396 that the trailer encapsulation be disabled by default on those 397 systems. 399 1.3. PPP Experience 401 PPP can support both encapsulation of IEEE 802 frames as defined in 402 [RFC3518], as well as IPv4 and IPv6 [RFC2472] packets. Multiple 403 compression schemes are also supported. 405 In addition to PPP Data Link Layer (DLL) protocol numbers allocated 406 for IPv4 (0x0021) and IPv6 (0x0057), Bridging PDU (0x0031), two 407 codepoints have been assigned for RObust Header Compression (ROHC) 408 [RFC3095] (ROHC small-CID (0x0003), ROHC large-CIDE (0x0005)), two 409 for Van Jacobson compression [RFC1144] (Compressed TCP/IP (0x002d), 410 Uncompressed TCP/IP (002f)), one for IPv6 Header Compression 412 [RFC2507] (0x004f) and nine codepoints for RTP IP Header Compression 413 [RFC3544], (Full Header (0x0061), Compressed TCP (0x0063), Compressed 414 Non TCP (0x0065), UDP 8 (0x0067), RTP 8 (0x0069), Compressed TCP No 415 Delta (0x2063), Context State (0x2065), UDP 16 (0x2067), RTP 16 416 (0x2069)). 418 Although PPP can encapsulate IP packets in multiple ways, typically 419 multiple encapsulation schemes are not operational on the same link 420 and therefore the issues described in this document rarely arise. 421 For example, while PPP can support both encapsulation of IEEE 802 422 frames as defined in [RFC3518], as well as IPv4 and IPv6 [RFC2472] 423 packets, in practice multiple encapsulation mechanisms are not 424 operational on the same link. Similarly, only a single compression 425 scheme is typically negotiated for use on a link. 427 1.4. Potential Mitigations 429 In order to mitigate problems arising from multiple encapsulation 430 methods, it may be possible to use switches or routers, or to attempt 431 to negotiate the encapsulation method to be used. As described 432 below, neither approach may be completely satisfactory. 434 The use of switches or routers to enable communication between hosts 435 utilizing multiple encapsulation methods is not a panacea. If 436 separate unicast prefixes are used for each encapsulation, then the 437 choice of encapsulation can be determined from the routing table. If 438 the same unicast prefix is used for each encapsulation method, it is 439 necessary to keep state for each destination host. However, this may 440 not work in situations where hosts using different encapsulations 441 respond to the same anycast address. 443 In situations where multiple encapsulation methods are enabled on a 444 single link, negotiation may be supported to allow hosts to determine 445 how to encapsulate a packet for a particular destination host. 447 Negotiating the encapsulation above the link layer is potentially 448 problematic since the negotiation itself may need to be carried out 449 using multiple encapsulations. In theory it is possible to negotiate 450 an encapsulation method by sending negotiation packets over all 451 encapsulation methods supported, and keeping state for each 452 destination host. However, if the encapsulation method must be 453 dynamically negotiated for each new on-link destination, 454 communication to new destinations may be delayed. If most 455 communication is short, and the negotiation requires an extra round 456 trip beyond link-layer address resolution, this can become a 457 noticeable factor in performance. Also, the negotiation may result 458 in consumption of additional bandwidth. 460 2. Evaluation of Arguments for Multiple Encapsulations 462 There are several reasons often given in support of multiple 463 encapsulation methods. We discuss each in turn, below. 465 2.1. Efficiency 467 Claim: Multiple encapsulation methods allow for greater efficiency. 468 For example, it has been argued that IEEE 802 or Ethernet 469 encapsulation of IP results in excessive overhead due to the size of 470 the data frame headers, and that this can adversely affect 471 performance on wireless networks, particularly in situations where 472 support of Voice over IP (VOIP) is required. 474 Discussion: Even where these performance concerns are valid, 475 solutions exist that do not require defining multiple IP 476 encapsulation methods. For example, links may support Ethernet frame 477 compression so that Ethernet Source and Destination Address fields 478 are not sent with every packet. 480 It is possible for link layers to negotiate compression without 481 requiring higher layer awareness; the Point-to-Point Protocol (PPP) 482 [RFC1661] is an example. "The PPP Compression Control Protocol 483 (CCP)" [RFC1962] enables negotiation of data compression mechanisms, 484 and "Robust Header Compression (ROHC) over PPP" [RFC3241] and "IP 485 Header Compression over PPP" [RFC3544] enable negotiation of header 486 compression, without Internet layer awareness. Any frame can be 487 "decompressed" based on the content of the frame, and prior state 488 based on previous control messages or data frames. Use of 489 compression is a good way to solve the efficiency problem without 490 introducing problems at higher layers. 492 There are also situations in which use of multiple encapsulations can 493 degrade performance or result in packet loss. The use of multiple 494 encapsulation methods with differing Maximum Transfer Units (MTUs) 495 can result in differing MTUs for on-link destinations. If the link- 496 layer protocol does not provide per-destination MTUs to the IP layer, 497 it will need to use a default MTU; to avoid fragmentation this must 498 be less than or equal to the minimum MTU of on-link destinations. If 499 the default MTU is too low, the full bandwidth may not be achievable. 500 If the default MTU is too high, packet loss will result unless or 501 until IP Path MTU Discovery is used to discover the correct MTU. 503 Recommendation: Where encapsulation is an efficiency issue, use 504 header compression. Where the encapsulation method, or the use of 505 compression, must be negotiated, negotiation should either occur as 506 part of bringing up the link, or be piggybacked in the link-layer 507 address resolution exchange; only a single compression scheme should 508 be negotiated on a link. Where the MTU may vary among destinations 509 on the same link, the link layer protocol should provide a per 510 destination MTU to IP. 512 2.2. Multicast/Broadcast 514 Claim: Support for Ethernet encapsulation requires layer 2 support 515 for distribution of IP multicast/broadcast packets. In situations 516 where this is difficult, support for Ethernet is problematic and 517 other encapsulations are necessary. 519 Discussion: Irrespective of the encapsulation used, IP packets sent 520 to multicast (IPv4/IPv6) or broadcast addresses (IPv4) need to reach 521 all potential on-link receivers. Use of alternative encapsulations 522 cannot remove this requirement, although there is considerable 523 flexibility in how it can be met. Non-Broadcast Multiple Access 524 (NBMA) networks can still support the broadcast/multicast service via 525 replication of unicast frames. 527 Techniques are also available for improving the efficiency of IP 528 multicast/broadcast delivery in wireless networks. In order to be 529 receivable by any host within listening range, an IP 530 multicast/broadcast packet sent as link layer multicast/broadcast 531 over a wireless link needs to be sent at the lowest rate supported by 532 listeners. If the sender does not keep track of the rates negotiated 533 by group listeners, by default multicast/broadcast traffic is sent 534 at the lowest supported rate, resulting in increased overhead. 535 However, a sender can also deliver an IP multicast/broadcast packet 536 using unicast frame(s) where this would be more efficient. For 537 example, in IEEE 802.11, multicast/broadcast traffic sent from the 538 Station (STA) to the Access Point (AP) is always sent as unicast, and 539 the AP tracks the negotiated rate for each STA, so that it can send 540 unicast frames at a rate appropriate for each station. 542 In order to limit the propagation of link-scope multicast or 543 broadcast traffic, it is possible to assign a separate prefix to each 544 host. 546 Unlike broadcasts, which are received by all hosts on the link 547 regardless of the protocol they are running, multicasts only need be 548 received by those hosts belonging to the multicast group. In wired 549 networks, it is possible to avoid forwarding multicast traffic on 550 switch ports without group members, by snooping of Internet Group 551 Management Protocol (IGMP) and Multicast Listener Discovery (MLD) 552 traffic as described in "Considerations for IGMP and MLD Snooping 553 Switches" [RFC4541]. 555 In wireless media where data rates to specific destinations are 556 negotiated and may vary over a wide range, it may be more efficient 557 to send multiple frames via link layer unicast than to send a single 558 multicast/broadcast frame. For example, in [IEEE-802.11] 559 multicast/broadcast traffic from the client station (STA) to the 560 Access Point (AP) is sent via link layer unicast. 562 Recommendation: Where support for link layer multicast/broadcast is 563 problematic, limit the propagation of link-scope multicast and 564 broadcast traffic by assignment of separate prefixes to hosts. In 565 some circumstances, it may be more efficient to distribute 566 multicast/broadcast traffic as multiple link-layer unicast frames. 568 2.3. Multiple Uses 570 Claim: No single encapsulation is optimal for all purposes. 571 Therefore where a link layer is utilized in disparate scenarios (such 572 as both fixed and mobile deployments), multiple encapsulations are a 573 practical requirement. 575 Discussion: "Architectural Principles of the Internet" [RFC1958] 576 point 3.2 states: 578 If there are several ways of doing the same thing, choose one. If 579 a previous design, in the Internet context or elsewhere, has 580 successfully solved the same problem, choose the same solution 581 unless there is a good technical reason not to. Duplication of 582 the same protocol functionality should be avoided as far as 583 possible, without of course using this argument to reject 584 improvements. 586 Existing encapsulations have proven themselves capable of supporting 587 disparate usage scenarios. For example, the Point-to-Point Protocol 588 (PPP) has been utilized by wireless link layers such as GPRS, as well 589 as in wired networks in applications such as "PPP over SONET/SDH" 590 [RFC2615]. PPP can even support bridging, as described in "Point-to- 591 Point Protocol (PPP) Bridging Control Protocol (BCP)" [RFC3518]. 593 Similarly, Ethernet encapsulation has been used in wired networks as 594 well as Wireless Local Area Networks (LANs) such as IEEE 802.11 595 [IEEE-802.11.2003]. Ethernet can also support Virtual LANs (VLANs) 596 and Quality of Service (QoS) [IEEE-802.1Q.2003]. 598 Therefore disparate usage scenarios can be addressed by choice of a 599 single encapsulation, rather than multiple encapsulations. Where an 600 existing encapsulation is suitable, this is preferable to creating a 601 new encapsulation. 603 Where encapsulations other than IP over Point-to-Point Protocol (PPP) 605 [RFC1661], Ethernet or IEEE 802 are supported, difficulties in 606 operating system integration can lead to interoperability problems. 608 In order to take advantage of operating system support for IP 609 encapsulation over PPP, Ethernet or IEEE 802, it may be tempting for 610 a driver supporting an alternative encapsulation to emulate PPP, 611 Ethernet or IEEE 802 support. Typically, PPP emulation requires that 612 the driver implement PPP, enabling translation of PPP control and 613 data frames to the equivalent native facilities. Similarly, Ethernet 614 or IEEE 802 emulation typically requires that the driver implement 615 Dynamic Host Configuration Protocol (DHCP)v4 or v6, Router 616 Solicitation/Router Advertisement (RS/RA), Address Resolution 617 Protocol (ARP) or IPv6 Neighbor Discovery (ND) in order to enable 618 translation of these frames to and from native facilities. 620 Where drivers are implemented in kernel mode, the work required to 621 provide faithful emulation may be substantial. This creates the 622 temptation to cut corners, potentially resulting in interoperability 623 problems. 625 For example, it might be tempting for driver implementations to 626 neglect IPv6 support. A driver emulating PPP might support only 627 IPCP, but not IPCPv6; a driver emulating Ethernet or IEEE 802 might 628 support only DHCPv4 and ARP, but not DHCPv6, RS/RA or ND. As a 629 result, an IPv6 host connecting to a network supporting IPv6 might 630 find itself unable to use IPv6 due to lack of driver support. 632 Recommendation: Support a single existing encapsulation where 633 possible. Emulation of PPP, Ethernet or IEEE 802 on top of 634 alternative encapsulations should be avoided. 636 3. Additional Issues 638 There are a number of additional issues arising from use of multiple 639 encapsulation methods, as hinted at in section 1. We discuss each of 640 these below. 642 3.1. Generality 644 Link layer protocols such as [IEEE-802.1A.1990] and [DIX] inherently 645 support the ability to add support for a new packet type without 646 modification to the link layer protocol. 648 IEEE 802.16 [IEEE-802.16.2004] splits the Media Access Control (MAC) 649 layer into a number of sublayers. For the uppermost of these, the 650 standard defines the concept of a service-specific Convergence 651 Sublayer (CS). The two underlying sublayers (the MAC Common Part 652 Sublayer and the Security Sublayer) provide common services for all 653 instantiations of the CS. 655 While [IEEE-802.16.2004] defined support for the Asynchronous 656 Transfer Mode (ATM) CS and the Packet CS for raw IPv4, raw IPv6 and 657 Ethernet with a choice of six different classifiers, 658 [IEEE-802.16e.2005] added support for raw and Ethernet-framed ROHC 659 Enhanced Compressed RTP (ECRTP) compressed packets. As a result, 660 [IEEE-802.16e.2005] defines the ATM CS and multiple versions of the 661 Packet CS for the transmission of raw IPv4, raw IPv6, 802.3/Ethernet, 662 802.1Q VLAN, IPv4 over 802.3/Ethernet, IPv6 over 802.3/Ethernet, IPv4 663 over 802.1Q VLAN, IPv6 over 802.1Q VLAN, raw ROHC compressed packets, 664 raw ECRTP compressed packets, ROHC compressed packets over 665 802.3/Ethernet and ECRTP compressed packets over 802.3/Ethernet. 667 As noted in [Generic], [IEEE-802.16.2004] appears to imply that the 668 standard will need to be modified to support new packet types: 670 We are concerned that the 802.16 protocol cannot easily be 671 extendable to transport new protocols over the 802.16 air 672 interface. It would appear that a Convergence Sublayer is needed 673 for every type of protocol transported over the 802.16 MAC. Every 674 time a new protocol type needs to be transported over the 802.16 675 air interface, the 802.16 standard needs to be modified to define 676 a new CS type. We need to have a generic Packet Convergence 677 Sublayer that can support multi-protocols and which does not 678 require further modification to the 802.16 standard to support new 679 protocols. We believe that this was the original intention of the 680 Packet CS. Furthermore, we believe it is difficult for the 681 industry to agree on a set of CSes that all devices must implement 682 to claim "compliance". 684 The use of IP and/or upper layer protocol specific classification and 685 encapsulation methods, rather than a 'neutral' general purpose 686 encapsulation may give rise to a number of undesirable effects 687 explored in the following subsections. 689 If the link layer does not provide a general purpose encapsulation 690 method, deployment of new IP and/or upper layer protocols will be 691 dependent on deployment of the corresponding new encapsulation 692 support in the link layer. 694 Even if a single encapsulation method is used, problems can still 695 occur if de-multiplexing of ARP, IPv4, IPv6, and any other protocols 696 in use, is not supported at the link layer. While it is possible to 697 demultiplex such packets based on the Version field (first four bits 698 on the packet), this assumes that IPv4-only implementations will be 699 able to properly handle IPv6 packets. As a result, a more robust 700 design is to demultiplex protocols in the link layer, such as by 701 assigning a different protocol type, as is done in IEEE 802 media 702 where a Type of 0x0800 is used for IPv4, and 0x86DD for IPv6. 704 Recommendations: Link layer protocols should enable network packets 705 (IPv4, IPv6, ARP, etc.) to be de-multiplexed in the link layer. 707 3.2. Layer Interdependence 709 Within IEEE 802.16, the process by which frames are selected for 710 transmission on a connection identifier (CID) is known as 711 "classification". Fields in the Ethernet, IP and UDP/TCP headers can 712 be used for classification; for a particular CS a defined subset of 713 header fields may be applied for that purpose. 715 Utilizing IP and/or upper layer headers in link layer classification 716 will almost inevitably lead to interdependencies between link layer 717 and upper layer specifications. Although this might appear to be 718 desirable in terms of providing a highly specific (and hence 719 interoperable) mapping between the capabilities provided by the link 720 layer (e.g., quality of service support) and those that are needed by 721 upper layers, this sort of capability is probably better provided by 722 a more comprehensive service interface (Application Programming 723 Interface) in conjunction with a single encapsulation mechanism. 725 IPv6, in particular, provides an extensible header system. An upper 726 layer specific classification scheme would still have to provide a 727 degree of generality in order to cope with future extensions of IPv6 728 that might wish to make use of some of the link layer services 729 already provided. 731 Recommendations: Upper layer specific classification schemes should 732 be avoided. 734 3.3. Inspection of Payload Contents 736 If a classification scheme utilizing higher layer headers proposes to 737 inspect the contents of the packet being encapsulated (e.g., IEEE 738 802.16 IP CS mechanisms for determining the connection identifier 739 (CID) to use to transmit a packet), the fields available for 740 inspection may be limited if the packet is compressed or encrypted 741 before passing to the link layer. This may prevent the link layer 742 from utilizing existing compression mechanisms, such as Van Jacobson 743 Compression [RFC1144], ROHC [RFC3095][RFC3759], Compressed RTP (CRTP) 744 [RFC2508], Enhanced Compressed RTP (ECRTP) [RFC3545] or IP Header 745 Compression [RFC2507]. 747 Recommendations: Link layer classification schemes should not rely on 748 the contents of higher layer headers. 750 3.4. Interoperability Guidance 752 In situations where multiple encapsulation methods are operational 753 and capable of carrying IP traffic, interoperability problems are 754 possible in the absence of clear implementation guidelines. For 755 example, there is no guarantee that other hosts on the link will 756 support the same set of encapsulation methods, or that if they do, 757 that their routing tables will result in identical preferences. 759 In IEEE 802.16 the Subscriber Station (SS) indicates the Convergence 760 Sublayers it supports to the Base Station (BS), which selects from 761 the list one or more that it will support on the link. Therefore it 762 is possible for multiple CSes to be operational. 764 Note that IEEE 802.16 does not provide multiple encapsulation methods 765 for the same kind of data payload; it defines exactly one 766 encapsulation scheme for each data payload. For example, there is 767 one way to encapsulate a raw IPv4 packet into an IEEE 802.16 MAC 768 frame, one encapsulation scheme for a raw IPv6 packet, etc. There is 769 also one way to encapsulate an Ethernet frame, even when there are 770 multiple possibilities for classifying an Ethernet frame for 771 forwarding over a connection identifier (CID). Since support for 772 multiple CSes enables IEEE 802.16 to encapsulate layer 2 frames as 773 well as layer 3 packets, IP packets may be directly encapsulated in 774 IEEE 802.16 MAC frames as well as framed with Ethernet headers in 775 IEEE 802.16 MAC frames. Where CSes supporting both layer 2 frames as 776 well as layer 3 packets are operational on the same link, a number of 777 issues may arise, including: 779 Use of Address Resolution Protocol (ARP) 780 Where both IPv4 CS and Ethernet CS are operational on the same 781 link, it may not be obvious how address resolution should be 782 implemented. For example, should an ARP frame be encapsulated over 783 the Ethernet CS, or should alternative mechanisms be used for 784 address resolution, utilizing the IPv4 CS? 786 Data Frame Encapsulation 787 When sending an IP packet, which CS should be used? Where multiple 788 encapsulations are operational, multiple connection identifiers 789 (CIDs) will also be present. The issue can therefore be treated as 790 a multi-homing problem, with each CID constituting its own 791 interface. Since a given CID may have associated bandwidth or 792 quality of service constraints, routing metrics could be adjusted 793 to take this into account, allowing the routing layer to choose 794 based on which CID (and encapsulation) appears more attractive. 796 This could lead to interoperability problems or routing asymmetry. 797 For example, consider the effects on IPv6 Neighbor Discovery: 799 [a] If hosts choose to send IPv6 Neighbor Discovery traffic on 800 different CSes, it is possible that a host sending an IPv6 Neighbor 801 Discovery packet will not receive a reply, even though the target 802 host is reachable over another CS. 804 [b] Where hosts all support the same set of CSes, but have different 805 routing preferences, it is possible for a host to send an IPv6 806 Neighbor Discovery packet over one CS and receive a reply over 807 another CS. 809 Recommendations: Given these issues, it is strongly recommended that 810 only a single kind of CS supporting a single encapsulation method 811 should be usable on a particular link. 813 3.5. Service Consistency 815 If a link layer protocol provides multiple encapsulation methods, the 816 services offered to the IP and upper layer protocols may differ 817 qualitatively between the different encapsulation methods. For 818 example, the 802.16 [IEEE-802.16.2004] link layer protocol offers 819 both 'native' encapsulation for raw IPv4 and IPv6 packets, and 820 Ethernet encapsulation. In the raw case, the IP layer can be 821 directly mapped to the quality of service (QoS) capabilities of the 822 IEEE 802.16 transmission channels, whereas using the Ethernet 823 encapsulation an IP over Ethernet CS has to be deployed to circumvent 824 the mapping of the IP QoS to the Ethernet header fields to avoid the 825 limitations of Ethernet QoS. Consequently, the service offered to an 826 application depends on the classification method employed and may be 827 inconsistent between sessions. This may be confusing for the user 828 and the application. 830 Recommendations: If multiple encapsulation methods for IP packets on 831 a single link layer technology are deemed to be necessary, care 832 should be taken to match the services available between encapsulation 833 methods as closely as possible. 835 3.6. Implementation Complexity 837 Support of multiple encapsulation methods results in additional 838 implementation complexity. Lack of uniform encapsulation support 839 also results in potential interoperability problems. To avoid 840 interoperability issues, devices with limited resources may be 841 required to implement multiple encapsulation mechanisms, which may 842 not be practical. 844 When encapsulation methods require hardware support, implementations 845 may choose to support different encapsulation sets, resulting in 846 market fragmentation. This can prevent users from benefiting from 847 economies of scale, precluding some uses of the technology entirely. 849 Recommendations: Choose a single mandatory to implement 850 encapsulation mechanism for both sending and receiving, and make that 851 encapsulation mechanism the default for sending. 853 3.7. Negotiation 855 The complexity of negotiation within ARP or IP can be reduced by 856 performing encapsulation negotiation within the link layer. 858 However, unless the link layer allows the negotiation of the 859 encapsulation between any two hosts, then interoperability problems 860 can still result if more than one encapsulation is possible on a 861 given link. In general, a host cannot assume that all other hosts on 862 a link support the same set of encapsulation methods, so that unless 863 a link layer protocol only supports point-to-point communication, 864 negotiation of multiple potential encapsulation methods will be 865 problematic. To avoid this problem, it is desirable for link layer 866 encapsulation negotiation to determine a single IP encapsulation, not 867 merely to indicate which encapsulation methods are possible. 869 Recommendations: Encapsulation negotiation is best handled in the 870 link layer. In order to avoid dependencies on the data frame 871 encapsulation mechanism, it is preferable for the negotiation to be 872 carried out using management frames, if they are supported. If 873 multiple encapsulations are required and negotiation is provided, 874 then the negotiation should result in a single encapsulation method 875 being negotiated on the link. 877 3.8. Roaming 879 Where a mobile node roams between base stations or to a fixed 880 infrastructure and the base stations and fixed infrastructure do not 881 all support the same set of encapsulations, then it may be necessary 882 to alter the encapsulation method, potentially in mid-conversation. 883 Even if the change can be handled seamlessly at the link and IP layer 884 so that applications are not affected, unless the services offered 885 over the different encapsulations are equivalent (see Section 3.5) 886 the service experienced by the application may change as the mobile 887 node crosses boundaries. If the service is significantly different, 888 it might even require 'in-flight' renegotiation which most 889 applications are not equipped to manage. 891 Recommendations: Ensure uniformity of the encapsulation set 892 (preferably only a single encapsulation) within a given mobile 893 domain, between mobile domains, and between mobile domains and fixed 894 infrastructure. If a link layer protocol offers multiple 895 encapsulation methods for IP packets, it is strongly recommended that 896 only one of these encapsulation methods should be in use on any given 897 link or within a single wireless transmission domain. 899 4. Security Considerations 901 The use of multiple encapsulation methods does not appear to have 902 significant security implications. 904 An attacker might be able to utilize an encapsulation method which 905 was not in normal use on a link to cause a Denial of Service attack 906 which would exhaust the processing resources of interfaces if packets 907 utilizing this encapsulation were passed up the stack to any 908 significant degree before being discarded. 910 An attacker might be able to force a more cumbersome encapsulation 911 method between two endpoints, even when a lighter weight one is 912 available, hence forcing higher resource consumption on the link and 913 within those endpoints, or causing fragmentation. Since IP fragments 914 are more difficult to classify than non-fragments, this may result in 915 packet loss or may even expose security vulnerabilities [WEP]. 917 If different methods have different security properties, an attacker 918 might be able to force a less secure method as an elevation path to 919 get access to some other resource or data. Similarly, if one method 920 is rarely used, that method is potentially more likely to have 921 exploitable implementation bugs. 923 Since lower layer classification methods may need to inspect fields 924 in the packet being encapsulated, this might deter the deployment of 925 end-to-end security which is undesirable. Where encryption of upper 926 layer headers (e.g. IPsec tunnel mode) is required, this may obscure 927 headers required for classification. As a result, it may be 928 necessary for all encrypted traffic to flow over a single connection. 930 5. IANA Considerations 932 This document has no actions for IANA. 934 6. Conclusion 936 The use of multiple encapsulation methods on the same link is 937 problematic, as discussed above. 939 Although multiple IP encapsulation methods were defined on Ethernet 940 cabling, recent implementations support only the Ethernet 941 encapsulation of IPv4 defined in [RFC894]. In order to avoid a 942 repeat of the experience with IPv4, for operation of IPv6 on IEEE 943 802.3 media, only the Ethernet encapsulation was defined in "A Method 944 for the Transmission of IPv6 Packets over Ethernet Networks" 945 [RFC1972], later updated in [RFC2464]. 947 In addition to the recommendations given earlier, we give the 948 following general recommendations to avoid problems resulting from 949 use of multiple IP encapsulation methods: 951 When developing standards for encapsulating IP packets on a link 952 layer technology, it is desirable that only a single encapsulation 953 method should be standardized for each link layer technology; 955 If a link layer protocol offers multiple encapsulation methods for 956 IP packets, it is strongly recommended that only one of these 957 encapsulation methods should be in use within any given link; 959 Where multiple encapsulation methods are supported on a link, a 960 single encapsulation should be mandatory to implement for send and 961 receive. 963 7. References 965 7.1. Informative References 967 [DIX] Digital Equipment Corporation, Intel Corporation, 968 and Xerox Corporation, "The Ethernet -- A Local Area 969 Network: Data Link Layer and Physical Layer (Version 970 2.0)", November 1982. 972 [Generic] Wang, L. et al, "A Generic Packet Convergence 973 Sublayer (GPCS) for Supporting Multiple Protocols 974 over 802.16 Air Interface", Submission to IEEE 975 802.16g: CB0216g_05_025r4.pdf, November 2005, 976 . 979 [IEEE-802.1A.1990] Institute of Electrical and Electronics Engineers, 980 "Local Area Networks and Metropolitan Area Networks: 981 Overview and Architecture of Network Standards", 982 IEEE Standard 802.1A, 1990. 984 [IEEE-802.1D.2004] Institute of Electrical and Electronics Engineers, 985 "Information technology - Telecommunications and 986 information exchange between systems - Local area 987 networks - Media access control (MAC) bridges", IEEE 988 Standard 802.1D, 2004. 990 [IEEE-802.1Q.2003] IEEE Standards for Local and Metropolitan Area 991 Networks: Draft Standard for Virtual Bridged Local 992 Area Networks, P802.1Q-2003, January 2003. 994 [IEEE-802.3.2002] Institute of Electrical and Electronics Engineers, 995 "Carrier Sense Multiple Access with Collision 996 Detection (CSMA/CD) Access Method and Physical Layer 997 Specifications", IEEE Standard 802.3, 2002. 999 [IEEE-802.11.2003] Institute of Electrical and Electronics Engineers, 1000 "Wireless LAN Medium Access Control (MAC) and 1001 Physical Layer (PHY) Specifications", IEEE Standard 1002 802.11, 2003. 1004 [IEEE-802.16.2004] Institute of Electrical and Electronics Engineers, 1005 "Information technology - Telecommunications and 1006 information exchange between systems - Local and 1007 metropolitan area networks, Part 16: Air Interface 1008 for Fixed Broadband Wireless Access Systems", IEEE 1009 Standard 802.16-2004, October 2004. 1011 [IEEE-802.16e.2005] Institute of Electrical and Electronics Engineers, 1012 "Information technology - Telecommunications and 1013 information exchange between systems - Local and 1014 Metropolitan Area Networks - Part 16: Air Interface 1015 for Fixed and Mobile Broadband Wireless Access 1016 Systems, Amendment for Physical and Medium Access 1017 Control Layers for Combined Fixed and Mobile 1018 Operation in Licensed Bands", IEEE P802.16e, 1019 September 2005. 1021 [PROBE] Hewlett Packard, "A Primer on HP Probe", 1022 http://www.hp.com/rnd/support/manuals/pdf/ 1023 hp_probe.pdf, July 1993. 1025 [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: 1026 Or converting network protocol addresses to 48.bit 1027 Ethernet address for transmission on Ethernet 1028 hardware", STD 37, RFC 826, November 1982. 1030 [RFC893] Leffler, S. and M. Karels, "Trailer encapsulations", 1031 RFC 893, April 1984. 1033 [RFC894] Hornig, C., "Standard for the transmission of IP 1034 datagrams over Ethernet networks", STD 41, RFC 894, 1035 April 1984. 1037 [RFC903] Finlayson, R., Mann, T., Mogul, J. and M. Theimer, 1038 "A Reverse Address Resolution Protocol", RFC 903, 1039 Stanford, June 1984. 1041 [RFC948] Winston, I., "Two Methods for the Transmission of IP 1042 Datagrams over IEEE 802.3 Networks", RFC 948, June 1043 1985. 1045 [RFC1010] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1046 1010, May 1987. 1048 [RFC1042] Postel, J. and J. Reynolds, "Standard for the 1049 transmission of IP datagrams over IEEE 802 1050 networks", STD 43, RFC 1042, February 1988. 1052 [RFC1122] Braden, R., "Requirements for Internet Hosts -- 1053 Communication Layers", RFC 1122, October 1989. 1055 [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low- 1056 Speed Serial Links", RFC 1144, February 1990. 1058 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", 1059 STD 51, RFC 1661, July 1994. 1061 [RFC1958] Carpenter, B., "Architectural Principles of the 1062 Internet", RFC 1958, June 1996. 1064 [RFC1962] Rand, D., "The PPP Compression Control Protocol 1065 (CCP)", RFC 1962, June 1996. 1067 [RFC1972] Crawford, M., "A Method for the Transmission of IPv6 1068 Packets over Ethernet Networks", RFC 1972, August 1069 1996. 1071 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1072 Requirement Levels", BCP 14, RFC 2119, March 1997. 1074 [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", 1075 RFC 2472, December 1998. 1077 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over 1078 Ethernet Networks", RFC 2464, December 1998. 1080 [RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header 1081 Compression", RFC 2507, February 1999. 1083 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 1084 Headers for Low-Speed Serial Links", RFC 2508, 1085 February 1999. 1087 [RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 1088 2615, June 1999. 1090 [RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol 1091 Encapsulation over ATM Adaptation Layer 5", RFC 1092 2684, September 1999. 1094 [RFC3095] Bormann, C., et. al, "RObust Header Compression 1095 (ROHC): Framework and four profiles: RTP, UDP, ESP 1096 and uncompressed", RFC 3095, July 2001. 1098 [RFC3241] Bormann, C., "Robust Header Compression (ROHC) over 1099 PPP", RFC 3241, April 2002. 1101 [RFC3518] Higashiyama, M., Baker, F. and T. Liao, "Point-to- 1102 Point Protocol (PPP) Bridging Control Protocol 1103 (BCP)", RFC 3518, April 2003. 1105 [RFC3544] Koren, T., Casner, S. and C. Bormann, "IP Header 1106 Compression over PPP", RFC 3544, July 2003. 1108 [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, 1109 B., and P. Ruddy, "Enhanced Compressed RTP (CRTP) 1110 for Links with High Delay, Packet Loss and 1111 Reordering", RFC 3545, July 2003. 1113 [RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC): 1114 Terminology and Channel Mapping Examples", RFC 3759, 1115 April 2004. 1117 [RFC4541] Christensen, M., Kimball, K. and F. Solensky, 1118 "Considerations for Internet Group Management 1119 Protocol (IGMP) and Multicast Listener Discovery 1120 (MLD) Snooping Switches", RFC 4541, May 2006. 1122 [WEP] Bittau, A., Handley, M. and J. Lackey, "The Final 1123 Nail in WEP's Coffin", Proceedings of the 2006 IEEE 1124 Symposium on Security and Privacy, pp. 386-400. 1126 Acknowledgments 1128 The authors would like to acknowledge Jeff Mandin, Bob Hinden, Jari 1129 Arkko, Max Riegel, Alfred Hoenes and Phil Roberts for contributions 1130 to this document. 1132 Appendix A - IAB Members at the time of this writing 1134 Bernard Aboba 1135 Loa Andersson 1136 Brian Carpenter 1137 Leslie Daigle 1138 Elwyn Davies 1139 Kevin Fall 1140 Olaf Kolkman 1141 Kurtis Lindqvist 1142 David Meyer 1143 David Oran 1144 Eric Rescorla 1145 Dave Thaler 1146 Lixia Zhang 1148 Authors' Addresses 1150 Bernard Aboba 1151 Microsoft Corporation 1152 One Microsoft Way 1153 Redmond, WA 98052 1155 EMail: bernarda@microsoft.com 1156 Phone: +1 425 706 6605 1157 Fax: +1 425 936 7329 1159 Elwyn B. Davies 1160 Consultant 1161 Soham, Cambs 1162 UK 1164 EMail: elwynd@dial.pipex.com 1165 Phone: +44 7889 488 335 1167 Dave Thaler 1168 Microsoft Corporation 1169 One Microsoft Way 1170 Redmond, WA 98052 1172 EMail: dthaler@microsoft.com 1173 Phone: +1 425 703 8835 1175 Full Copyright Statement 1177 Copyright (C) The IETF Trust (2007). 1179 This document is subject to the rights, licenses and restrictions 1180 contained in BCP 78, and except as set forth therein, the authors 1181 retain all their rights. 1183 This document and the information contained herein are provided on an 1184 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1185 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1186 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1187 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1188 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1189 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1191 Intellectual Property 1193 The IETF takes no position regarding the validity or scope of any 1194 Intellectual Property Rights or other rights that might be claimed to 1195 pertain to the implementation or use of the technology described in 1196 this document or the extent to which any license under such rights 1197 might or might not be available; nor does it represent that it has 1198 made any independent effort to identify any such rights. Information 1199 on the procedures with respect to rights in RFC documents can be 1200 found in BCP 78 and BCP 79. 1202 Copies of IPR disclosures made to the IETF Secretariat and any 1203 assurances of licenses to be made available, or the result of an 1204 attempt made to obtain a general license or permission for the use of 1205 such proprietary rights by implementers or users of this 1206 specification can be obtained from the IETF on-line IPR repository at 1207 http://www.ietf.org/ipr. 1209 The IETF invites any interested party to bring to its attention any 1210 copyrights, patents or patent applications, or other proprietary 1211 rights that may cover technology that may be required to implement 1212 this standard. Please address the information to the IETF at 1213 ietf-ipr@ietf.org. 1215 Acknowledgment 1217 Funding for the RFC Editor function is currently provided by the 1218 Internet Society.