Network Working Group                                      B. Aboba, Ed.
INTERNET-DRAFT                                              Elwyn Davies
Category: Informational                                        D. Thaler
<draft-iab-link-encaps-01.txt>               Internet Architecture Board
7 June 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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on December 1, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).  All Rights Reserved.


   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      7 June 2006

Table of Contents

1.     Introduction ..........................................    3
   1.1        Terminology ....................................    3
   1.2        Ethernet Experience ............................    3
   1.3        Trailer Encapsulation Experience ...............    5
2.     Evaluation of Reasons .................................    7
   2.1        Bridging .......................................    7
   2.2        Efficiency .....................................    8
3.     Additional Issues .....................................    9
   3.1        Generality .....................................    9
   3.2        Layer Interdependence ..........................   10
   3.3        Inspection of Payload Contents .................   11
   3.4        Interoperability Guidance ......................   11
   3.5        Service Consistency ............................   12
   3.6        Implementation Complexity ......................   12
   3.7        Negotiation ....................................   13
   3.8        Roaming ........................................   13
4.     Security Considerations ...............................   14
5.     IANA Considerations ...................................   14
6.     Conclusion ............................................   14
7.     References ............................................   15
   7.1       Informative References ..........................   15
Acknowledgments ..............................................   17
Appendix A - IAB Members .....................................   17
Intellectual Property Statement ..............................   17
Disclaimer of Validity .......................................   18
Copyright Statement ..........................................   18

IAB                           Informational                     [Page 2]

INTERNET-DRAFT   Multiple Encapsulation Methods Harmful      7 June 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"

   Recently new link types have been defined that support multiple
   encapsulation methods.  For example, 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 defines the concept of a
   service-specific Convergence Sublayer (CS) that can be instantiated
   in multiple ways, each with its own data frame encapsulation.  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 ATM CS and the
   Packet CS, [IEEE-802.16e] added support for eight new Convergence
   Sublayers.  In each case there are multiple choices available for
   encapsulating IP packets.

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 physical medium that can sustain data
     communications between multiple network nodes, such as an Ethernet
     (simple or bridged).

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

IAB                           Informational                     [Page 3]

INTERNET-DRAFT   Multiple Encapsulation Methods Harmful      7 June 2006

   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 joint 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 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

      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

      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, necessitating the use
   of a switch or router to enable the hosts supporting disparate
   encapsulation methods to communicate with each other.  However, hosts
   supporting multiple encapsulation methods still needed to determine
   the encapsulation method used to reach a destination host.  As noted
   in [RFC1122], Section 2.3.3:

      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 address these issues, "Requirements for Internet Hosts --

IAB                           Informational                     [Page 4]

INTERNET-DRAFT   Multiple Encapsulation Methods Harmful      7 June 2006

   Communication Layers" [RFC1122] provided guidance in Section 2.3.3:

      Every Internet host connected to a 10Mbps Ethernet cable:

        o    MUST be able to send and receive packets using RFC-894

        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-

   By making Ethernet encapsulation mandatory to implement for both send
   and receive, and also the default for sending, [RFC1122] headed off
   potential interoperability problems.

1.3.  Trailer Encapsulation Experience

   [RFC1122] Section 2.3.1 described the issues with trailer


         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.


         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-

IAB                           Informational                     [Page 5]

INTERNET-DRAFT   Multiple Encapsulation Methods Harmful      7 June 2006

         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

         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

         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.

   "Requirements for Internet Hosts - Communication Layers" [RFC1122]
   Section 2.3.1 provided the following guidance for use of trailer

      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.

   Trailer encapsulation negotiation depends on ARP and can only be used
   where all hosts on the link are within the same broadcast domain.

IAB                           Informational                     [Page 6]

INTERNET-DRAFT   Multiple Encapsulation Methods Harmful      7 June 2006

   Since it assumes that all hosts support standard Ethernet
   encapsulation [RFC894], it did not enable negotiation between
   Ethernet and IEEE 802 encapsulation, only between standard Ethernet
   [RFC894] and trailer [RFC893] encapsulation.

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

   Experience with trailer encapsulation suggests some of the issues
   that may be encountered in attempting to negotiate encapsulation
   above the link layer.  The trailer negotiation mechanism resulted in
   multiple ARP replies.  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, this results in higher bandwidth
   overhead, higher latency when establishing communication, and
   additional complexity in implementations.

2.  Evaluation of Reasons

   There are several reasons often given in support of multiple
   encapsulation methods.  We discuss each in turn, below.

2.1.  Bridging

   Claim: A number of features have been defined for Ethernet that are
   desirable in new link layer protocols, most notably (but not limited
   to) bridging.  Hence in addition to any other encapsulation methods,
   it is desirable to support an Ethernet encapsulation method in order
   to take advantage of existing features without redefining them in the
   context of a new link layer protocol.

   Discussion: Reuse of Ethernet encapsulation is a worthy goal.
   "Architectural Principles of the Internet" [RFC1958] point 3.2

IAB                           Informational                     [Page 7]

INTERNET-DRAFT   Multiple Encapsulation Methods Harmful      7 June 2006


      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

   Furthermore, other features have been added to Ethernet such as
   support for Virtual LANs (VLANs) and Quality of Service (QoS).  Hence
   supporting Ethernet encapsulation has significant value.

   However, this reasoning by itself is only sufficient to motivate a
   single encapsulation method (i.e., Ethernet), but not multiple
   encapsulation methods.

   Recommendation: Support Ethernet encapsulation where possible.

2.2.  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 not the existence of multiple encapsulation methods that is the
   issue; the problem occurs when the encapsulations are visible in the
   upper layers as different broadcast domains.  For instance, the
   problem with Ethernet and IEEE 802.3 encapsulation occurs because the
   IP layer needs to know whether to encapsulate ARP in one way or the
   other; where all hosts on the link do not support the same
   encapsulation method, packets encapsulated in one way will not be
   received by all hosts on the link.  In 802.16 the link-layer address
   resolution design may be affected the choice of the CS.

   In contrast, "The PPP Compression Control Protocol (CCP)" [RFC1962]
   enables negotiation of data compression mechanisms, and "Robust
   Header Compression (ROHC) over PPP" [RFC3241] and "IP Header

IAB                           Informational                     [Page 8]

INTERNET-DRAFT   Multiple Encapsulation Methods Harmful      7 June 2006

   Compression over PPP" [RFC3544] enable negotiation of header
   compression, without IP 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.

   The use of multiple encapsulation methods (even if the only
   difference is compression) can degrade performance if the
   encapsulation mechanisms have differing MTUs.  This can result in
   differing MTUs for on-link destinations;  if the link-layer protocol
   does not provide per-destination MTU's to the IP layer, it will need
   to use a default MTU, which is an upper bound on the actual MTU.  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 as IP Path
   MTU Discovery discovers the correct MTU.

   Finally, even if the MTU does not differ between encapsulation
   methods, 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.

   Recommendations: 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.  Where the MTU may vary among
   destinations on the same link, the link layer protocol should provide
   a per destination MTU to IP.

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.  As noted in [Generic], the
   definition of multiple Convergence Sublayers within 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

IAB                           Informational                     [Page 9]

INTERNET-DRAFT   Multiple Encapsulation Methods Harmful      7 June 2006

      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 demultiplexing 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 demultiplexed in the link layer.

3.2.  Layer Interdependence

   Standardizing IP and/or upper layer specific encapsulation methods 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 non-specific encapsulation.

IAB                           Informational                    [Page 10]

INTERNET-DRAFT   Multiple Encapsulation Methods Harmful      7 June 2006

   IPv6, in particular, provides an extensible header system.  An upper
   layer specific encapsulation method 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 encapsulations should be

3.3.  Inspection of Payload Contents

   If an IP or upper layer specific encapsulation method 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 encrypted before passing to the link layer.

   Recommendations: Encapsulation mechanisms should be neutral with
   respect to the contents of the packet being encapsulated.

3.4.  Interoperability Guidance

   [IEEE-802.16e] has defined multiple Convergence Sublayers capable of
   carrying IP traffic.  In addition to the Ethernet CS, IPv4 CS and
   IPv6 CS, ten other Convergence Sublayers are defined.  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.  In situations where multiple CSes
   are operational and capable of carrying IP traffic, interoperability
   problems are possible in the absence of clear implementation
   guidelines.  Some of the issues that may arise include:

ARP  Where multiple CSes are operational, it may not be obvious how ARP
     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.

     However there is no guarantee that other hosts on the link will

IAB                           Informational                    [Page 11]

INTERNET-DRAFT   Multiple Encapsulation Methods Harmful      7 June 2006

     support the same set of CSes, or that if they do, that their
     routing tables will result in identical preferences.

     This could lead to interoperability problems or routing asymmetry.
     For example, consider the effects on Neighbor Discovery:

[a]  If hosts choose to send Neighbor Discovery traffic on different
     CSes, it is possible that a host sending a 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 a 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 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 IPv4 and IPv6 packets, and emulated
   Ethernet encapsulation.  In the native 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.

IAB                           Informational                    [Page 12]

INTERNET-DRAFT   Multiple Encapsulation Methods Harmful      7 June 2006

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

IAB                           Informational                    [Page 13]

INTERNET-DRAFT   Multiple Encapsulation Methods Harmful      7 June 2006

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

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" [RFC1972].

IAB                           Informational                    [Page 14]

INTERNET-DRAFT   Multiple Encapsulation Methods Harmful      7 June 2006

   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

7.  References

7.1.  Informative References

     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.

     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,

     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.

     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.

IAB                           Informational                    [Page 15]

INTERNET-DRAFT   Multiple Encapsulation Methods Harmful      7 June 2006

     Institute of Electrical and Electronics Engineers, "Local Area
     Networks and Metropolitan Area Networks: Overview and Architecture
     of Network Standards", IEEE Standard 802.1A, 1990.

     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.

     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.

     Leffler, S. and M. Karels, "Trailer encapsulations", RFC 893, April

     Hornig, C., "Standard for the transmission of IP datagrams over
     Ethernet networks", STD 41, RFC 894, April 1984.

     Postel, J. and J. Reynolds, "Standard for the transmission of IP
     datagrams over IEEE 802 networks", STD 43, RFC 1042, February 1988.

     Carpenter, B., "Architectural Principles of the Internet", RFC
     1958, June 1996.

     Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962,
     June 1996.

     Crawford, M., "A Method for the Transmission of IPv6 Packets over
     Ethernet Networks", RFC 1972, August 1996.

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

     Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241,
     April 2002.

IAB                           Informational                    [Page 16]

INTERNET-DRAFT   Multiple Encapsulation Methods Harmful      7 June 2006

     Koren, T., Casner, S. and C. Bormann, "IP Header Compression over
     PPP", RFC 3544, July 2003.


   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

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

   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-

IAB                           Informational                    [Page 17]

INTERNET-DRAFT   Multiple Encapsulation Methods Harmful      7 June 2006

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.


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

IAB                           Informational                    [Page 18]