idnits 2.17.1 draft-iab-link-encaps-02.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 957. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 934. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 941. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 947. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 963), 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 397 has weird spacing: '...rnet is poten...' == 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 (30 July 2006) is 6477 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE-802-1A.190' is mentioned on line 82, but not defined == Missing Reference: 'RFC1122' is mentioned on line 311, but not defined == Missing Reference: 'IEEE-802.1Q' is mentioned on line 457, but not defined == Unused Reference: 'IEEE.802-1D.1998' is defined on line 820, but no explicit reference was found in the text == Unused Reference: 'IEEE.802-3.1985' is defined on line 827, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 860, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1972 (Obsoleted by RFC 2464) Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 8 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 30 July 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 February 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 ............................ 3 48 1.3 Trailer Encapsulation Experience ............... 6 49 1.4 Potential Mitigations .......................... 8 50 2. Evaluation of Arguments for Multiple Encapsulations ... 8 51 2.1 Efficiency ..................................... 8 52 2.2 Multicast/Broadcast ............................ 9 53 2.3 Multiple Uses .................................. 10 54 3. Additional Issues ..................................... 11 55 3.1 Generality ..................................... 12 56 3.2 Layer Interdependence .......................... 13 57 3.3 Inspection of Payload Contents ................. 13 58 3.4 Interoperability Guidance ...................... 13 59 3.5 Service Consistency ............................ 14 60 3.6 Implementation Complexity ...................... 15 61 3.7 Negotiation .................................... 15 62 3.8 Roaming ........................................ 16 63 4. Security Considerations ............................... 16 64 5. IANA Considerations ................................... 17 65 6. Conclusion ............................................ 17 66 7. References ............................................ 17 67 7.1 Informative References .......................... 17 68 Acknowledgments .............................................. 20 69 Appendix A - IAB Members ..................................... 20 70 Intellectual Property Statement .............................. 20 71 Disclaimer of Validity ....................................... 21 72 Copyright Statement .......................................... 21 73 1. Introduction 75 This document describes architectural and operational issues arising 76 from use of multiple ways of encapsulating IP packets on the same 77 link. While typically a link layer protocol supports only a single 78 Internet Protocol (IP) encapsulation method, this is not always the 79 case. For example, on the same cable it is possible to encapsulate 80 an IPv4 packet using Ethernet [DIX] encapsulation as defined in "A 81 Standard for the Transmission of IP Datagrams over Ethernet Networks" 82 [RFC894] or IEEE 802 [IEEE-802-1A.190] encapsulation as defined in "A 83 Standard for the Transmission of IP Datagrams over IEEE 802 Networks" 84 [RFC1042]. Historically, a further encapsulation method was used on 85 some Ethernet systems as specified in "Trailer Encapsulations" 86 [RFC893]. 88 Recently new link types have been defined that support multiple 89 encapsulation methods. For example, IEEE 802.16 [IEEE-802.16] splits 90 the Media Access Control (MAC) layer into a number of sublayers. For 91 the uppermost of these, the standard defines the concept of a 92 service-specific Convergence Sublayer (CS) that can be instantiated 93 in multiple ways, each with its own data frame encapsulation. The 94 two underlying sublayers (the MAC Common Part Sublayer and the 95 Security Sublayer) provide common services for all instantiations of 96 the CS. While [IEEE-802.16] defined support for the Asynchronous 97 Transfer Mode (ATM) CS and the Packet CS, [IEEE-802.16e] added 98 support for eight new Convergence Sublayers. In each case there are 99 multiple choices available for encapsulating IP packets. 101 1.1. Terminology 103 Broadcast domain 104 The set of all endpoints that receive broadcast frames sent by an 105 endpoint in the set. 107 Link A communication facility or physical medium that can sustain data 108 communications between multiple network nodes, such as an Ethernet 109 (simple or bridged). 111 Link Layer 112 The conceptual layer of control or processing logic that is 113 responsible for maintaining control of the link. The link layer 114 functions provide an interface between the higher-layer logic and 115 the link. The link layer is the layer immediately below IP. 117 1.2. Ethernet Experience 119 The fundamental issues with multiple encapsulation methods on the 120 same link are described in [RFC1042] and "Requirements for Internet 121 Hosts -- Communication Layers" [RFC1122]. This section summarizes 122 the concerns articulated in those documents and also describes the 123 limitations of approaches suggested to mitigate the problems, 124 including encapsulation negotiation and use of routers. 126 [RFC1042] described the potential issues resulting from 127 contemporaneous use of Ethernet and IEEE 802.3 encapsulation on the 128 same physical cable: 130 Interoperation with Ethernet 132 It is possible to use the Ethernet link level protocol [DIX] on 133 the same physical cable with the IEEE 802.3 link level 134 protocol. A computer interfaced to a physical cable used in 135 this way could potentially read both Ethernet and 802.3 packets 136 from the network. If a computer does read both types of 137 packets, it must keep track of which link protocol was used 138 with each other computer on the network and use the proper link 139 protocol when sending packets. 141 One should note that in such an environment, link level 142 broadcast packets will not reach all the computers attached to 143 the network, but only those using the link level protocol used 144 for the broadcast. 146 Since it must be assumed that most computers will read and send 147 using only one type of link protocol, it is recommended that if 148 such an environment (a network with both link protocols) is 149 necessary, an IP gateway be used as if there were two distinct 150 networks. 152 Note that the MTU for the Ethernet allows a 1500 octet IP 153 datagram, with the MTU for the 802.3 network allows only a 1492 154 octet IP datagram. 156 When multiple IP encapsulation methods were supported on a given 157 link, all hosts could not be assumed to support the same set of 158 encapsulation methods. This in turn implied that the broadcast 159 domain might not include all hosts on the link. Where a single 160 encapsulation does not reach all hosts on the link, a host needs to 161 determine the appropriate encapsulation prior to sending. While a 162 host supporting reception of multiple encapsulations could keep track 163 of the encapsulations it receives, this does not enable initiation of 164 communication; supporting initiation requires a host to support 165 sending of multiple encapsulations in order to determine which one to 166 use. However, requiring hosts to send and receive multiple 167 encapsulations is a potentially onerous requirement. 169 The use of multiple encapsulation methods with differing Maximum 170 Transfer Units (MTUs) can degrade performance. This can result in 171 differing MTUs for on-link destinations; if the link-layer protocol 172 does not provide per-destination MTUs to the IP layer, it will need 173 to use a default MTU; to avoid fragmentation this must be less than 174 or equal to the minimum MTU of on-link destinations. If the default 175 MTU is too low, the full bandwidth may not be achievable. If the 176 default MTU is too high, packet loss will result unless or until IP 177 Path MTU Discovery is used to discover the correct MTU. 179 [RFC1122], Section 2.3.3 notes the difficulties with this approach: 181 Furthermore, it is not useful or even possible for a dual-format 182 host to discover automatically which format to send, because of 183 the problem of link-layer broadcasts. 185 To enable hosts that only support sending and receiving of a single 186 encapsulation to communicate with each other, a router can be 187 utilized to segregate the hosts by encapsulation. Here only the 188 router needs to support sending and receiving of multiple 189 encapsulations. This requires assigning a separate prefix to each 190 encapsulation, or else all hosts in the broadcast domain would not be 191 reachable with a single encapsulation. 193 [RFC1122] Section 2.3.3 provided guidance on encapsulation support: 195 Every Internet host connected to a 10Mbps Ethernet cable: 197 o MUST be able to send and receive packets using RFC-894 198 encapsulation; 200 o SHOULD be able to receive RFC-1042 packets, intermixed 201 with RFC-894 packets; and 203 o MAY be able to send packets using RFC-1042 encapsulation. 205 An Internet host that implements sending both the RFC-894 and 206 the RFC-1042 encapsulation MUST provide a configuration switch 207 to select which is sent, and this switch MUST default to RFC- 208 894. 210 By making Ethernet encapsulation mandatory to implement for both send 211 and receive, and also the default for sending, [RFC1122] recognized 212 Ethernet as the predominant encapsulation, heading off potential 213 interoperability problems. 215 1.3. Trailer Encapsulation Experience 217 As noted in "Trailer Encapsulations" [RFC893], trailer encapsulation 218 was an optimization developed to minimize memory-to-memory copies on 219 reception. By placing variable length IP and transport headers at 220 the end of the packet, page alignment of data could be more easily 221 maintained. Trailers were implemented in 4.2 Berkeley System 222 Distribution (BSD) (among others). While in theory trailer 223 encapsulation could have been applied to both Ethernet and IEEE 802 224 encapsulations (creating four potential encapsulations of IP!), in 225 practice trailer encapsulation was only supported for Ethernet. A 226 separate Ethertype was utilized in order to enable IP packets in 227 trailer encapsulation to be distinguished from [RFC894] 228 encapsulation. 230 [RFC1122] Section 2.3.1 described the issues with trailer 231 encapsulation: 233 DISCUSSION 235 The trailer protocol is a link-layer encapsulation technique 236 that rearranges the data contents of packets sent on the 237 physical network. In some cases, trailers improve the 238 throughput of higher layer protocols by reducing the amount of 239 data copying within the operating system. Higher layer 240 protocols are unaware of trailer use, but both the sending and 241 receiving host MUST understand the protocol if it is used. 242 Improper use of trailers can result in very confusing symptoms. 243 Only packets with specific size attributes are encapsulated 244 using trailers, and typically only a small fraction of the 245 packets being exchanged have these attributes. Thus, if a 246 system using trailers exchanges packets with a system that does 247 not, some packets disappear into a black hole while others are 248 delivered successfully. 250 IMPLEMENTATION: 252 On an Ethernet, packets encapsulated with trailers use a 253 distinct Ethernet type [RFC893], and trailer negotiation is 254 performed at the time that ARP is used to discover the link- 255 layer address of a destination system. 257 Specifically, the ARP exchange is completed in the usual manner 258 using the normal IP protocol type, but a host that wants to 259 speak trailers will send an additional "trailer ARP reply" 260 packet, i.e., an ARP reply that specifies the trailer 261 encapsulation protocol type but otherwise has the format of a 262 normal ARP reply. If a host configured to use trailers 263 receives a trailer ARP reply message from a remote machine, it 264 can add that machine to the list of machines that understand 265 trailers, e.g., by marking the corresponding entry in the ARP 266 cache. 268 Hosts wishing to receive trailers send trailer ARP replies 269 whenever they complete exchanges of normal ARP messages for IP. 270 Thus, a host that received an ARP request for its IP protocol 271 address would send a trailer ARP reply in addition to the 272 normal IP ARP reply; a host that sent the IP ARP request would 273 send a trailer ARP reply when it received the corresponding IP 274 ARP reply. In this way, either the requesting or responding 275 host in an IP ARP exchange may request that it receive 276 trailers. 278 This scheme, using extra trailer ARP reply packets rather than 279 sending an ARP request for the trailer protocol type, was 280 designed to avoid a continuous exchange of ARP packets with a 281 misbehaving host that, contrary to any specification or common 282 sense, responded to an ARP reply for trailers with another ARP 283 reply for IP. This problem is avoided by sending a trailer ARP 284 reply in response to an IP ARP reply only when the IP ARP reply 285 answers an outstanding request; this is true when the hardware 286 address for the host is still unknown when the IP ARP reply is 287 received. A trailer ARP reply may always be sent along with an 288 IP ARP reply responding to an IP ARP request. 290 Since trailer encapsulation negotiation depends on ARP, it can only 291 be used where all hosts on the link are within the same broadcast 292 domain. It was assumed that all hosts supported sending and 293 receiving ARP packets in standard Ethernet encapsulation [RFC894], so 294 that negotiation between Ethernet and IEEE 802 encapsulation was not 295 required, only negotiation between standard Ethernet [RFC894] and 296 trailer [RFC893] encapsulation. Had hosts supporting trailer 297 encapsulation also supported IEEE 802 framing, the negotiation would 298 have been complicated still further. 300 [RFC1122] Section 2.3.1 provided the following guidance for use of 301 trailer encapsulation: 303 The trailer protocol for link-layer encapsulation MAY be used, but 304 only when it has been verified that both systems (host or gateway) 305 involved in the link-layer communication implement trailers. If 306 the system does not dynamically negotiate use of the trailer 307 protocol on a per-destination basis, the default configuration 308 MUST disable the protocol. 310 4.2BSD did not support dynamic negotiation, only configuration of 311 trailer encapsulation at boot time, and therefore [RFC1122] required 312 that the trailer encapsulation be disabled by default on those 313 systems. 315 1.4. Potential Mitigations 317 In order to mitigate problems arising from multiple encapsulation 318 methods, it may be possible to use switches or routers, or to attempt 319 to negotiate the encapsulation method to be used. As described 320 below, neither approach is completely satisfactory. 322 The use of switches or routers to enable communication between hosts 323 utilizing multiple encapsulation methods is not a panacea. If 324 separate prefixes are used for each encapsulation, then each 325 encapsulation method can be treated as a separate interface with the 326 choice of encapsulation determined from the routing table. However, 327 if the same prefix is used for each encapsulation method, it is 328 necessary to keep state for each destination host. 330 In situations where multiple encapsulation methods are enabled on a 331 single link, negotiation may be supported to allow hosts to determine 332 how to encapsulate a packet for a particular destination host. 334 Negotiating the encapsulation above the link layer is potentially 335 problematic since the negotiation itself may need to be carried out 336 using multiple encapsulations. In theory it is possible to negotiate 337 an encapsulation method by sending negotiation packets over all 338 encapsulation methods supported, and keeping state for each 339 destination host. However, if the encapsulation method must be 340 dynamically negotiated for each new on-link destination, 341 communication to new destinations may be delayed. If most 342 communication is short, and the negotiation requires an extra round 343 trip beyond link-layer address resolution, this can become a 344 noticeable factor in performance. Also, the negotiation may result 345 in consumption of additional bandwidth. 347 2. Evaluation of Arguments for Multiple Encapsulations 349 There are several reasons often given in support of multiple 350 encapsulation methods. We discuss each in turn, below. 352 2.1. Efficiency 354 Claim: Multiple encapsulation methods allow for greater efficiency. 355 For example, it has been argued that IEEE 802 or Ethernet 356 encapsulation of IP results in excessive overhead due to the size of 357 the data frame headers, and that this can adversely affect 358 performance on wireless networks, particularly in situations where 359 support of Voice over IP (VOIP) is required. 361 Discussion: Even where these performance concerns are valid, 362 solutions exist that do not require defining multiple IP 363 encapsulation methods. For example, links may support Ethernet frame 364 compression so that Ethernet Source and Destination Address fields 365 are not sent with every packet. 367 It is possible for link layers to negotiate compression without 368 requiring higher layer awareness; the Point-to-Point Protocol (PPP) 369 is an example. "The PPP Compression Control Protocol (CCP)" 370 [RFC1962] enables negotiation of data compression mechanisms, and 371 "Robust Header Compression (ROHC) over PPP" [RFC3241] and "IP Header 372 Compression over PPP" [RFC3544] enable negotiation of header 373 compression, without Internet layer awareness. Any frame can be 374 "decompressed" based on the content of the frame, and prior state 375 based on previous control messages or data frames. Use of 376 compression is a good way to solve the efficiency problem without 377 introducing problems at higher layers. 379 Recommendation: Where encapsulation is an efficiency issue, use 380 header compression. Where the encapsulation method, or the use of 381 compression, must be negotiated, negotiation should either occur as 382 part of bringing up the link, or be piggybacked in the link-layer 383 address resolution exchange. Where the MTU may vary among 384 destinations on the same link, the link layer protocol should provide 385 a per destination MTU to IP. 387 2.2. Multicast/Broadcast 389 Claim: Support for Ethernet encapsulation requires layer 2 support 390 for distribution of IP multicast/broadcast packets. In order to be 391 receivable by any host within listening range, a multicast/broadcast 392 packet sent over a wireless link needs to be sent at the lowest rate 393 supported by listeners. Since the sending host typically does not 394 keep track of the rates negotiated by group listeners, by default the 395 sending rate for multicast/broadcast traffic defaults to the lowest 396 supported rate, resulting in greatly increased overhead. Therefore 397 support for Ethernet is potentially problematic and other 398 encapsulations are necessary. 400 Discussion: Irrespective of the encapsulation used, IP packets sent 401 to multicast (IPv4/IPv6) or broadcast addresses (IPv4) need to reach 402 all potential on-link receivers. Use of alternative encapsulations 403 cannot remove this requirement. In order to limit the propagation of 404 link-scope multicast or broadcast traffic, it is possible to assign a 405 separate prefix to each host. 407 Unlike broadcasts, which are received by all hosts on the link 408 regardless of the protocol they are running, multicasts only need be 409 received by those hosts belonging to the multicast group. In wired 410 networks, it is possible to avoid forwarding multicast traffic on 411 switch ports without group members, by snooping of Internet Group 412 Management Protocol (IGMP) and Multicast Listener Discovery (MLD) 413 traffic as described in "Considerations for IGMP and MLD Snooping 414 Switches" [RFC4541]. 416 In wireless media where data rates to specific destinations are 417 negotiated and may vary over a wide range, it may be more efficient 418 to send multiple frames via link layer unicast than to send a single 419 multicast/broadcast frame. For example, in [IEEE-802.11] 420 multicast/broadcast traffic from the client station (STA) to the 421 Access Point (AP) is sent via link layer unicast. 423 Recommendation: Where support for link layer multicast/broadcast is 424 problematic, limit the propagation of link-scope multicast and 425 broadcast traffic by assignment of separate prefixes to hosts. In 426 some circumstances, it may be more efficient to distribute 427 multicast/broadcast traffic as multiple link-layer unicast frames. 429 2.3. Multiple Uses 431 Claim: No single encapsulation is optimal for all purposes. 432 Therefore where a link layer is utilized in disparate scenarios (such 433 as both fixed and mobile deployments), multiple encapsulations are a 434 practical requirement. 436 Discussion: "Architectural Principles of the Internet" [RFC1958] 437 point 3.2 states: 439 If there are several ways of doing the same thing, choose one. If 440 a previous design, in the Internet context or elsewhere, has 441 successfully solved the same problem, choose the same solution 442 unless there is a good technical reason not to. Duplication of 443 the same protocol functionality should be avoided as far as 444 possible, without of course using this argument to reject 445 improvements. 447 Existing encapsulations have proven themselves capable of supporting 448 disparate usage scenarios. For example, the Point-to-Point Protocol 449 (PPP) has been utilized by wireless link layers such as GPRS, as well 450 as in wired networks in applications such as "PPP over SONET/SDH" 451 [RFC2615]. PPP can even support bridging, as described in "Point-to- 452 Point Protocol (PPP) Bridging Control Protocol (BCP)" [RFC3518]. 454 Similarly, Ethernet encapsulation has been used in wired networks as 455 well as Wireless Local Area Networks (LANs) such as IEEE 802.11 456 [IEEE-802.11]. Ethernet can also support Virtual LANs (VLANs) and 457 Quality of Service (QoS) [IEEE-802.1Q]. 459 Therefore disparate usage scenarios can be addressed by choice of a 460 single encapsulation, rather than multiple encapsulations. Where an 461 existing encapsulation is suitable, this is preferable to creating a 462 new encapsulation. 464 Where encapsulations other than IP over Point-to-Point Protocol (PPP) 465 [RFC1661], Ethernet or IEEE 802 are supported, difficulties in 466 operating system integration can lead to interoperability problems. 468 In order to take advantage of operating system support for IP 469 encapsulation over PPP, Ethernet or IEEE 802, it may be tempting for 470 a driver supporting an alternative encapsulation to emulate PPP, 471 Ethernet or IEEE 802 support. Typically, PPP emulation requires that 472 the driver implement PPP, enabling translation of PPP control and 473 data frames to the equivalent native facilities. Similarly, Ethernet 474 or IEEE 802 emulation typically requires that the driver implement 475 Dynamic Host Configuration Protocol (DHCP)v4 or v6, Router 476 Solicitation/Router Advertisement (RS/RA), Address Resolution 477 Protocol (ARP) or IPv6 Neighbor Discovery (ND) in order to enable 478 translation of these frames to and from native facilities. 480 Where drivers are implemented in kernel mode, the work required to 481 provide faithful emulation may be substantial. This creates the 482 temptation to cut corners, potentially resulting in interoperability 483 problems. 485 For example, it might be tempting for driver implementations to 486 neglect IPv6 support. A driver emulating PPP might support only 487 IPCP, but not IPCPv6; a driver emulating Ethernet or IEEE 802 might 488 support only DHCPv4 and ARP, but not DHCPv6, RS/RA or ND. As a 489 result, an IPv6 host connecting to a network supporting IPv6 might 490 find itself unable to use IPv6 due to lack of driver support. 492 Recommendation: Support a single existing encapsulation where 493 possible. Emulation of PPP, Ethernet or IEEE 802 on top of 494 alternative encapsulations should be avoided. 496 3. Additional Issues 498 There are a number of additional issues arising from use of multiple 499 encapsulation methods, as hinted at in section 1. We discuss each of 500 these below. In many cases we consider the example of the multiple 501 encapsulations available in IEEE 802.16 for illustration but the 502 issues would occur in any other link layer that provided multiple 503 encapsulations. 505 3.1. Generality 507 Link layer protocols such as [IEEE.802-1A.1990] and [DIX] inherently 508 support the ability to add support for a new packet type without 509 modification to the link layer protocol. As noted in [Generic], the 510 definition of multiple Convergence Sublayers within 802.16 appears to 511 imply that the standard will need to be modified to support new 512 packet types: 514 We are concerned that the 802.16 protocol cannot easily be 515 extendable to transport new protocols over the 802.16 air 516 interface. It would appear that a Convergence Sublayer is needed 517 for every type of protocol transported over the 802.16 MAC. Every 518 time a new protocol type needs to be transported over the 802.16 519 air interface, the 802.16 standard needs to be modified to define 520 a new CS type. We need to have a generic Packet Convergence 521 Sublayer that can support multi-protocols and which does not 522 require further modification to the 802.16 standard to support new 523 protocols. We believe that this was the original intention of the 524 Packet CS. Furthermore, we believe it is difficult for the 525 industry to agree on a set of CSes that all devices must implement 526 to claim "compliance". 528 The use of IP and/or upper layer protocol specific encapsulation 529 methods, rather than a 'neutral' general purpose encapsulation may 530 give rise to a number of undesirable effects explored in the 531 following subsections. 533 If the link layer does not provide a general purpose encapsulation 534 method, deployment of new IP and/or upper layer protocols will be 535 dependent on deployment of the corresponding new encapsulation 536 support in the link layer. 538 Even if a single encapsulation method is used, problems can still 539 occur if de-multiplexing of ARP, IPv4, IPv6, and any other protocols 540 in use, is not supported at the link layer. While is possible to 541 demultiplex such packets based on the Version field (first four bits 542 on the packet), this assumes that IPv4-only implementations will be 543 able to properly handle IPv6 packets. As a result, a more robust 544 design is to demultiplex protocols in the link layer, such as by 545 assigning a different protocol type, as is done in IEEE 802 media 546 where a Type of 0x0800 is used for IPv4, and 0x86DD for IPv6. 548 Recommendations: Link layer protocols should enable network packets 549 (IPv4, IPv6, ARP, etc.) to be de-multiplexed in the link layer. 551 3.2. Layer Interdependence 553 Standardizing IP and/or upper layer specific encapsulation methods in 554 the link layer will almost inevitably lead to interdependencies 555 between the two specifications. Although this might appear to be 556 desirable in terms of providing a highly specific (and hence 557 interoperable) mapping between the capabilities provided by the link 558 layer (e.g., quality of service support) and those that are needed by 559 the upper layer, this sort of capability is probably better provided 560 by a more comprehensive service interface (Application Programming 561 Interface) in conjunction with a single non-specific encapsulation. 563 IPv6, in particular, provides an extensible header system. An upper 564 layer specific encapsulation method would still have to provide a 565 degree of generality in order to cope with future extensions of IPv6 566 that might wish to make use of some of the link layer services 567 already provided. 569 Recommendations: Upper layer specific encapsulations should be 570 avoided. 572 3.3. Inspection of Payload Contents 574 If an IP or upper layer specific encapsulation method proposes to 575 inspect the contents of the packet being encapsulated (e.g., 802.16 576 IP CS mechanisms for determining the connection identifier (CID) to 577 use to transmit a packet), the fields available for inspection may be 578 limited if the packet is compressed or encrypted before passing to 579 the link layer. This may prevent the link layer from utilizing 580 existing compression mechanisms, such as ROHC [RFC3059][RFC3759], 581 Compressed RTP (CRTP) [RFC2508], Enhanced Compressed RTP (ECRTP) 582 [RFC3545] or IP Header Compression [RFC2507]. 584 Recommendations: Encapsulation mechanisms should not rely on the 585 contents of the layer 3 payload. 587 3.4. Interoperability Guidance 589 [IEEE-802.16e] has defined multiple Convergence Sublayers capable of 590 carrying IP traffic. In addition to the Ethernet CS, IPv4 CS and 591 IPv6 CS, ten other Convergence Sublayers are defined. In 802.16 the 592 Mobile Station (MS) indicates the Convergence Sublayers it supports 593 to the Base Station (BS), which selects from the list one or more 594 that it will support on the link. Therefore it is possible for 595 multiple CSes to be operational. In situations where multiple CSes 596 are operational and capable of carrying IP traffic, interoperability 597 problems are possible in the absence of clear implementation 598 guidelines. Some of the issues that may arise include: 600 Address Resolution Protocol (ARP) 601 Where multiple CSes are operational, it may not be obvious how ARP 602 should be implemented. For example, should an ARP frame be 603 encapsulated over the Ethernet CS, or should alternative mechanisms 604 be used for address resolution, utilizing the IPv4 CS? 606 Data Frame Encapsulation 607 When sending an IP packet, which CS should be used? Where multiple 608 CSes are operational, the issue can be treated as a multi-homing 609 problem, with each CS constituting its own interface. Since a 610 given CS may have associated bandwidth or quality of service 611 constraints, routing metrics could be adjusted to take this into 612 account, allowing the routing layer to choose based on which CS 613 appears more attractive. 615 However there is no guarantee that other hosts on the link will 616 support the same set of CSes, or that if they do, that their 617 routing tables will result in identical preferences. 619 This could lead to interoperability problems or routing asymmetry. 620 For example, consider the effects on IPv6 Neighbor Discovery: 622 [a] If hosts choose to send IPv6 Neighbor Discovery traffic on 623 different CSes, it is possible that a host sending an IPv6 Neighbor 624 Discovery packet will not receive a reply, even though the target 625 host is reachable over another CS. 627 [b] Where hosts all support the same set of CSes, but have different 628 routing preferences, it is possible for a host to send an IPv6 629 Neighbor Discovery packet over one CS and receive a reply over 630 another CS. 632 Recommendations: Given these issues, it is strongly recommended that 633 only a single encapsulation method be usable in a given circumstance. 635 3.5. Service Consistency 637 If a link layer protocol provides multiple encapsulation methods, the 638 services offered to the IP and upper layer protocols may differ 639 qualitatively between the different encapsulation methods. For 640 example, the 802.16 [IEEE-802.16] link layer protocol offers both 641 'native' encapsulation for IPv4 and IPv6 packets, and emulated 642 Ethernet encapsulation. In the native case, the IP layer has direct 643 access to the quality of service (QoS) capabilities of the 802.16 644 transmission channels, whereas using the Ethernet encapsulation the 645 IP QoS has first to be mapped through the rather more limited 646 capabilities of Ethernet QoS. Consequently, the service offered to 647 an application depends on the encapsulation method employed and may 648 be inconsistent between sessions. This may be confusing for the user 649 and the application. 651 Recommendations: If multiple encapsulation methods for IP packets on 652 a single link layer technology are deemed to be necessary, care 653 should be taken to match the services available between encapsulation 654 methods as closely as possible. 656 3.6. Implementation Complexity 658 Support of multiple encapsulation methods results in additional 659 implementation complexity. Lack of uniform encapsulation support 660 also results in potential interoperability problems. To avoid 661 interoperability issues, devices with limited resources may be 662 required to implement multiple encapsulation mechanisms, which may 663 not be practical. 665 When encapsulation methods require hardware support, implementations 666 may choose to support different encapsulation sets, resulting in 667 market fragmentation. This can prevent users from benefiting from 668 economies of scale, precluding some uses of the technology entirely. 670 Recommendations: Choose a single mandatory to implement 671 encapsulation mechanism for both sending and receiving, and make that 672 encapsulation mechanism the default for sending. 674 3.7. Negotiation 676 The complexity of negotiation within ARP or IP can be reduced by 677 performing encapsulation negotiation within the link layer. 679 However, unless the link layer allows the negotiation of the 680 encapsulation between any two hosts, then interoperability problems 681 can still result if more than one encapsulation is possible on a 682 given link. In general, a host cannot assume that all other hosts on 683 a link support the same set of encapsulation methods, so that unless 684 a link layer protocol only supports point-to-point communication, 685 negotiation of multiple potential encapsulation methods will be 686 problematic. To avoid this problem, it is desirable for link layer 687 encapsulation negotiation to determine a single IP encapsulation, not 688 merely to indicate which encapsulation methods are possible. 690 Recommendations: Encapsulation negotiation is best handled in the 691 link layer. In order to avoid dependencies on the data frame 692 encapsulation mechanism, it is preferable for the negotiation to be 693 carried out using management frames, if they are supported. If 694 multiple encapsulations are required and negotiation is provided, 695 then the negotiation should result in a single encapsulation method 696 being negotiated on the link. 698 3.8. Roaming 700 Where a mobile node roams between base stations or to a fixed 701 infrastructure and the base stations and fixed infrastructure do not 702 all support the same set of encapsulations, then it may be necessary 703 to alter the encapsulation method, potentially in mid-conversation. 704 Even if the change can be handled seamlessly at the link and IP layer 705 so that applications are not affected, unless the services offered 706 over the different encapsulations are equivalent (see Section 3.5) 707 the service experienced by the application may change as the mobile 708 node crosses boundaries. If the service is significantly different, 709 it might even require 'in-flight' renegotiation which most 710 applications are not equipped to manage. 712 Recommendations: Ensure uniformity of the encapsulation set 713 (preferably only a single encapsulation) within a given mobile 714 domain, between mobile domains, and between mobile domains and fixed 715 infrastructure. If a link layer protocol offers multiple 716 encapsulation methods for IP packets, it is strongly recommended that 717 only one of these encapsulation methods should be in use on any given 718 link or within a single wireless transmission domain. 720 4. Security Considerations 722 The use of multiple encapsulation methods does not appear to have 723 significant security implications. 725 An attacker might be able to utilize an encapsulation method which 726 was not in normal use on a link to cause a Denial of Service attack 727 which would exhaust the processing resources of interfaces if packets 728 utilizing this encapsulation were passed up the stack to any 729 significant degree before being discarded. However, the use of 730 encapsulation methods that need to inspect fields in the packet being 731 encapsulated in order to provide service classification might deter 732 the deployment of end-to-end security; this is undesirable. 734 Similarly, if one method is rarely used, that method is potentially 735 more likely to have exploitable implementation bugs. 737 An attacker might be able to force a more cumbersome encapsulation 738 method between two endpoints, even when a lighter weight one is 739 available, hence forcing higher resource consumption on the link and 740 within those endpoints. 742 If different methods have different security properties, an attacker 743 might be able to force a less secure method as an elevation path to 744 get access to some other resource or data. 746 Where lower layer classification is implemented, encryption of upper 747 layer headers (e.g. IPsec tunnel mode), may obscure headers required 748 for classification. As a result, it may be necessary for all 749 encrypted traffic to flow over a single connection. 751 5. IANA Considerations 753 This document has no actions for IANA. 755 6. Conclusion 757 The use of multiple encapsulation methods on the same link is 758 problematic, as discussed above. Although multiple IP encapsulation 759 methods were defined on Ethernet cabling, recent implementations 760 support only the Ethernet encapsulation of IPv4 defined in [RFC894]. 761 In order to avoid a repeat of the experience with IPv4, for operation 762 of IPv6 on IEEE 802.3 media, only the Ethernet encapsulation was 763 defined in "A Method for the Transmission of IPv6 Packets over 764 Ethernet Networks" [RFC1972], later updated in [RFC2464]. 766 In addition to the recommendations given earlier, we give the 767 following general recommendations to avoid problems resulting from 768 use of multiple IP encapsulation methods: 770 When developing standards for encapsulating IP packets on a link 771 layer technology, it is desirable that only a single encapsulation 772 method should be standardized for each link layer technology; 774 If a link layer protocol offers multiple encapsulation methods for 775 IP packets, it is strongly recommended that only one of these 776 encapsulation methods should be in use within any given link or 777 wireless transmission domain; 779 Where multiple encapsulation methods are supported on a link, a 780 single encapsulation should be mandatory to implement for send and 781 receive. 783 7. References 785 7.1. Informative References 787 [DIX] Digital Equipment Corporation, Intel Corporation, and 788 Xerox Corporation, "The Ethernet -- A Local Area Network: 789 Data Link Layer and Physical Layer (Version 2.0)", 790 November 1982. 792 [Generic] Wang, L. et al, "A Generic Packet Convergence Sublayer 793 (GPCS) for Supporting Multiple Protocols over 802.16 Air 794 Interface", Submission to IEEE 802.16g: 795 CB0216g_05_025r4.pdf, November 2005, . 798 [IEEE-802.16] Institute of Electrical and Electronics Engineers, 799 "Information technology - Telecommunications and 800 information exchange between systems - Local and 801 metropolitan area networks, Part 16: Air Interface for 802 Fixed Broadband Wireless Access Systems", IEEE Standard 803 802.16-2004, October 2004. 805 [IEEE-802.16e] Institute of Electrical and Electronics Engineers, 806 "Information technology - Telecommunications and 807 information exchange between systems - Local and 808 Metropolitan Area Networks - Part 16: Air Interface for 809 Fixed and Mobile Broadband Wireless Access Systems, 810 Amendment for Physical and Medium Access Control Layers 811 for Combined Fixed and Mobile Operation in Licensed 812 Bands", IEEE P802.16e, September 2005. 814 [IEEE.802-1A.1990] 815 Institute of Electrical and Electronics Engineers, "Local 816 Area Networks and Metropolitan Area Networks: Overview 817 and Architecture of Network Standards", IEEE Standard 818 802.1A, 1990. 820 [IEEE.802-1D.1998] 821 Institute of Electrical and Electronics Engineers, 822 "Information technology - Telecommunications and 823 information exchange between systems - Local area 824 networks - Media access control (MAC) bridges", IEEE 825 Standard 802.1D, 1998. 827 [IEEE.802-3.1985] 828 Institute of Electrical and Electronics Engineers, 829 "Carrier Sense Multiple Access with Collision Detection 830 (CSMA/CD) Access Method and Physical Layer 831 Specifications", IEEE Standard 802.3, 1985. 833 [IEEE-802.11] Institute of Electrical and Electronics Engineers, 834 "Wireless LAN Medium Access Control (MAC) and Physical 835 Layer (PHY) Specifications", IEEE Standard 802.11, 2003. 837 [RFC893] Leffler, S. and M. Karels, "Trailer encapsulations", RFC 838 893, April 1984. 840 [RFC894] Hornig, C., "Standard for the transmission of IP 841 datagrams over Ethernet networks", STD 41, RFC 894, April 842 1984. 844 [RFC1042] Postel, J. and J. Reynolds, "Standard for the 845 transmission of IP datagrams over IEEE 802 networks", STD 846 43, RFC 1042, February 1988. 848 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 849 RFC 1661, July 1994. 851 [RFC1958] Carpenter, B., "Architectural Principles of the 852 Internet", RFC 1958, June 1996. 854 [RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)", 855 RFC 1962, June 1996. 857 [RFC1972] Crawford, M., "A Method for the Transmission of IPv6 858 Packets over Ethernet Networks", RFC 1972, August 1996. 860 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 861 Requirement Levels", BCP 14, RFC 2119, March 1997. 863 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 864 Networks", RFC 2464, December 1998. 866 [RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header 867 Compression", RFC 2507, February 1999. 869 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 870 Headers for Low-Speed Serial Links", RFC 2508, February 871 1999. 873 [RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, 874 June 1999. 876 [RFC3059] Bormann, C., et. al, "RObust Header Compression (ROHC): 877 Framework and four profiles: RTP, UDP, ESP and 878 uncompressed", RFC 3059, July 2001. 880 [RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP", 881 RFC 3241, April 2002. 883 [RFC3518] Higashiyama, M., Baker, F. and T. Liao, "Point-to-Point 884 Protocol (PPP) Bridging Control Protocol (BCP)", RFC 885 3518, April 2003. 887 [RFC3544] Koren, T., Casner, S. and C. Bormann, "IP Header 888 Compression over PPP", RFC 3544, July 2003. 890 [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and 891 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with 892 High Delay, Packet Loss and Reordering", RFC 3545, July 893 2003. 895 [RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC): 896 Terminology and Channel Mapping Examples", RFC 3759, 897 April 2004. 899 [RFC4541] Christensen, M., Kimball, K. and F. Solensky, 900 "Considerations for Internet Group Management Protocol 901 (IGMP) and Multicast Listener Discovery (MLD) Snooping 902 Switches", RFC 4541, May 2006. 904 Acknowledgments 906 The authors would like to acknowledge Jeff Mandin, Bob Hinden, Jari 907 Arkko, and Phil Roberts for contributions to this document. 909 Appendix A - IAB Members at the time of this writing 911 Bernard Aboba 912 Loa Andersson 913 Brian Carpenter 914 Leslie Daigle 915 Elwyn Davies 916 Kevin Fall 917 Olaf Kolkman 918 Kurtis Lindqvist 919 David Meyer 920 David Oran 921 Eric Rescorla 922 Dave Thaler 923 Lixia Zhang 925 Intellectual Property Statement 927 The IETF takes no position regarding the validity or scope of any 928 Intellectual Property Rights or other rights that might be claimed to 929 pertain to the implementation or use of the technology described in 930 this document or the extent to which any license under such rights 931 might or might not be available; nor does it represent that it has 932 made any independent effort to identify any such rights. Information 933 on the procedures with respect to rights in RFC documents can be 934 found in BCP 78 and BCP 79. 936 Copies of IPR disclosures made to the IETF Secretariat and any 937 assurances of licenses to be made available, or the result of an 938 attempt made to obtain a general license or permission for the use of 939 such proprietary rights by implementers or users of this 940 specification can be obtained from the IETF on-line IPR repository at 941 http://www.ietf.org/ipr. 943 The IETF invites any interested party to bring to its attention any 944 copyrights, patents or patent applications, or other proprietary 945 rights that may cover technology that may be required to implement 946 this standard. Please address the information to the IETF at ietf- 947 ipr@ietf.org. 949 Disclaimer of Validity 951 This document and the information contained herein are provided on an 952 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 953 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 954 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 955 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 956 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 957 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 959 Copyright Statement 961 Copyright (C) The Internet Society (2006). This document is subject 962 to the rights, licenses and restrictions contained in BCP 78, and 963 except as set forth therein, the authors retain all their rights. 965 Acknowledgment 967 Funding for the RFC Editor function is currently provided by the 968 Internet Society.