Multiple Encapsulation Methods Considered Harmful
RFC 4840
|
| Document |
Type |
|
RFC - Informational
(April 2007; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IAB
|
|
Formats |
|
plain text
pdf
html
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
Show full document text