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