One document matched: draft-iab-link-encaps-03.txt
Differences from draft-iab-link-encaps-02.txt
Network Working Group B. Aboba, Ed.
INTERNET-DRAFT Elwyn Davies
Category: Informational D. Thaler
<draft-iab-link-encaps-03.txt> Internet Architecture Board
1 October 2006
Multiple Encapsulation Methods Considered Harmful
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 1, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
This document describes architectural and operational issues that
arise from link layer protocols supporting multiple Internet Protocol
encapsulation methods.
IAB Informational [Page 1]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
Table of Contents
1. Introduction .......................................... 3
1.1 Terminology .................................... 3
1.2 Ethernet Experience ............................ 3
1.3 Trailer Encapsulation Experience ............... 5
1.4 Potential Mitigations .......................... 7
2. Evaluation of Arguments for Multiple Encapsulations ... 8
2.1 Efficiency ..................................... 8
2.2 Multicast/Broadcast ............................ 9
2.3 Multiple Uses .................................. 10
3. Additional Issues ..................................... 11
3.1 Generality ..................................... 12
3.2 Layer Interdependence .......................... 13
3.3 Inspection of Payload Contents ................. 13
3.4 Interoperability Guidance ...................... 13
3.5 Service Consistency ............................ 15
3.6 Implementation Complexity ...................... 15
3.7 Negotiation .................................... 16
3.8 Roaming ........................................ 16
4. Security Considerations ............................... 17
5. IANA Considerations ................................... 17
6. Conclusion ............................................ 17
7. References ............................................ 18
7.1 Informative References .......................... 18
Acknowledgments .............................................. 21
Appendix A - IAB Members ..................................... 21
Authors' Addresses ........................................... 21
Intellectual Property Statement .............................. 22
Disclaimer of Validity ....................................... 22
Copyright Statement .......................................... 22
IAB Informational [Page 2]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
1. Introduction
This document describes architectural and operational issues arising
from 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] or IEEE 802 [IEEE-802-1A.190] encapsulation as 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].
1.1. Terminology
Broadcast domain
The set of all endpoints that receive broadcast frames sent by an
endpoint in the set.
Link A communication facility or medium over which nodes can communicate
at the link layer, i.e., the layer immediately below IP.
Link Layer
The conceptual layer of control or processing logic that is
responsible for maintaining control of the link. The link layer
functions provide an interface between the higher-layer logic and
the link. The link layer is the layer immediately below IP.
1.2. Ethernet Experience
The fundamental issues with multiple encapsulation methods on the
same link are described in [RFC1042] and "Requirements for Internet
Hosts -- Communication Layers" [RFC1122]. This section summarizes
the concerns articulated in those documents and also describes the
limitations of approaches suggested to mitigate the problems,
including encapsulation negotiation and use of routers.
[RFC1042] described the potential issues resulting from
contemporaneous use of Ethernet and IEEE 802.3 encapsulation on the
same physical cable:
Interoperation with Ethernet
It is possible to use the Ethernet link level protocol [DIX] on
the same physical cable with the IEEE 802.3 link level
protocol. A computer interfaced to a physical cable used in
IAB Informational [Page 3]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
this way could potentially read both Ethernet and 802.3 packets
from the network. If a computer does read both types of
packets, it must keep track of which link protocol was used
with each other computer on the network and use the proper link
protocol when sending packets.
One should note that in such an environment, link level
broadcast packets will not reach all the computers attached to
the network, but only those using the link level protocol used
for the broadcast.
Since it must be assumed that most computers will read and send
using only one type of link protocol, it is recommended that if
such an environment (a network with both link protocols) is
necessary, an IP gateway be used as if there were two distinct
networks.
Note that the MTU for the Ethernet allows a 1500 octet IP
datagram, with the MTU for the 802.3 network allows only a 1492
octet IP datagram.
When multiple IP encapsulation methods were supported on a given
link, all hosts could not be assumed to support the same set of
encapsulation methods. This in turn implied that the broadcast
domain might not include all hosts on the link. Where a single
encapsulation does not reach all hosts on the link, a host needs to
determine the appropriate encapsulation prior to sending. While a
host supporting reception of multiple encapsulations could keep track
of the encapsulations it receives, this does not enable initiation of
communication; supporting initiation requires a host to support
sending of multiple encapsulations in order to determine which one to
use. However, requiring hosts to send and receive multiple
encapsulations is a potentially onerous requirement.
The use of multiple encapsulation methods with differing Maximum
Transfer Units (MTUs) can degrade performance. This can result in
differing MTUs for on-link destinations. If the link-layer protocol
does not provide per-destination MTUs to the IP layer, it will need
to use a default MTU; to avoid fragmentation this must be less than
or equal to the minimum MTU of on-link destinations. If the default
MTU is too low, the full bandwidth may not be achievable. If the
default MTU is too high, packet loss will result unless or until IP
Path MTU Discovery is used to discover the correct MTU.
[RFC1122], Section 2.3.3 notes the difficulties with this approach:
Furthermore, it is not useful or even possible for a dual-format
host to discover automatically which format to send, because of
IAB Informational [Page 4]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
the problem of link-layer broadcasts.
To enable hosts that only support sending and receiving of a single
encapsulation to communicate with each other, a router can be
utilized to segregate the hosts by encapsulation. Here only the
router needs to support sending and receiving of multiple
encapsulations. This requires assigning a separate prefix to each
encapsulation, or else all hosts in the broadcast domain would not be
reachable with a single encapsulation.
[RFC1122] Section 2.3.3 provided guidance on encapsulation support:
Every Internet host connected to a 10Mbps Ethernet cable:
o MUST be able to send and receive packets using RFC-894
encapsulation;
o SHOULD be able to receive RFC-1042 packets, intermixed
with RFC-894 packets; and
o MAY be able to send packets using RFC-1042 encapsulation.
An Internet host that implements sending both the RFC-894 and
the RFC-1042 encapsulation MUST provide a configuration switch
to select which is sent, and this switch MUST default to RFC-
894.
By making Ethernet encapsulation mandatory to implement for both send
and receive, and also the default for sending, [RFC1122] recognized
Ethernet as the predominant encapsulation, heading off potential
interoperability problems.
1.3. Trailer Encapsulation Experience
As noted in "Trailer Encapsulations" [RFC893], trailer encapsulation
was an optimization developed to minimize memory-to-memory copies on
reception. By placing variable length IP and transport headers at
the end of the packet, page alignment of data could be more easily
maintained. Trailers were implemented in 4.2 Berkeley System
Distribution (BSD) (among others). While in theory trailer
encapsulation could have been applied to both Ethernet and IEEE 802
encapsulations (creating four potential encapsulations of IP!), in
practice trailer encapsulation was only supported for Ethernet. A
separate Ethertype was utilized in order to enable IP packets in
trailer encapsulation to be distinguished from [RFC894]
encapsulation.
[RFC1122] Section 2.3.1 described the issues with trailer
IAB Informational [Page 5]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
encapsulation:
DISCUSSION
The trailer protocol is a link-layer encapsulation technique
that rearranges the data contents of packets sent on the
physical network. In some cases, trailers improve the
throughput of higher layer protocols by reducing the amount of
data copying within the operating system. Higher layer
protocols are unaware of trailer use, but both the sending and
receiving host MUST understand the protocol if it is used.
Improper use of trailers can result in very confusing symptoms.
Only packets with specific size attributes are encapsulated
using trailers, and typically only a small fraction of the
packets being exchanged have these attributes. Thus, if a
system using trailers exchanges packets with a system that does
not, some packets disappear into a black hole while others are
delivered successfully.
IMPLEMENTATION:
On an Ethernet, packets encapsulated with trailers use a
distinct Ethernet type [RFC893], and trailer negotiation is
performed at the time that ARP is used to discover the link-
layer address of a destination system.
Specifically, the ARP exchange is completed in the usual manner
using the normal IP protocol type, but a host that wants to
speak trailers will send an additional "trailer ARP reply"
packet, i.e., an ARP reply that specifies the trailer
encapsulation protocol type but otherwise has the format of a
normal ARP reply. If a host configured to use trailers
receives a trailer ARP reply message from a remote machine, it
can add that machine to the list of machines that understand
trailers, e.g., by marking the corresponding entry in the ARP
cache.
Hosts wishing to receive trailers send trailer ARP replies
whenever they complete exchanges of normal ARP messages for IP.
Thus, a host that received an ARP request for its IP protocol
address would send a trailer ARP reply in addition to the
normal IP ARP reply; a host that sent the IP ARP request would
send a trailer ARP reply when it received the corresponding IP
ARP reply. In this way, either the requesting or responding
host in an IP ARP exchange may request that it receive
trailers.
This scheme, using extra trailer ARP reply packets rather than
IAB Informational [Page 6]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
sending an ARP request for the trailer protocol type, was
designed to avoid a continuous exchange of ARP packets with a
misbehaving host that, contrary to any specification or common
sense, responded to an ARP reply for trailers with another ARP
reply for IP. This problem is avoided by sending a trailer ARP
reply in response to an IP ARP reply only when the IP ARP reply
answers an outstanding request; this is true when the hardware
address for the host is still unknown when the IP ARP reply is
received. A trailer ARP reply may always be sent along with an
IP ARP reply responding to an IP ARP request.
Since trailer encapsulation negotiation depends on ARP, it can only
be used where all hosts on the link are within the same broadcast
domain. It was assumed that all hosts supported sending and
receiving ARP packets in standard Ethernet encapsulation [RFC894], so
that negotiation between Ethernet and IEEE 802 encapsulation was not
required, only negotiation between standard Ethernet [RFC894] and
trailer [RFC893] encapsulation. Had hosts supporting trailer
encapsulation also supported IEEE 802 framing, the negotiation would
have been complicated still further.
[RFC1122] Section 2.3.1 provided the following guidance for use of
trailer encapsulation:
The trailer protocol for link-layer encapsulation MAY be used, but
only when it has been verified that both systems (host or gateway)
involved in the link-layer communication implement trailers. If
the system does not dynamically negotiate use of the trailer
protocol on a per-destination basis, the default configuration
MUST disable the protocol.
4.2BSD did not support dynamic negotiation, only configuration of
trailer encapsulation at boot time, and therefore [RFC1122] required
that the trailer encapsulation be disabled by default on those
systems.
1.4. Potential Mitigations
In order to mitigate problems arising from multiple encapsulation
methods, it may be possible to use switches or routers, or to attempt
to negotiate the encapsulation method to be used. As described
below, neither approach is completely satisfactory.
The use of switches or routers to enable communication between hosts
utilizing multiple encapsulation methods is not a panacea. If
separate prefixes are used for each encapsulation, then each
encapsulation method can be treated as a separate interface with the
choice of encapsulation determined from the routing table. However,
IAB Informational [Page 7]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
if the same prefix is used for each encapsulation method, it is
necessary to keep state for each destination host.
In situations where multiple encapsulation methods are enabled on a
single link, negotiation may be supported to allow hosts to determine
how to encapsulate a packet for a particular destination host.
Negotiating the encapsulation above the link layer is potentially
problematic since the negotiation itself may need to be carried out
using multiple encapsulations. In theory it is possible to negotiate
an encapsulation method by sending negotiation packets over all
encapsulation methods supported, and keeping state for each
destination host. However, if the encapsulation method must be
dynamically negotiated for each new on-link destination,
communication to new destinations may be delayed. If most
communication is short, and the negotiation requires an extra round
trip beyond link-layer address resolution, this can become a
noticeable factor in performance. Also, the negotiation may result
in consumption of additional bandwidth.
2. Evaluation of Arguments for Multiple Encapsulations
There are several reasons often given in support of multiple
encapsulation methods. We discuss each in turn, below.
2.1. Efficiency
Claim: Multiple encapsulation methods allow for greater efficiency.
For example, it has been argued that IEEE 802 or Ethernet
encapsulation of IP results in excessive overhead due to the size of
the data frame headers, and that this can adversely affect
performance on wireless networks, particularly in situations where
support of Voice over IP (VOIP) is required.
Discussion: Even where these performance concerns are valid,
solutions exist that do not require defining multiple IP
encapsulation methods. For example, links may support Ethernet frame
compression so that Ethernet Source and Destination Address fields
are not sent with every packet.
It is possible for link layers to negotiate compression without
requiring higher layer awareness; the Point-to-Point Protocol (PPP)
[RFC1661] is an example. "The PPP Compression Control Protocol
(CCP)" [RFC1962] enables negotiation of data compression mechanisms,
and "Robust Header Compression (ROHC) over PPP" [RFC3241] and "IP
Header Compression over PPP" [RFC3544] enable negotiation of header
compression, without Internet layer awareness. Any frame can be
"decompressed" based on the content of the frame, and prior state
IAB Informational [Page 8]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
based on previous control messages or data frames. Use of
compression is a good way to solve the efficiency problem without
introducing problems at higher layers.
While PPP supports multiple Data Link Layer (DLL) encapsulation
mechanisms for IP packets corresponding to different compression
schemes, in practice only a single compression scheme is negotiated
for use on a link. In addition to DLL protocol numbers allocated for
IPv4 (0x0021) and IPv6 (0x0057), two codepoints have been assigned
for RObust Header Compression (ROHC) [RFC3095] (ROHC small-CID
(0x0003), ROHC large-CIDE (0x0005)), two for Van Jacobson compression
[RFC1144] (Compressed TCP/IP (0x002d), Uncompressed TCP/IP (002f)),
one for IPv6 Header Compression [RFC2507] (0x004f) and nine
codepoints for RTP IP Header Compression [RFC3544], (Full Header
(0x0061), Compressed TCP (0x0063), Compressed Non TCP (0x0065), UDP 8
(0x0067), RTP 8 (0x0069), Compressed TCP No Delta (0x2063), Context
State (0x2065), UDP 16 (0x2067), RTP 16 (0x2069)).
Recommendation: Where encapsulation is an efficiency issue, use
header compression. Where the encapsulation method, or the use of
compression, must be negotiated, negotiation should either occur as
part of bringing up the link, or be piggybacked in the link-layer
address resolution exchange; only a single compression scheme should
be negotiated on a link. Where the MTU may vary among destinations
on the same link, the link layer protocol should provide a per
destination MTU to IP.
2.2. Multicast/Broadcast
Claim: Support for Ethernet encapsulation requires layer 2 support
for distribution of IP multicast/broadcast packets. In order to be
receivable by any host within listening range, a multicast/broadcast
packet sent over a wireless link needs to be sent at the lowest rate
supported by listeners. Since the sending host typically does not
keep track of the rates negotiated by group listeners, by default the
sending rate for multicast/broadcast traffic defaults to the lowest
supported rate, resulting in greatly increased overhead. Therefore
support for Ethernet is potentially problematic and other
encapsulations are necessary.
Discussion: Irrespective of the encapsulation used, IP packets sent
to multicast (IPv4/IPv6) or broadcast addresses (IPv4) need to reach
all potential on-link receivers. Use of alternative encapsulations
cannot remove this requirement. In order to limit the propagation of
link-scope multicast or broadcast traffic, it is possible to assign a
separate prefix to each host.
Unlike broadcasts, which are received by all hosts on the link
IAB Informational [Page 9]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
regardless of the protocol they are running, multicasts only need be
received by those hosts belonging to the multicast group. In wired
networks, it is possible to avoid forwarding multicast traffic on
switch ports without group members, by snooping of Internet Group
Management Protocol (IGMP) and Multicast Listener Discovery (MLD)
traffic as described in "Considerations for IGMP and MLD Snooping
Switches" [RFC4541].
In wireless media where data rates to specific destinations are
negotiated and may vary over a wide range, it may be more efficient
to send multiple frames via link layer unicast than to send a single
multicast/broadcast frame. For example, in [IEEE-802.11]
multicast/broadcast traffic from the client station (STA) to the
Access Point (AP) is sent via link layer unicast.
Recommendation: Where support for link layer multicast/broadcast is
problematic, limit the propagation of link-scope multicast and
broadcast traffic by assignment of separate prefixes to hosts. In
some circumstances, it may be more efficient to distribute
multicast/broadcast traffic as multiple link-layer unicast frames.
2.3. Multiple Uses
Claim: No single encapsulation is optimal for all purposes.
Therefore where a link layer is utilized in disparate scenarios (such
as both fixed and mobile deployments), multiple encapsulations are a
practical requirement.
Discussion: "Architectural Principles of the Internet" [RFC1958]
point 3.2 states:
If there are several ways of doing the same thing, choose one. If
a previous design, in the Internet context or elsewhere, has
successfully solved the same problem, choose the same solution
unless there is a good technical reason not to. Duplication of
the same protocol functionality should be avoided as far as
possible, without of course using this argument to reject
improvements.
Existing encapsulations have proven themselves capable of supporting
disparate usage scenarios. For example, the Point-to-Point Protocol
(PPP) has been utilized by wireless link layers such as GPRS, as well
as in wired networks in applications such as "PPP over SONET/SDH"
[RFC2615]. PPP can even support bridging, as described in "Point-to-
Point Protocol (PPP) Bridging Control Protocol (BCP)" [RFC3518].
Similarly, Ethernet encapsulation has been used in wired networks as
well as Wireless Local Area Networks (LANs) such as IEEE 802.11
IAB Informational [Page 10]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
[IEEE-802.11]. Ethernet can also support Virtual LANs (VLANs) and
Quality of Service (QoS) [IEEE-802.1Q].
Therefore disparate usage scenarios can be addressed by choice of a
single encapsulation, rather than multiple encapsulations. Where an
existing encapsulation is suitable, this is preferable to creating a
new encapsulation.
Where encapsulations other than IP over Point-to-Point Protocol (PPP)
[RFC1661], Ethernet or IEEE 802 are supported, difficulties in
operating system integration can lead to interoperability problems.
In order to take advantage of operating system support for IP
encapsulation over PPP, Ethernet or IEEE 802, it may be tempting for
a driver supporting an alternative encapsulation to emulate PPP,
Ethernet or IEEE 802 support. Typically, PPP emulation requires that
the driver implement PPP, enabling translation of PPP control and
data frames to the equivalent native facilities. Similarly, Ethernet
or IEEE 802 emulation typically requires that the driver implement
Dynamic Host Configuration Protocol (DHCP)v4 or v6, Router
Solicitation/Router Advertisement (RS/RA), Address Resolution
Protocol (ARP) or IPv6 Neighbor Discovery (ND) in order to enable
translation of these frames to and from native facilities.
Where drivers are implemented in kernel mode, the work required to
provide faithful emulation may be substantial. This creates the
temptation to cut corners, potentially resulting in interoperability
problems.
For example, it might be tempting for driver implementations to
neglect IPv6 support. A driver emulating PPP might support only
IPCP, but not IPCPv6; a driver emulating Ethernet or IEEE 802 might
support only DHCPv4 and ARP, but not DHCPv6, RS/RA or ND. As a
result, an IPv6 host connecting to a network supporting IPv6 might
find itself unable to use IPv6 due to lack of driver support.
Recommendation: Support a single existing encapsulation where
possible. Emulation of PPP, Ethernet or IEEE 802 on top of
alternative encapsulations should be avoided.
3. Additional Issues
There are a number of additional issues arising from use of multiple
encapsulation methods, as hinted at in section 1. We discuss each of
these below.
IAB Informational [Page 11]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
3.1. Generality
Link layer protocols such as [IEEE.802-1A.1990] and [DIX] inherently
support the ability to add support for a new packet type without
modification to the link layer protocol. As noted in [Generic],
[IEEE-802.16] appears to imply that the standard will need to be
modified to support new packet types:
We are concerned that the 802.16 protocol cannot easily be
extendable to transport new protocols over the 802.16 air
interface. It would appear that a Convergence Sublayer is needed
for every type of protocol transported over the 802.16 MAC. Every
time a new protocol type needs to be transported over the 802.16
air interface, the 802.16 standard needs to be modified to define
a new CS type. We need to have a generic Packet Convergence
Sublayer that can support multi-protocols and which does not
require further modification to the 802.16 standard to support new
protocols. We believe that this was the original intention of the
Packet CS. Furthermore, we believe it is difficult for the
industry to agree on a set of CSes that all devices must implement
to claim "compliance".
The use of IP and/or upper layer protocol specific encapsulation
methods, rather than a 'neutral' general purpose encapsulation may
give rise to a number of undesirable effects explored in the
following subsections.
If the link layer does not provide a general purpose encapsulation
method, deployment of new IP and/or upper layer protocols will be
dependent on deployment of the corresponding new encapsulation
support in the link layer.
Even if a single encapsulation method is used, problems can still
occur if de-multiplexing of ARP, IPv4, IPv6, and any other protocols
in use, is not supported at the link layer. While is possible to
demultiplex such packets based on the Version field (first four bits
on the packet), this assumes that IPv4-only implementations will be
able to properly handle IPv6 packets. As a result, a more robust
design is to demultiplex protocols in the link layer, such as by
assigning a different protocol type, as is done in IEEE 802 media
where a Type of 0x0800 is used for IPv4, and 0x86DD for IPv6.
Recommendations: Link layer protocols should enable network packets
(IPv4, IPv6, ARP, etc.) to be de-multiplexed in the link layer.
IAB Informational [Page 12]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
3.2. Layer Interdependence
Standardizing IP and/or upper layer specific classification schemes
in the link layer will almost inevitably lead to interdependencies
between the two specifications. Although this might appear to be
desirable in terms of providing a highly specific (and hence
interoperable) mapping between the capabilities provided by the link
layer (e.g., quality of service support) and those that are needed by
the upper layer, this sort of capability is probably better provided
by a more comprehensive service interface (Application Programming
Interface) in conjunction with a single encapsulation mechanism.
IPv6, in particular, provides an extensible header system. An upper
layer specific classification scheme would still have to provide a
degree of generality in order to cope with future extensions of IPv6
that might wish to make use of some of the link layer services
already provided.
Recommendations: Upper layer specific classification schemes should
be avoided.
3.3. Inspection of Payload Contents
If an IP or upper layer specific classification scheme proposes to
inspect the contents of the packet being encapsulated (e.g., 802.16
IP CS mechanisms for determining the connection identifier (CID) to
use to transmit a packet), the fields available for inspection may be
limited if the packet is compressed or encrypted before passing to
the link layer. This may prevent the link layer from utilizing
existing compression mechanisms, such as Van Jacobson Compression
[RFC1144], ROHC [RFC3095][RFC3759], Compressed RTP (CRTP) [RFC2508],
Enhanced Compressed RTP (ECRTP) [RFC3545] or IP Header Compression
[RFC2507].
Recommendations: Classification schemes should not rely on the
contents of the layer 3 payload.
3.4. Interoperability Guidance
In situations where multiple CSes are operational and capable of
carrying IP traffic, interoperability problems are possible in the
absence of clear implementation guidelines. For example, there is no
guarantee that other hosts on the link will support the same set of
CSes, or that if they do, that their routing tables will result in
identical preferences.
IEEE 802.16 [IEEE-802.16] splits the Media Access Control (MAC) layer
into a number of sublayers. For the uppermost of these, the standard
IAB Informational [Page 13]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
defines the concept of a service-specific Convergence Sublayer (CS).
The two underlying sublayers (the MAC Common Part Sublayer and the
Security Sublayer) provide common services for all instantiations of
the CS. While [IEEE-802.16] defined support for the Asynchronous
Transfer Mode (ATM) CS and the Packet CS, [IEEE-802.16e] added
support for four new Convergence Sublayers. As a result,
[IEEE-802.16e] defines the ATM CS, Packet CS, Ethernet CS, IPv4 CS
and IPv6 CS as well as eight other Convergence Sublayers.
In 802.16 the Mobile Station (MS) indicates the Convergence Sublayers
it supports to the Base Station (BS), which selects from the list one
or more that it will support on the link. Therefore it is possible
for multiple CSes to be operational. However, IEEE 802.16 does not
provide multiple encapsulation methods for the same kind of payload;
it defines exactly one encapsulation scheme for each payload. For
example, there is one way to encapsulate a raw IPv4 packet into an
IEEE 802.16 MAC frame, one encapsulation scheme for a raw IPv6
packet, etc. There is also one way to encapsulate an Ethernet frame,
even when there are multiple possibilities for classifying an
Ethernet frame for forwarding over a Connection ID (CID).
Since support for multiple CSes enables IEEE 802.16 to encapsulate
layer 2 frames as well as layer 3 packets, IP packets may be directly
encapsulated in IEEE802.16 MAC frames as well as framed with Ethernet
headers in IEEE802.16 MAC frames. Where CSes supporting both layer 2
frames as well as layer 3 packets are operational on the same link, a
number of issues may arise, including:
Use of Address Resolution Protocol (ARP)
Where both IPv4 CS and Ethernet CS are operational, it may not be
obvious how address resolution should be implemented. For example,
should an ARP frame be encapsulated over the Ethernet CS, or should
alternative mechanisms be used for address resolution, utilizing
the IPv4 CS?
Data Frame Encapsulation
When sending an IP packet, which CS should be used? Where multiple
CSes are operational, the issue can be treated as a multi-homing
problem, with each CS constituting its own interface. Since a
given CS may have associated bandwidth or quality of service
constraints, routing metrics could be adjusted to take this into
account, allowing the routing layer to choose based on which CS
appears more attractive.
This could lead to interoperability problems or routing asymmetry.
For example, consider the effects on IPv6 Neighbor Discovery:
IAB Informational [Page 14]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
[a] If hosts choose to send IPv6 Neighbor Discovery traffic on
different CSes, it is possible that a host sending an IPv6 Neighbor
Discovery packet will not receive a reply, even though the target
host is reachable over another CS.
[b] Where hosts all support the same set of CSes, but have different
routing preferences, it is possible for a host to send an IPv6
Neighbor Discovery packet over one CS and receive a reply over
another CS.
Recommendations: Given these issues, it is strongly recommended that
only a single CS supporting a single encapsulation method be usable
in a given circumstance.
3.5. Service Consistency
If a link layer protocol provides multiple encapsulation methods, the
services offered to the IP and upper layer protocols may differ
qualitatively between the different encapsulation methods. For
example, the 802.16 [IEEE-802.16] link layer protocol offers both
'native' encapsulation for raw IPv4 and IPv6 packets, and emulated
Ethernet encapsulation. In the raw case, the IP layer has direct
access to the quality of service (QoS) capabilities of the 802.16
transmission channels, whereas using the Ethernet encapsulation the
IP QoS has first to be mapped through the rather more limited
capabilities of Ethernet QoS. Consequently, the service offered to
an application depends on the encapsulation method employed and may
be inconsistent between sessions. This may be confusing for the user
and the application.
Recommendations: If multiple encapsulation methods for IP packets on
a single link layer technology are deemed to be necessary, care
should be taken to match the services available between encapsulation
methods as closely as possible.
3.6. Implementation Complexity
Support of multiple encapsulation methods results in additional
implementation complexity. Lack of uniform encapsulation support
also results in potential interoperability problems. To avoid
interoperability issues, devices with limited resources may be
required to implement multiple encapsulation mechanisms, which may
not be practical.
When encapsulation methods require hardware support, implementations
may choose to support different encapsulation sets, resulting in
market fragmentation. This can prevent users from benefiting from
economies of scale, precluding some uses of the technology entirely.
IAB Informational [Page 15]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
Recommendations: Choose a single mandatory to implement
encapsulation mechanism for both sending and receiving, and make that
encapsulation mechanism the default for sending.
3.7. Negotiation
The complexity of negotiation within ARP or IP can be reduced by
performing encapsulation negotiation within the link layer.
However, unless the link layer allows the negotiation of the
encapsulation between any two hosts, then interoperability problems
can still result if more than one encapsulation is possible on a
given link. In general, a host cannot assume that all other hosts on
a link support the same set of encapsulation methods, so that unless
a link layer protocol only supports point-to-point communication,
negotiation of multiple potential encapsulation methods will be
problematic. To avoid this problem, it is desirable for link layer
encapsulation negotiation to determine a single IP encapsulation, not
merely to indicate which encapsulation methods are possible.
Recommendations: Encapsulation negotiation is best handled in the
link layer. In order to avoid dependencies on the data frame
encapsulation mechanism, it is preferable for the negotiation to be
carried out using management frames, if they are supported. If
multiple encapsulations are required and negotiation is provided,
then the negotiation should result in a single encapsulation method
being negotiated on the link.
3.8. Roaming
Where a mobile node roams between base stations or to a fixed
infrastructure and the base stations and fixed infrastructure do not
all support the same set of encapsulations, then it may be necessary
to alter the encapsulation method, potentially in mid-conversation.
Even if the change can be handled seamlessly at the link and IP layer
so that applications are not affected, unless the services offered
over the different encapsulations are equivalent (see Section 3.5)
the service experienced by the application may change as the mobile
node crosses boundaries. If the service is significantly different,
it might even require 'in-flight' renegotiation which most
applications are not equipped to manage.
Recommendations: Ensure uniformity of the encapsulation set
(preferably only a single encapsulation) within a given mobile
domain, between mobile domains, and between mobile domains and fixed
infrastructure. If a link layer protocol offers multiple
encapsulation methods for IP packets, it is strongly recommended that
only one of these encapsulation methods should be in use on any given
IAB Informational [Page 16]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
link or within a single wireless transmission domain.
4. Security Considerations
The use of multiple encapsulation methods does not appear to have
significant security implications.
An attacker might be able to utilize an encapsulation method which
was not in normal use on a link to cause a Denial of Service attack
which would exhaust the processing resources of interfaces if packets
utilizing this encapsulation were passed up the stack to any
significant degree before being discarded. However, the use of
encapsulation methods that need to inspect fields in the packet being
encapsulated in order to provide service classification might deter
the deployment of end-to-end security; this is undesirable.
Similarly, if one method is rarely used, that method is potentially
more likely to have exploitable implementation bugs.
An attacker might be able to force a more cumbersome encapsulation
method between two endpoints, even when a lighter weight one is
available, hence forcing higher resource consumption on the link and
within those endpoints.
If different methods have different security properties, an attacker
might be able to force a less secure method as an elevation path to
get access to some other resource or data.
Where lower layer classification is implemented, encryption of upper
layer headers (e.g. IPsec tunnel mode), may obscure headers required
for classification. As a result, it may be necessary for all
encrypted traffic to flow over a single connection.
5. IANA Considerations
This document has no actions for IANA.
6. Conclusion
The use of multiple encapsulation methods on the same link is
problematic, as discussed above.
Although multiple IP encapsulation methods were defined on Ethernet
cabling, recent implementations support only the Ethernet
encapsulation of IPv4 defined in [RFC894]. In order to avoid a
repeat of the experience with IPv4, for operation of IPv6 on IEEE
802.3 media, only the Ethernet encapsulation was defined in "A Method
for the Transmission of IPv6 Packets over Ethernet Networks"
IAB Informational [Page 17]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
[RFC1972], later updated in [RFC2464].
In addition to the recommendations given earlier, we give the
following general recommendations to avoid problems resulting from
use of multiple IP encapsulation methods:
When developing standards for encapsulating IP packets on a link
layer technology, it is desirable that only a single encapsulation
method should be standardized for each link layer technology;
If a link layer protocol offers multiple encapsulation methods for
IP packets, it is strongly recommended that only one of these
encapsulation methods should be in use within any given link or
wireless transmission domain;
Where multiple encapsulation methods are supported on a link, a
single encapsulation should be mandatory to implement for send and
receive.
7. References
7.1. Informative References
[DIX] Digital Equipment Corporation, Intel Corporation, and
Xerox Corporation, "The Ethernet -- A Local Area Network:
Data Link Layer and Physical Layer (Version 2.0)",
November 1982.
[Generic] Wang, L. et al, "A Generic Packet Convergence Sublayer
(GPCS) for Supporting Multiple Protocols over 802.16 Air
Interface", Submission to IEEE 802.16g:
CB0216g_05_025r4.pdf, November 2005, <http://
www.ieee802.org/16/netman/contrib/C80216g-05_025r4.pdf>.
[IEEE-802.16] Institute of Electrical and Electronics Engineers,
"Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks, Part 16: Air Interface for
Fixed Broadband Wireless Access Systems", IEEE Standard
802.16-2004, October 2004.
[IEEE-802.16e] Institute of Electrical and Electronics Engineers,
"Information technology - Telecommunications and
information exchange between systems - Local and
Metropolitan Area Networks - Part 16: Air Interface for
Fixed and Mobile Broadband Wireless Access Systems,
Amendment for Physical and Medium Access Control Layers
for Combined Fixed and Mobile Operation in Licensed
IAB Informational [Page 18]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
Bands", IEEE P802.16e, September 2005.
[IEEE.802-1A.1990]
Institute of Electrical and Electronics Engineers, "Local
Area Networks and Metropolitan Area Networks: Overview
and Architecture of Network Standards", IEEE Standard
802.1A, 1990.
[IEEE.802-1D.1998]
Institute of Electrical and Electronics Engineers,
"Information technology - Telecommunications and
information exchange between systems - Local area
networks - Media access control (MAC) bridges", IEEE
Standard 802.1D, 1998.
[IEEE.802-3.1985]
Institute of Electrical and Electronics Engineers,
"Carrier Sense Multiple Access with Collision Detection
(CSMA/CD) Access Method and Physical Layer
Specifications", IEEE Standard 802.3, 1985.
[IEEE-802.11] Institute of Electrical and Electronics Engineers,
"Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Standard 802.11, 2003.
[RFC893] Leffler, S. and M. Karels, "Trailer encapsulations", RFC
893, April 1984.
[RFC894] Hornig, C., "Standard for the transmission of IP
datagrams over Ethernet networks", STD 41, RFC 894, April
1984.
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
transmission of IP datagrams over IEEE 802 networks", STD
43, RFC 1042, February 1988.
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC1958] Carpenter, B., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)",
RFC 1962, June 1996.
IAB Informational [Page 19]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
[RFC1972] Crawford, M., "A Method for the Transmission of IPv6
Packets over Ethernet Networks", RFC 1972, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, February
1999.
[RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615,
June 1999.
[RFC3095] Bormann, C., et. al, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP and
uncompressed", RFC 3095, July 2001.
[RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP",
RFC 3241, April 2002.
[RFC3518] Higashiyama, M., Baker, F. and T. Liao, "Point-to-Point
Protocol (PPP) Bridging Control Protocol (BCP)", RFC
3518, April 2003.
[RFC3544] Koren, T., Casner, S. and C. Bormann, "IP Header
Compression over PPP", RFC 3544, July 2003.
[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and
P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with
High Delay, Packet Loss and Reordering", RFC 3545, July
2003.
[RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC):
Terminology and Channel Mapping Examples", RFC 3759,
April 2004.
[RFC4541] Christensen, M., Kimball, K. and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006.
IAB Informational [Page 20]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
Acknowledgments
The authors would like to acknowledge Jeff Mandin, Bob Hinden, Jari
Arkko, and Phil Roberts for contributions to this document.
Appendix A - IAB Members at the time of this writing
Bernard Aboba
Loa Andersson
Brian Carpenter
Leslie Daigle
Elwyn Davies
Kevin Fall
Olaf Kolkman
Kurtis Lindqvist
David Meyer
David Oran
Eric Rescorla
Dave Thaler
Lixia Zhang
Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Elwyn B. Davies
Consultant
Soham, Cambs
UK
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: dthaler@microsoft.com
IAB Informational [Page 21]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 1 October 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
IAB Informational [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-22 05:39:52 |