GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4840

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-bit
      value that identifies a transport connection or an uplink
      (UL)/downlink (DL) pair of associated management connections.  A
      connection is a unidirectional mapping between base station (BS)
      and subscriber station (SS) MAC peers.  Each transport
      connection has a particular set of associated parameters
      indicating characteristics such as the ciphersuite and quality-
      of-service.

Aboba, et al. Informational [Page 3] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

 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 encapsulations 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 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.

Aboba, et al. Informational [Page 4] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

 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.  [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
    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 unicast 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.

Aboba, et al. Informational [Page 5] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

1.2.1. IEEE 802.2/802.3 LLC Type 1 Encapsulation

 Prior to standardization of the IEEE 802 encapsulation in [RFC1042],
 an IEEE 802.2/802.3 LLC Type 1 encapsulation was specified in
 [RFC948], utilizing 6 in the Source Service Access Point (SSAP) and
 Destination Service Access Point (DSAP) fields of the IEEE 802.2
 header.  However, since the SSAP and DSAP fields are each only a
 single octet, and the Ethertype values for IP, ARP [RFC826], and RARP
 [RFC903] are greater than 1500, these values cannot be represented in
 the SSAP and DSAP fields.  As a result, the encapsulation described
 in [RFC948] did not support protocols requiring distinct Ethertypes
 such as ARP or RARP, and implementations typically included support
 for alternatives to ARP such as the Probe [PROBE] protocol.  Support
 for ARP, RARP and other IP protocols utilizing distinct Ethertypes
 was addressed in [RFC1042], which obsoleted [RFC948]. [RFC1042]
 utilized the Sub-Network Access Protocol (SNAP) form of the IEEE
 802.2 Logical Link Control (LLC) with the SSAP and DSAP fields set to
 170, including support for the Ethertype field.  As noted in
 "Assigned Numbers" [RFC1010]:
    At an ad hoc special session on "IEEE 802 Networks and ARP", held
    during the TCP Vendors Workshop (August 1986), an approach to a
    consistent way to send DoD-IP datagrams and other IP related
    protocols on 802 networks was developed.
    Due to some evolution of the IEEE 802.2 standards and the need to
    provide for a standard way to do additional DoD-IP related
    protocols (such as the Address Resolution Protocol (ARP) on IEEE
    802 network, the following new policy is established, which will
    replace the old policy (see RFC 960 and RFC 948 [108]).
    The new policy is for the Internet community to use the IEEE 802.2
    encapsulation on 802.3, 802.4, and 802.5 networks by using the
    SNAP with an organization code indicating that the following 16
    bits specify the EtherType code (where IP = 2048 (0800 hex), see
    Ethernet Numbers of Interest).

Aboba, et al. Informational [Page 6] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

                                                                Header
     ...--------+--------+--------+
      MAC Header|      Length     |                    802.{3/4/5} MAC
     ...--------+--------+--------+
     +--------+--------+--------+
     | Dsap=K1| Ssap=K1| control|                            802.2 SAP
     +--------+--------+--------+
     +--------+--------+---------+--------+--------+
     |protocol id or org code =K2|    Ether Type   |        802.2 SNAP
     +--------+--------+---------+--------+--------+
    The total length of the SAP Header and the SNAP header is
    8-octets, making the 802.2 protocol overhead come out on a nice
    boundary.
    K1 is 170.  The IEEE likes to talk about things in little-endian
    bit transmission order and specifies this value as 01010101.  In
    big-endian order, as used in Internet specifications, this becomes
    10101010 binary, or AA hex, or 170 decimal.
    K2 is 0 (zero).
    The use of the IP LSAP (K1 = 6) is to be phased out as quickly as
    possible.
 Many of the issues involved in coexistence of the [RFC948] and
 [RFC1042] encapsulations are similar to those described in Section
 1.2.  For example, due to use of different SSAP/DSAP values, the
 broadcast domain might not include all hosts on the link, and a host
 would need to determine the appropriate encapsulation prior to
 sending.  However, the lack of support for ARP within the [RFC948]
 encapsulation created additional interoperability and implementation
 issues.  For example, the lack of support for ARP in [RFC948] implied
 that implementations supporting both [RFC948] and [RFC894] or
 [RFC1042] encapsulations would need to implement both ARP and an
 alternative address resolution mechanism such as Probe.  Also, since
 the address resolution mechanism for [RFC948] implementations was not
 standardized, interoperability problems would likely have arisen had
 [RFC948] been widely implemented.

1.2.2. Trailer Encapsulation

 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

Aboba, et al. Informational [Page 7] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

 maintained.  Trailers were implemented in 4.2 Berkeley System
 Distribution (BSD), among others.  While, in theory, trailer
 encapsulation could have been applied to the Ethernet [RFC894] or
 IEEE 802 [RFC1042] 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.  Since the [RFC948] encapsulation did
 not support the Ethertype field (or ARP), this mechanism could not
 have been used in [RFC948] implementations.
 [RFC1122], Section 2.3.1, described the issues with trailer
 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.

Aboba, et al. Informational [Page 8] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

       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
       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 encapsulations was not
 required, only negotiation between standard Ethernet [RFC894] and
 trailer [RFC893] encapsulation.  Had hosts supporting trailer
 encapsulation also supported one or more IEEE 802 framing mechanisms,
 the negotiation would have been complicated still further.  For
 example, since [RFC948] implementations did not support the Ethertype
 field or ARP, the trailer negotiation mechanism could not have been
 utilized, and additional difficulty would have been encountered in
 distinguishing trailer encapsulated data frames from normally
 encapsulated frames.
 [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.

Aboba, et al. Informational [Page 9] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

 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.3. PPP Experience

 PPP can support both encapsulation of IEEE 802 frames as defined in
 [RFC3518], as well as IPv4 and IPv6 [RFC2472] packets.  Multiple
 compression schemes are also supported.
 In addition to PPP Data Link Layer (DLL) protocol numbers allocated
 for IPv4 (0x0021), IPv6 (0x0057), and Bridging PDU (0x0031), the
 following codepoints have been assigned:
 o  two for RObust Header Compression (ROHC) [RFC3095]:
    ROHC small-CID (0x0003) and ROHC large-CID (0x0005)
 o  two for Van Jacobson compression [RFC1144]:
    Compressed TCP/IP (0x002d) and Uncompressed TCP/IP (002f)
 o  one for IPv6 Header Compression [RFC2507]: (0x004f)
 o  nine 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), and RTP 16
    (0x2069)
 Although PPP can encapsulate IP packets in multiple ways, typically
 multiple encapsulation schemes are not operational on the same link,
 and therefore the issues described in this document rarely arise.
 For example, while PPP can support both encapsulation of IEEE 802
 frames as defined in [RFC3518], as well as IPv4 and IPv6 [RFC2472]
 packets, in practice, multiple encapsulation mechanisms are not
 operational on the same link.  Similarly, only a single compression
 scheme is typically negotiated for use on a link.

1.4. Potential Mitigations

 In order to mitigate problems arising from multiple encapsulation
 methods, it may be possible to use switches [IEEE-802.1D.2004] or
 routers, or to attempt to negotiate the encapsulation method to be
 used.  As described below, neither approach may be completely
 satisfactory.

Aboba, et al. Informational [Page 10] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

 The use of switches or routers to enable communication between hosts
 utilizing multiple encapsulation methods is not a panacea.  If
 separate unicast prefixes are used for each encapsulation, then the
 choice of encapsulation can be determined from the routing table.  If
 the same unicast prefix is used for each encapsulation method, it is
 necessary to keep state for each destination host.  However, this may
 not work in situations where hosts using different encapsulations
 respond to the same anycast address.
 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)

Aboba, et al. Informational [Page 11] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

 [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
 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.
 There are also situations in which use of multiple encapsulations can
 degrade performance or result in packet loss.  The use of multiple
 encapsulation methods with differing Maximum Transfer Units (MTUs)
 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.
 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 be 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 situations
 where this is difficult, support for Ethernet is problematic and
 other encapsulations are necessary.
 Discussion: Irrespective of the encapsulation used, IP packets sent
 to multicast (IPv4/IPv6) or broadcast (IPv4) addresses need to reach
 all potential on-link receivers.  Use of alternative encapsulations
 cannot remove this requirement, although there is considerable
 flexibility in how it can be met.  Non-Broadcast Multiple Access
 (NBMA) networks can still support the broadcast/multicast service via
 replication of unicast frames.
 Techniques are also available for improving the efficiency of IP
 multicast/broadcast delivery in wireless networks.  In order to be
 receivable by any host within listening range, an IP

Aboba, et al. Informational [Page 12] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

 multicast/broadcast packet sent as link-layer multicast/broadcast
 over a wireless link needs to be sent at the lowest rate supported by
 listeners.  If the sender does not keep track of the rates negotiated
 by group listeners, by default, multicast/broadcast traffic is sent
 at the lowest supported rate, resulting in increased overhead.
 However, a sender can also deliver an IP multicast/broadcast packet
 using unicast frame(s) where this would be more efficient.  For
 example, in IEEE 802.11, multicast/broadcast traffic sent from the
 Station (STA) to the Access Point (AP) is always sent as unicast, and
 the AP tracks the negotiated rate for each STA, so that it can send
 unicast frames at a rate appropriate for each station.
 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
 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.2003]
 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:

Aboba, et al. Informational [Page 13] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

    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 General
 Packet Radio Service (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 (WLANs) such as IEEE 802.11
 [IEEE-802.11.2003].  Ethernet can also support Virtual LANs (VLANs)
 and Quality of Service (QoS) [IEEE-802.1Q.2003].
 Therefore, disparate usage scenarios can be addressed by choosing 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.

Aboba, et al. Informational [Page 14] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

 For example, it might be tempting for driver implementations to
 neglect IPv6 support.  A driver emulating PPP might support only IP
 Control Protocol (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.

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.
 IEEE 802.16 [IEEE-802.16.2004] splits the Media Access Control (MAC)
 layer into a number of sublayers.  For the uppermost of these, the
 standard 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.2004] defined support for the Asynchronous
 Transfer Mode (ATM) CS and the Packet CS for raw IPv4, raw IPv6, and
 Ethernet with a choice of six different classifiers,
 [IEEE-802.16e.2005] added support for raw and Ethernet-framed ROHC
 Enhanced Compressed RTP (ECRTP) compressed packets.  As a result,
 [IEEE-802.16e.2005] defines the ATM CS and multiple versions of the
 Packet CS for the transmission of raw IPv4, raw IPv6, 802.3/Ethernet,
 802.1Q VLAN, IPv4 over 802.3/Ethernet, IPv6 over 802.3/Ethernet, IPv4
 over 802.1Q VLAN, IPv6 over 802.1Q VLAN, raw ROHC-compressed packets,
 raw ECRTP-compressed packets, ROHC-compressed packets over
 802.3/Ethernet. and ECRTP-compressed packets over 802.3/Ethernet.
 As noted in [Generic], [IEEE-802.16.2004] appears to imply that the
 standard will need to be modified to support new packet types:

Aboba, et al. Informational [Page 15] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

    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 CS's that all devices must implement
    to claim "compliance".
 The use of IP and/or upper-layer protocol specific classification and
 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 demultiplexing of ARP, IPv4, IPv6, and any other protocols
 in use, is not supported at the link layer.  While it 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 demultiplexed in the link layer.

3.2. Layer Interdependence

 Within IEEE 802.16, the process by which frames are selected for
 transmission on a connection identifier (CID) is known as
 "classification".  Fields in the Ethernet, IP, and UDP/TCP headers
 can be used for classification; for a particular CS, a defined subset
 of header fields may be applied for that purpose.
 Utilizing IP and/or upper layer headers in link-layer classification
 will almost inevitably lead to interdependencies between link-layer
 and upper-layer specifications.  Although this might appear to be

Aboba, et al. Informational [Page 16] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

 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
 upper layers, 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 a classification scheme utilizing higher-layer headers proposes to
 inspect the contents of the packet being encapsulated (e.g., IEEE
 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: Link-layer classification schemes should not rely on
 the contents of higher-layer headers.

3.4. Interoperability Guidance

 In situations where multiple encapsulation methods 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 encapsulation methods, or that if they do,
 that their routing tables will result in identical preferences.
 In IEEE 802.16, the Subscriber Station (SS) 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.
 Note that IEEE 802.16 does not provide multiple encapsulation methods
 for the same kind of data payload; it defines exactly one

Aboba, et al. Informational [Page 17] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

 encapsulation scheme for each data 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 identifier (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
 IEEE 802.16 MAC frames as well as framed with Ethernet headers in
 IEEE 802.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 on the same
    link, 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 encapsulations are operational, multiple connection
    identifiers (CIDs) will also be present.  The issue can therefore
    be treated as a multi-homing problem, with each CID constituting
    its own interface.  Since a given CID 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 CID (and encapsulation) appears more
    attractive.
 This could lead to interoperability problems or routing asymmetry.
 For example, consider the effects on IPv6 Neighbor Discovery:
 (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 kind of CS supporting a single encapsulation method
 should be usable on a particular link.

Aboba, et al. Informational [Page 18] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

3.5. Service Consistency

 If a link-layer protocol provides multiple encapsulation methods, the
 services offered to the IP-layer and upper-layer protocols may differ
 qualitatively between the different encapsulation methods.  For
 example, the 802.16 [IEEE-802.16.2004] link-layer protocol offers
 both 'native' encapsulation for raw IPv4 and IPv6 packets, and
 Ethernet encapsulation.  In the raw case, the IP layer can be
 directly mapped to the quality-of-service (QoS) capabilities of the
 IEEE 802.16 transmission channels, whereas using the Ethernet
 encapsulation, an IP-over-Ethernet CS has to be deployed to
 circumvent the mapping of the IP QoS to the Ethernet header fields to
 avoid the limitations of Ethernet QoS.  Consequently, the service
 offered to an application depends on the classification 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.
 Recommendations: Choose a single encapsulation mechanism that is
 mandatory to implement 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, interoperability problems can
 still result if more than one encapsulation is possible on a given

Aboba, et al. Informational [Page 19] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

 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
 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 that 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.

Aboba, et al. Informational [Page 20] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

 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, or causing fragmentation.  Since IP fragments
 are more difficult to classify than non-fragments, this may result in
 packet loss or may even expose security vulnerabilities [WEP].
 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.  Similarly, if one method
 is rarely used, that method is potentially more likely to have
 exploitable implementation bugs.
 Since lower-layer classification methods may need to inspect fields
 in the packet being encapsulated, this might deter the deployment of
 end-to-end security, which is undesirable.  Where encryption of upper
 layer headers (e.g., IPsec tunnel mode) is required, this may obscure
 headers required for classification.  As a result, it may be
 necessary for all encrypted traffic to flow over a single connection.

5. 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"
 [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.
    Where multiple encapsulation methods are supported on a link, a
    single encapsulation should be mandatory to implement for send and
    receive.

Aboba, et al. Informational [Page 21] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

6. References

6.1. Normative Reference

 [RFC2119]           Bradner, S., "Key words for use in RFCs to
                     Indicate Requirement Levels", BCP 14, RFC 2119,
                     March 1997.

6.2. 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.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.2004]  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, 2004.
 [IEEE-802.1Q.2003]  IEEE Standards for Local and Metropolitan Area
                     Networks: Draft Standard for Virtual Bridged
                     Local Area Networks, P802.1Q-2003, January 2003.
 [IEEE-802.3.2002]   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, 2002.
 [IEEE-802.11.2003]  Institute of Electrical and Electronics
                     Engineers, "Wireless LAN Medium Access Control
                     (MAC) and Physical Layer (PHY) Specifications",
                     IEEE Standard 802.11, 2003.

Aboba, et al. Informational [Page 22] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

 [IEEE-802.16.2004]  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.2005] 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 Bands", IEEE P802.16e, September 2005.
 [PROBE]             Hewlett Packard, "A Primer on HP Probe",
                     http://www.hp.com/rnd/support/manuals/pdf/
                     hp_probe.pdf, July 1993.
 [RFC826]            Plummer, D., "Ethernet Address Resolution
                     Protocol:  Or converting network protocol
                     addresses to 48.bit Ethernet address for
                     transmission on Ethernet hardware", STD 37, RFC
                     826, November 1982.
 [RFC893]            Leffler, S. and M. Karels, "Trailer
                     encapsulations", RFC 893, April 1984.
 [RFC894]            Hornig, C., "A Standard for the Transmission of
                     IP Datagrams over Ethernet Networks", STD 41, RFC
                     894, April 1984.
 [RFC903]            Finlayson, R., Mann, T., Mogul, J., and M.
                     Theimer, "A Reverse Address Resolution Protocol",
                     STD 38, RFC 903, June 1984.
 [RFC948]            Winston, I., "Two Methods for the Transmission of
                     IP Datagrams over IEEE 802.3 Networks", RFC 948,
                     June 1985.
 [RFC1010]           Reynolds, J. and J. Postel, "Assigned Numbers",
                     RFC 1010, May 1987.

Aboba, et al. Informational [Page 23] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

 [RFC1042]           Postel, J. and J. Reynolds, "Standard for the
                     transmission of IP datagrams over IEEE 802
                     networks", STD 43, RFC 1042, February 1988.
 [RFC1122]           Braden, R., "Requirements for Internet Hosts --
                     Communication Layers", STD 3, RFC 1122, October
                     1989.
 [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.
 [RFC1972]           Crawford, M., "A Method for the Transmission of
                     IPv6 Packets over Ethernet Networks", RFC 1972,
                     August 1996.
 [RFC2472]           Haskin, D. and E. Allen, "IP Version 6 over PPP",
                     RFC 2472, December 1998.
 [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.
 [RFC2684]           Grossman, D. and J. Heinanen, "Multiprotocol
                     Encapsulation over ATM Adaptation Layer 5", RFC
                     2684, September 1999.
 [RFC3095]           Bormann, C., Burmeister, C., Degermark, M.,
                     Fukushima, H., Hannu, H., Jonsson, L-E.,
                     Hakenberg, R., Koren, T., Le, K., Liu, Z.,
                     Martensson, A., Miyazaki, A., Svanbro, K.,

Aboba, et al. Informational [Page 24] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

                     Wiebke, T., Yoshimura, T., and H. Zheng, "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.
 [WEP]               Bittau, A., Handley, M., and J. Lackey, "The
                     Final Nail in WEP's Coffin", Proceedings of the
                     2006 IEEE Symposium on Security and Privacy, pp.
                     386-400.

7. Acknowledgments

 The authors would like to acknowledge Jeff Mandin, Bob Hinden, Jari
 Arkko, Max Riegel, Alfred Hoenes, and Phil Roberts for contributions
 to this document.

Aboba, et al. Informational [Page 25] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

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
 EMail: elwynd@dial.pipex.com
 Phone: +44 7889 488 335
 Dave Thaler
 Microsoft Corporation
 One Microsoft Way
 Redmond, WA 98052
 EMail: dthaler@microsoft.com
 Phone: +1 425 703 8835

Aboba, et al. Informational [Page 26] RFC 4840 Multiple Encapsulation Methods Harmful April 2007

Full Copyright Statement

 Copyright (C) The IETF Trust (2007).
 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.
 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, THE IETF TRUST 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.

Intellectual Property

 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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Aboba, et al. Informational [Page 27]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4840.txt · Last modified: 2007/04/10 21:10 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki