Multiple Encapsulation Methods Considered Harmful
RFC 4840
Document | Type |
RFC - Informational
(April 2007; No errata)
Was draft-iab-link-encaps (iab)
|
|
---|---|---|---|
Authors | Bernard Aboba , Elwyn Davies , Dave Thaler , Elwyn Davies | ||
Last updated | 2015-10-14 | ||
Stream | Internet Architecture Board (IAB) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | IAB state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) |
Network Working Group B. Aboba, Ed. Request for Comments: 4840 E. Davies Category: Informational D. Thaler Internet Architecture Board April 2007 Multiple Encapsulation Methods Considered Harmful Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes architectural and operational issues that arise from link-layer protocols supporting multiple Internet Protocol encapsulation methods. Aboba, et al. Informational [Page 1] RFC 4840 Multiple Encapsulation Methods Harmful April 2007 Table of Contents 1. Introduction ....................................................3 1.1. Terminology ................................................3 1.2. Ethernet Experience ........................................4 1.2.1. IEEE 802.2/802.3 LLC Type 1 Encapsulation ...........6 1.2.2. Trailer Encapsulation ...............................7 1.3. PPP Experience ............................................10 1.4. Potential Mitigations .....................................10 2. Evaluation of Arguments for Multiple Encapsulations ............11 2.1. Efficiency ................................................11 2.2. Multicast/Broadcast .......................................12 2.3. Multiple Uses .............................................13 3. Additional Issues ..............................................15 3.1. Generality ................................................15 3.2. Layer Interdependence .....................................16 3.3. Inspection of Payload Contents ............................17 3.4. Interoperability Guidance .................................17 3.5. Service Consistency .......................................19 3.6. Implementation Complexity .................................19 3.7. Negotiation ...............................................19 3.8. Roaming ...................................................20 4. Security Considerations ........................................20 5. Conclusion .....................................................21 6. References .....................................................22 6.1. Normative Reference .......................................22 6.2. Informative References ....................................22 7. Acknowledgments ................................................25 Appendix A. IAB Members at the Time of This Writing ...............26 Aboba, et al. Informational [Page 2] RFC 4840 Multiple Encapsulation Methods Harmful April 2007 1. Introduction This document describes architectural and operational issues arising from the use of multiple ways of encapsulating IP packets on the same link. While typically a link-layer protocol supports only a single Internet Protocol (IP) encapsulation method, this is not always the case. For example, on the same cable it is possible to encapsulate an IPv4 packet using Ethernet [DIX] encapsulation as defined in "A Standard for the Transmission of IP Datagrams over Ethernet Networks" [RFC894], the IEEE 802.2/802.3 LLC [IEEE-802.3.2002] Type 1 encapsulation defined in "Two Methods For The Transmission of IP Datagrams over IEEE 802.3 Networks" [RFC948], or the IEEE 802 [IEEE-802.1A.1990] encapsulation defined in "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks" [RFC1042]. Historically, a further encapsulation method was used on some Ethernet systems as specified in "Trailer Encapsulations" [RFC893]. Similarly, ATM (e.g., see [RFC2684]), the Point-to-Point Protocol (PPP) [RFC1661], and IEEE 802.16 [IEEE-802.16e.2005] also support multiple encapsulation mechanisms. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Broadcast domain The set of all endpoints that receive broadcast frames sent by an endpoint in the set. Classification As defined in [IEEE-802.16e.2005], the process by which a Medium Access Control (MAC) Service Data Unit (SDU) is mapped into a particular transport connection for transmission between MAC peers. Connection Identifier (CID) In [IEEE-802.16e.2005] the connection identifier is a 16-bitShow full document text