idnits 2.17.1 draft-iab-link-encaps-01.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 801. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 778. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 785. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 791. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 807), 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 563 has weird spacing: '...xity of negot...' == 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 (7 June 2006) is 6531 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE-802-1A.190' is mentioned on line 80, but not defined == Missing Reference: 'RFC1122' is mentioned on line 250, but not defined == Unused Reference: 'IEEE.802-1D.1998' is defined on line 701, but no explicit reference was found in the text == Unused Reference: 'IEEE.802-3.1985' is defined on line 707, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 736, 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 (~~), 8 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 7 June 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 December 1, 2006. 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 2. Evaluation of Reasons ................................. 7 50 2.1 Bridging ....................................... 7 51 2.2 Efficiency ..................................... 8 52 3. Additional Issues ..................................... 9 53 3.1 Generality ..................................... 9 54 3.2 Layer Interdependence .......................... 10 55 3.3 Inspection of Payload Contents ................. 11 56 3.4 Interoperability Guidance ...................... 11 57 3.5 Service Consistency ............................ 12 58 3.6 Implementation Complexity ...................... 12 59 3.7 Negotiation .................................... 13 60 3.8 Roaming ........................................ 13 61 4. Security Considerations ............................... 14 62 5. IANA Considerations ................................... 14 63 6. Conclusion ............................................ 14 64 7. References ............................................ 15 65 7.1 Informative References .......................... 15 66 Acknowledgments .............................................. 17 67 Appendix A - IAB Members ..................................... 17 68 Intellectual Property Statement .............................. 17 69 Disclaimer of Validity ....................................... 18 70 Copyright Statement .......................................... 18 71 1. Introduction 73 This document describes architectural and operational issues arising 74 from use of multiple ways of encapsulating IP packets on the same 75 link. While typically a link layer protocol supports only a single 76 Internet Protocol (IP) encapsulation method, this is not always the 77 case. For example, on the same cable it is possible to encapsulate 78 an IPv4 packet using Ethernet [DIX] encapsulation as defined in "A 79 Standard for the Transmission of IP Datagrams over Ethernet Networks" 80 [RFC894] or IEEE 802 [IEEE-802-1A.190] encapsulation as defined in "A 81 Standard for the Transmission of IP Datagrams over IEEE 802 Networks" 82 [RFC1042]. Historically, a further encapsulation method was used on 83 some Ethernet systems as specified in "Trailer Encapsulations" 84 [RFC893]. 86 Recently new link types have been defined that support multiple 87 encapsulation methods. For example, IEEE 802.16 [IEEE-802.16] splits 88 the Media Access Control (MAC) layer into a number of sublayers. For 89 the uppermost of these, the standard defines the concept of a 90 service-specific Convergence Sublayer (CS) that can be instantiated 91 in multiple ways, each with its own data frame encapsulation. The 92 two underlying sublayers (the MAC Common Part Sublayer and the 93 Security Sublayer) provide common services for all instantiations of 94 the CS. While [IEEE-802.16] defined support for the ATM CS and the 95 Packet CS, [IEEE-802.16e] added support for eight new Convergence 96 Sublayers. In each case there are multiple choices available for 97 encapsulating IP packets. 99 1.1. Terminology 101 Broadcast domain 102 The set of all endpoints that receive broadcast frames sent by an 103 endpoint in the set. 105 Link A communication facility or physical medium that can sustain data 106 communications between multiple network nodes, such as an Ethernet 107 (simple or bridged). 109 Link Layer 110 The conceptual layer of control or processing logic that is 111 responsible for maintaining control of the link. The link layer 112 functions provide an interface between the higher-layer logic and 113 the link. The link layer is the layer immediately below IP. 115 1.2. Ethernet Experience 117 The fundamental issues with multiple encapsulation methods on the 118 same link are described in [RFC1042] and "Requirements for Internet 119 Hosts -- Communication Layers" [RFC1122]. This section summarizes 120 the concerns articulated in those documents and also describes the 121 limitations of approaches suggested to mitigate the problems, 122 including encapsulation negotiation and use of routers. 124 [RFC1042] described the potential issues resulting from joint use of 125 Ethernet and IEEE 802.3 encapsulation on the same physical cable: 127 Interoperation with Ethernet 129 It is possible to use the Ethernet link level protocol [DIX] on 130 the same physical cable with the IEEE 802.3 link level protocol. 131 A computer interfaced to a physical cable used in this way could 132 potentially read both Ethernet and 802.3 packets from the network. 133 If a computer does read both types of packets, it must keep track 134 of which link protocol was used with each other computer on the 135 network and use the proper link protocol when sending packets. 137 One should note that in such an environment, link level broadcast 138 packets will not reach all the computers attached to the network, 139 but only those using the link level protocol used for the 140 broadcast. 142 Since it must be assumed that most computers will read and send 143 using only one type of link protocol, it is recommended that if 144 such an environment (a network with both link protocols) is 145 necessary, an IP gateway be used as if there were two distinct 146 networks. 148 Note that the MTU for the Ethernet allows a 1500 octet IP 149 datagram, with the MTU for the 802.3 network allows only a 1492 150 octet IP datagram. 152 When multiple IP encapsulation methods were supported on a given 153 link, all hosts could not be assumed to support the same set of 154 encapsulation methods. This in turn implied that the broadcast 155 domain might not include all hosts on the link, necessitating the use 156 of a switch or router to enable the hosts supporting disparate 157 encapsulation methods to communicate with each other. However, hosts 158 supporting multiple encapsulation methods still needed to determine 159 the encapsulation method used to reach a destination host. As noted 160 in [RFC1122], Section 2.3.3: 162 Furthermore, it is not useful or even possible for a dual-format 163 host to discover automatically which format to send, because of 164 the problem of link-layer broadcasts. 166 To address these issues, "Requirements for Internet Hosts -- 167 Communication Layers" [RFC1122] provided guidance in Section 2.3.3: 169 Every Internet host connected to a 10Mbps Ethernet cable: 171 o MUST be able to send and receive packets using RFC-894 172 encapsulation; 174 o SHOULD be able to receive RFC-1042 packets, intermixed 175 with RFC-894 packets; and 177 o MAY be able to send packets using RFC-1042 encapsulation. 179 An Internet host that implements sending both the RFC-894 and 180 the RFC-1042 encapsulation MUST provide a configuration switch 181 to select which is sent, and this switch MUST default to RFC- 182 894. 184 By making Ethernet encapsulation mandatory to implement for both send 185 and receive, and also the default for sending, [RFC1122] headed off 186 potential interoperability problems. 188 1.3. Trailer Encapsulation Experience 190 [RFC1122] Section 2.3.1 described the issues with trailer 191 encapsulation: 193 DISCUSSION 195 The trailer protocol is a link-layer encapsulation technique 196 that rearranges the data contents of packets sent on the 197 physical network. In some cases, trailers improve the 198 throughput of higher layer protocols by reducing the amount of 199 data copying within the operating system. Higher layer 200 protocols are unaware of trailer use, but both the sending and 201 receiving host MUST understand the protocol if it is used. 202 Improper use of trailers can result in very confusing symptoms. 203 Only packets with specific size attributes are encapsulated 204 using trailers, and typically only a small fraction of the 205 packets being exchanged have these attributes. Thus, if a 206 system using trailers exchanges packets with a system that does 207 not, some packets disappear into a black hole while others are 208 delivered successfully. 210 IMPLEMENTATION: 212 On an Ethernet, packets encapsulated with trailers use a 213 distinct Ethernet type [RFC893], and trailer negotiation is 214 performed at the time that ARP is used to discover the link- 215 layer address of a destination system. 217 Specifically, the ARP exchange is completed in the usual manner 218 using the normal IP protocol type, but a host that wants to 219 speak trailers will send an additional "trailer ARP reply" 220 packet, i.e., an ARP reply that specifies the trailer 221 encapsulation protocol type but otherwise has the format of a 222 normal ARP reply. If a host configured to use trailers 223 receives a trailer ARP reply message from a remote machine, it 224 can add that machine to the list of machines that understand 225 trailers, e.g., by marking the corresponding entry in the ARP 226 cache. 228 Hosts wishing to receive trailers send trailer ARP replies 229 whenever they complete exchanges of normal ARP messages for IP. 230 Thus, a host that received an ARP request for its IP protocol 231 address would send a trailer ARP reply in addition to the 232 normal IP ARP reply; a host that sent the IP ARP request would 233 send a trailer ARP reply when it received the corresponding IP 234 ARP reply. In this way, either the requesting or responding 235 host in an IP ARP exchange may request that it receive 236 trailers. 238 This scheme, using extra trailer ARP reply packets rather than 239 sending an ARP request for the trailer protocol type, was 240 designed to avoid a continuous exchange of ARP packets with a 241 misbehaving host that, contrary to any specification or common 242 sense, responded to an ARP reply for trailers with another ARP 243 reply for IP. This problem is avoided by sending a trailer ARP 244 reply in response to an IP ARP reply only when the IP ARP reply 245 answers an outstanding request; this is true when the hardware 246 address for the host is still unknown when the IP ARP reply is 247 received. A trailer ARP reply may always be sent along with an 248 IP ARP reply responding to an IP ARP request. 250 "Requirements for Internet Hosts - Communication Layers" [RFC1122] 251 Section 2.3.1 provided the following guidance for use of trailer 252 encapsulation: 254 The trailer protocol for link-layer encapsulation MAY be used, but 255 only when it has been verified that both systems (host or gateway) 256 involved in the link-layer communication implement trailers. If 257 the system does not dynamically negotiate use of the trailer 258 protocol on a per-destination basis, the default configuration 259 MUST disable the protocol. 261 Trailer encapsulation negotiation depends on ARP and can only be used 262 where all hosts on the link are within the same broadcast domain. 264 Since it assumes that all hosts support standard Ethernet 265 encapsulation [RFC894], it did not enable negotiation between 266 Ethernet and IEEE 802 encapsulation, only between standard Ethernet 267 [RFC894] and trailer [RFC893] encapsulation. 269 In order to mitigate problems arising from multiple encapsulation 270 methods, it may be possible to use switches or routers, or to attempt 271 to negotiate the encapsulation method to be used. As described 272 below, neither approach is completely satisfactory. 274 The use of switches or routers to enable communication between hosts 275 utilizing multiple encapsulation methods is not a panacea. If 276 separate prefixes are used for each encapsulation, then each 277 encapsulation method can be treated as a separate interface with the 278 choice of encapsulation determined from the routing table. However, 279 if the same prefix is used for each encapsulation method, it is 280 necessary to keep state for each destination host. 282 In situations where multiple encapsulation methods are enabled on a 283 single link, negotiation may be supported to allow hosts to determine 284 how to encapsulate a packet for a particular destination host. 286 Experience with trailer encapsulation suggests some of the issues 287 that may be encountered in attempting to negotiate encapsulation 288 above the link layer. The trailer negotiation mechanism resulted in 289 multiple ARP replies. In theory it is possible to negotiate an 290 encapsulation method by sending negotiation packets over all 291 encapsulation methods supported, and keeping state for each 292 destination host. However, this results in higher bandwidth 293 overhead, higher latency when establishing communication, and 294 additional complexity in implementations. 296 2. Evaluation of Reasons 298 There are several reasons often given in support of multiple 299 encapsulation methods. We discuss each in turn, below. 301 2.1. Bridging 303 Claim: A number of features have been defined for Ethernet that are 304 desirable in new link layer protocols, most notably (but not limited 305 to) bridging. Hence in addition to any other encapsulation methods, 306 it is desirable to support an Ethernet encapsulation method in order 307 to take advantage of existing features without redefining them in the 308 context of a new link layer protocol. 310 Discussion: Reuse of Ethernet encapsulation is a worthy goal. 311 "Architectural Principles of the Internet" [RFC1958] point 3.2 312 states: 314 If there are several ways of doing the same thing, choose one. If 315 a previous design, in the Internet context or elsewhere, has 316 successfully solved the same problem, choose the same solution 317 unless there is a good technical reason not to. Duplication of 318 the same protocol functionality should be avoided as far as 319 possible, without of course using this argument to reject 320 improvements. 322 Furthermore, other features have been added to Ethernet such as 323 support for Virtual LANs (VLANs) and Quality of Service (QoS). Hence 324 supporting Ethernet encapsulation has significant value. 326 However, this reasoning by itself is only sufficient to motivate a 327 single encapsulation method (i.e., Ethernet), but not multiple 328 encapsulation methods. 330 Recommendation: Support Ethernet encapsulation where possible. 332 2.2. Efficiency 334 Claim: Multiple encapsulation methods allow for greater efficiency. 335 For example, it has been argued that IEEE 802 or Ethernet 336 encapsulation of IP results in excessive overhead due to the size of 337 the data frame headers, and that this can adversely affect 338 performance on wireless networks, particularly in situations where 339 support of Voice over IP (VOIP) is required. 341 Discussion: Even where these performance concerns are valid, 342 solutions exist that do not require defining multiple IP 343 encapsulation methods. For example, links may support Ethernet frame 344 compression so that Ethernet Source and Destination Address fields 345 are not sent with every packet. 347 It is not the existence of multiple encapsulation methods that is the 348 issue; the problem occurs when the encapsulations are visible in the 349 upper layers as different broadcast domains. For instance, the 350 problem with Ethernet and IEEE 802.3 encapsulation occurs because the 351 IP layer needs to know whether to encapsulate ARP in one way or the 352 other; where all hosts on the link do not support the same 353 encapsulation method, packets encapsulated in one way will not be 354 received by all hosts on the link. In 802.16 the link-layer address 355 resolution design may be affected the choice of the CS. 357 In contrast, "The PPP Compression Control Protocol (CCP)" [RFC1962] 358 enables negotiation of data compression mechanisms, and "Robust 359 Header Compression (ROHC) over PPP" [RFC3241] and "IP Header 360 Compression over PPP" [RFC3544] enable negotiation of header 361 compression, without IP layer awareness. Any frame can be 362 "decompressed" based on the content of the frame, and prior state 363 based on previous control messages or data frames. Use of 364 compression is a good way to solve the efficiency problem without 365 introducing problems at higher layers. 367 The use of multiple encapsulation methods (even if the only 368 difference is compression) can degrade performance if the 369 encapsulation mechanisms have differing MTUs. This can result in 370 differing MTUs for on-link destinations; if the link-layer protocol 371 does not provide per-destination MTU's to the IP layer, it will need 372 to use a default MTU, which is an upper bound on the actual MTU. If 373 the default MTU is too low, the full bandwidth may not be achievable. 374 If the default MTU is too high, packet loss will result as IP Path 375 MTU Discovery discovers the correct MTU. 377 Finally, even if the MTU does not differ between encapsulation 378 methods, if the encapsulation method must be dynamically negotiated 379 for each new on-link destination, communication to new destinations 380 may be delayed. If most communication is short, and the negotiation 381 requires an extra round trip beyond link-layer address resolution, 382 this can become a noticeable factor in performance. 384 Recommendations: Where encapsulation is an efficiency issue, use 385 header compression. Where the encapsulation method, or the use of 386 compression, must be negotiated, negotiation should either occur as 387 part of bringing up the link, or be piggybacked in the link-layer 388 address resolution exchange. Where the MTU may vary among 389 destinations on the same link, the link layer protocol should provide 390 a per destination MTU to IP. 392 3. Additional Issues 394 There are a number of additional issues arising from use of multiple 395 encapsulation methods, as hinted at in section 1. We discuss each of 396 these below. 398 3.1. Generality 400 Link layer protocols such as [IEEE.802-1A.1990] and [DIX] inherently 401 support the ability to add support for a new packet type without 402 modification to the link layer protocol. As noted in [Generic], the 403 definition of multiple Convergence Sublayers within 802.16 appears to 404 imply that the standard will need to be modified to support new 405 packet types: 407 We are concerned that the 802.16 protocol cannot easily be 408 extendable to transport new protocols over the 802.16 air 409 interface. It would appear that a Convergence Sublayer is needed 410 for every type of protocol transported over the 802.16 MAC. Every 411 time a new protocol type needs to be transported over the 802.16 412 air interface, the 802.16 standard needs to be modified to define 413 a new CS type. We need to have a generic Packet Convergence 414 Sublayer that can support multi-protocols and which does not 415 require further modification to the 802.16 standard to support new 416 protocols. We believe that this was the original intention of the 417 Packet CS. Furthermore, we believe it is difficult for the 418 industry to agree on a set of CSes that all devices must implement 419 to claim "compliance". 421 The use of IP and/or upper layer protocol specific encapsulation 422 methods, rather than a 'neutral' general purpose encapsulation may 423 give rise to a number of undesirable effects explored in the 424 following subsections. 426 If the link layer does not provide a general purpose encapsulation 427 method, deployment of new IP and/or upper layer protocols will be 428 dependent on deployment of the corresponding new encapsulation 429 support in the link layer. 431 Even if a single encapsulation method is used, problems can still 432 occur if demultiplexing of ARP, IPv4, IPv6, and any other protocols 433 in use, is not supported at the link layer. While is possible to 434 demultiplex such packets based on the Version field (first four bits 435 on the packet), this assumes that IPv4-only implementations will be 436 able to properly handle IPv6 packets. As a result, a more robust 437 design is to demultiplex protocols in the link layer, such as by 438 assigning a different protocol type, as is done in IEEE 802 media 439 where a Type of 0x0800 is used for IPv4, and 0x86DD for IPv6. 441 Recommendations: Link layer protocols should enable network packets 442 (IPv4, IPv6, ARP, etc.) to be demultiplexed in the link layer. 444 3.2. Layer Interdependence 446 Standardizing IP and/or upper layer specific encapsulation methods in 447 the link layer will almost inevitably lead to interdependencies 448 between the two specifications. Although this might appear to be 449 desirable in terms of providing a highly specific (and hence 450 interoperable) mapping between the capabilities provided by the link 451 layer (e.g., quality of service support) and those that are needed by 452 the upper layer, this sort of capability is probably better provided 453 by a more comprehensive service interface (Application Programming 454 Interface) in conjunction with a single non-specific encapsulation. 456 IPv6, in particular, provides an extensible header system. An upper 457 layer specific encapsulation method would still have to provide a 458 degree of generality in order to cope with future extensions of IPv6 459 that might wish to make use of some of the link layer services 460 already provided. 462 Recommendations: Upper layer specific encapsulations should be 463 avoided. 465 3.3. Inspection of Payload Contents 467 If an IP or upper layer specific encapsulation method proposes to 468 inspect the contents of the packet being encapsulated (e.g., 802.16 469 IP CS mechanisms for determining the connection identifier (CID) to 470 use to transmit a packet), the fields available for inspection may be 471 limited if the packet is encrypted before passing to the link layer. 473 Recommendations: Encapsulation mechanisms should be neutral with 474 respect to the contents of the packet being encapsulated. 476 3.4. Interoperability Guidance 478 [IEEE-802.16e] has defined multiple Convergence Sublayers capable of 479 carrying IP traffic. In addition to the Ethernet CS, IPv4 CS and 480 IPv6 CS, ten other Convergence Sublayers are defined. In 802.16 the 481 Mobile Station (MS) indicates the Convergence Sublayers it supports 482 to the Base Station (BS), which selects from the list one or more 483 that it will support on the link. Therefore it is possible for 484 multiple CSes to be operational. In situations where multiple CSes 485 are operational and capable of carrying IP traffic, interoperability 486 problems are possible in the absence of clear implementation 487 guidelines. Some of the issues that may arise include: 489 ARP Where multiple CSes are operational, it may not be obvious how ARP 490 should be implemented. For example, should an ARP frame be 491 encapsulated over the Ethernet CS, or should alternative mechanisms 492 be used for address resolution, utilizing the IPv4 CS? 494 Data Frame Encapsulation 495 When sending an IP packet, which CS should be used? Where multiple 496 CSes are operational, the issue can be treated as a multi-homing 497 problem, with each CS constituting its own interface. Since a 498 given CS may have associated bandwidth or quality of service 499 constraints, routing metrics could be adjusted to take this into 500 account, allowing the routing layer to choose based on which CS 501 appears more attractive. 503 However there is no guarantee that other hosts on the link will 504 support the same set of CSes, or that if they do, that their 505 routing tables will result in identical preferences. 507 This could lead to interoperability problems or routing asymmetry. 508 For example, consider the effects on Neighbor Discovery: 510 [a] If hosts choose to send Neighbor Discovery traffic on different 511 CSes, it is possible that a host sending a Neighbor Discovery 512 packet will not receive a reply, even though the target host is 513 reachable over another CS. 515 [b] Where hosts all support the same set of CSes, but have different 516 routing preferences, it is possible for a host to send a Neighbor 517 Discovery packet over one CS and receive a reply over another CS. 519 Recommendations: Given these issues, it is strongly recommended that 520 only a single encapsulation method be usable in a given circumstance. 522 3.5. Service Consistency 524 If a link layer protocol provides multiple encapsulation methods, the 525 services offered to the IP and upper layer protocols may differ 526 qualitatively between the different encapsulation methods. For 527 example, the 802.16 [IEEE-802.16] link layer protocol offers both 528 'native' encapsulation for IPv4 and IPv6 packets, and emulated 529 Ethernet encapsulation. In the native case, the IP layer has direct 530 access to the quality of service (QoS) capabilities of the 802.16 531 transmission channels, whereas using the Ethernet encapsulation the 532 IP QoS has first to be mapped through the rather more limited 533 capabilities of Ethernet QoS. Consequently, the service offered to 534 an application depends on the encapsulation method employed and may 535 be inconsistent between sessions. This may be confusing for the user 536 and the application. 538 Recommendations: If multiple encapsulation methods for IP packets on 539 a single link layer technology are deemed to be necessary, care 540 should be taken to match the services available between encapsulation 541 methods as closely as possible. 543 3.6. Implementation Complexity 545 Support of multiple encapsulation methods results in additional 546 implementation complexity. Lack of uniform encapsulation support 547 also results in potential interoperability problems. To avoid 548 interoperability issues, devices with limited resources may be 549 required to implement multiple encapsulation mechanisms, which may 550 not be practical. 552 When encapsulation methods require hardware support, implementations 553 may choose to support different encapsulation sets, resulting in 554 market fragmentation. This can prevent users from benefiting from 555 economies of scale, precluding some uses of the technology entirely. 557 Recommendations: Choose a single mandatory to implement 558 encapsulation mechanism for both sending and receiving, and make that 559 encapsulation mechanism the default for sending. 561 3.7. Negotiation 563 The complexity of negotiation within ARP or IP can be reduced by 564 performing encapsulation negotiation within the link layer. 566 However, unless the link layer allows the negotiation of the 567 encapsulation between any two hosts, then interoperability problems 568 can still result if more than one encapsulation is possible on a 569 given link. In general, a host cannot assume that all other hosts on 570 a link support the same set of encapsulation methods, so that unless 571 a link layer protocol only supports point-to-point communication, 572 negotiation of multiple potential encapsulation methods will be 573 problematic. To avoid this problem, it is desirable for link layer 574 encapsulation negotiation to determine a single IP encapsulation, not 575 merely to indicate which encapsulation methods are possible. 577 Recommendations: Encapsulation negotiation is best handled in the 578 link layer. In order to avoid dependencies on the data frame 579 encapsulation mechanism, it is preferable for the negotiation to be 580 carried out using management frames, if they are supported. If 581 multiple encapsulations are required and negotiation is provided, 582 then the negotiation should result in a single encapsulation method 583 being negotiated on the link. 585 3.8. Roaming 587 Where a mobile node roams between base stations or to a fixed 588 infrastructure and the base stations and fixed infrastructure do not 589 all support the same set of encapsulations, then it may be necessary 590 to alter the encapsulation method, potentially in mid-conversation. 591 Even if the change can be handled seamlessly at the link and IP layer 592 so that applications are not affected, unless the services offered 593 over the different encapsulations are equivalent (see Section 3.5) 594 the service experienced by the application may change as the mobile 595 node crosses boundaries. If the service is significantly different, 596 it might even require 'in-flight' renegotiation which most 597 applications are not equipped to manage. 599 Recommendations: Ensure uniformity of the encapsulation set 600 (preferably only a single encapsulation) within a given mobile 601 domain, between mobile domains, and between mobile domains and fixed 602 infrastructure. If a link layer protocol offers multiple 603 encapsulation methods for IP packets, it is strongly recommended that 604 only one of these encapsulation methods should be in use on any given 605 link or within a single wireless transmission domain. 607 4. Security Considerations 609 The use of multiple encapsulation methods does not appear to have 610 significant security implications. 612 An attacker might be able to utilize an encapsulation method which 613 was not in normal use on a link to cause a Denial of Service attack 614 which would exhaust the processing resources of interfaces if packets 615 utilizing this encapsulation were passed up the stack to any 616 significant degree before being discarded. However, the use of 617 encapsulation methods that need to inspect fields in the packet being 618 encapsulated in order to provide service classification might deter 619 the deployment of end-to-end security; this is undesirable. 621 Similarly, if one method is rarely used, that method is potentially 622 more likely to have exploitable implementation bugs. 624 An attacker might be able to force a more cumbersome encapsulation 625 method between two endpoints, even when a lighter weight one is 626 available, hence forcing higher resource consumption on the link and 627 within those endpoints. 629 If different methods have different security properties, an attacker 630 might be able to force a less secure method as an elevation path to 631 get access to some other resource or data. 633 5. IANA Considerations 635 This document has no actions for IANA. 637 6. Conclusion 639 The use of multiple encapsulation methods on the same link is 640 problematic, as discussed above. Although multiple IP encapsulation 641 methods were defined on Ethernet cabling, recent implementations 642 support only the Ethernet encapsulation of IPv4 defined in [RFC894]. 643 In order to avoid a repeat of the experience with IPv4, for operation 644 of IPv6 on IEEE 802.3 media, only the Ethernet encapsulation was 645 defined in "A Method for the Transmission of IPv6 Packets over 646 Ethernet Networks" [RFC1972]. 648 In addition to the recommendations given earlier, we give the 649 following general recommendations to avoid problems resulting from 650 use of multiple IP encapsulation methods: 652 When developing standards for encapsulating IP packets on a link 653 layer technology, it is desirable that only a single encapsulation 654 method should be standardized for each link layer technology; 656 If a link layer protocol offers multiple encapsulation methods for 657 IP packets, it is strongly recommended that only one of these 658 encapsulation methods should be in use within any given link or 659 wireless transmission domain; 661 Where multiple encapsulation methods are supported on a link, a 662 single encapsulation should be mandatory to implement for send and 663 receive. 665 7. References 667 7.1. Informative References 669 [DIX] 670 Digital Equipment Corporation, Intel Corporation, and Xerox 671 Corporation, "The Ethernet -- A Local Area Network: Data Link Layer 672 and Physical Layer (Version 2.0)", November 1982. 674 [Generic] 675 Wang, L. et al, "A Generic Packet Convergence Sublayer (GPCS) for 676 Supporting Multiple Protocols over 802.16 Air Interface", 677 Submission to IEEE 802.16g: CB0216g_05_025r4.pdf, November 2005, 678 . 680 [IEEE-802.16] 681 Institute of Electrical and Electronics Engineers, "Information 682 technology - Telecommunications and information exchange between 683 systems - Local and metropolitan area networks, Part 16: Air 684 Interface for Fixed Broadband Wireless Access Systems", IEEE 685 Standard 802.16-2004, October 2004. 687 [IEEE-802.16e] 688 Institute of Electrical and Electronics Engineers, "Information 689 technology - Telecommunications and information exchange between 690 systems - Local and Metropolitan Area Networks - Part 16: Air 691 Interface for Fixed and Mobile Broadband Wireless Access Systems, 692 Amendment for Physical and Medium Access Control Layers for 693 Combined Fixed and Mobile Operation in Licensed Bands", IEEE 694 P802.16e, September 2005. 696 [IEEE.802-1A.1990] 697 Institute of Electrical and Electronics Engineers, "Local Area 698 Networks and Metropolitan Area Networks: Overview and Architecture 699 of Network Standards", IEEE Standard 802.1A, 1990. 701 [IEEE.802-1D.1998] 702 Institute of Electrical and Electronics Engineers, "Information 703 technology - Telecommunications and information exchange between 704 systems - Local area networks - Media access control (MAC) 705 bridges", IEEE Standard 802.1D, 1998. 707 [IEEE.802-3.1985] 708 Institute of Electrical and Electronics Engineers, "Carrier Sense 709 Multiple Access with Collision Detection (CSMA/CD) Access Method 710 and Physical Layer Specifications", IEEE Standard 802.3, 1985. 712 [RFC893] 713 Leffler, S. and M. Karels, "Trailer encapsulations", RFC 893, April 714 1984. 716 [RFC894] 717 Hornig, C., "Standard for the transmission of IP datagrams over 718 Ethernet networks", STD 41, RFC 894, April 1984. 720 [RFC1042] 721 Postel, J. and J. Reynolds, "Standard for the transmission of IP 722 datagrams over IEEE 802 networks", STD 43, RFC 1042, February 1988. 724 [RFC1958] 725 Carpenter, B., "Architectural Principles of the Internet", RFC 726 1958, June 1996. 728 [RFC1962] 729 Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, 730 June 1996. 732 [RFC1972] 733 Crawford, M., "A Method for the Transmission of IPv6 Packets over 734 Ethernet Networks", RFC 1972, August 1996. 736 [RFC2119] 737 Bradner, S., "Key words for use in RFCs to Indicate Requirement 738 Levels", BCP 14, RFC 2119, March 1997. 740 [RFC3241] 741 Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, 742 April 2002. 744 [RFC3544] 745 Koren, T., Casner, S. and C. Bormann, "IP Header Compression over 746 PPP", RFC 3544, July 2003. 748 Acknowledgments 750 The authors would like to acknowledge Jeff Mandin, Bob Hinden, Jari 751 Arkko, and Phil Roberts for contributions to this document. 753 Appendix A - IAB Members at the time of this writing 755 Bernard Aboba 756 Loa Andersson 757 Brian Carpenter 758 Leslie Daigle 759 Elwyn Davies 760 Kevin Fall 761 Olaf Kolkman 762 Kurtis Lindqvist 763 David Meyer 764 David Oran 765 Eric Rescorla 766 Dave Thaler 767 Lixia Zhang 769 Intellectual Property Statement 771 The IETF takes no position regarding the validity or scope of any 772 Intellectual Property Rights or other rights that might be claimed to 773 pertain to the implementation or use of the technology described in 774 this document or the extent to which any license under such rights 775 might or might not be available; nor does it represent that it has 776 made any independent effort to identify any such rights. Information 777 on the procedures with respect to rights in RFC documents can be 778 found in BCP 78 and BCP 79. 780 Copies of IPR disclosures made to the IETF Secretariat and any 781 assurances of licenses to be made available, or the result of an 782 attempt made to obtain a general license or permission for the use of 783 such proprietary rights by implementers or users of this 784 specification can be obtained from the IETF on-line IPR repository at 785 http://www.ietf.org/ipr. 787 The IETF invites any interested party to bring to its attention any 788 copyrights, patents or patent applications, or other proprietary 789 rights that may cover technology that may be required to implement 790 this standard. Please address the information to the IETF at ietf- 791 ipr@ietf.org. 793 Disclaimer of Validity 795 This document and the information contained herein are provided on an 796 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 797 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 798 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 799 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 800 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 801 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 803 Copyright Statement 805 Copyright (C) The Internet Society (2006). This document is subject 806 to the rights, licenses and restrictions contained in BCP 78, and 807 except as set forth therein, the authors retain all their rights. 809 Acknowledgment 811 Funding for the RFC Editor function is currently provided by the 812 Internet Society.