EtherIP: Tunneling Ethernet Frames in IP Datagrams
RFC 3378

Network Working Group                                         R. Housley
Request for Comments: 3378                              RSA Laboratories
Category: Informational                                    S. Hollenbeck
                                                          VeriSign, Inc.
                                                          September 2002

           EtherIP: Tunneling Ethernet Frames in IP Datagrams

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.

Abstract

   This document describes the EtherIP, an early tunneling protocol, to
   provide informational and historical context for the assignment of IP
   protocol 97.  EtherIP tunnels Ethernet and IEEE 802.3 media access
   control frames in IP datagrams so that non-IP traffic can traverse an
   IP internet.  The protocol is very lightweight, and it does not
   provide protection against infinite loops.

1. Introduction

   EtherIP was first designed and developed in 1991.  This document was
   written to document the protocol for informational purposes and to
   provide historical context for the assignment of IP protocol 97 by
   IANA.

   The IETF Layer Two Tunneling Protocol Extensions (L2TPEXT) Working
   Group and IETF Pseudo Wire Emulation Edge-to-Edge (PWE3) Working
   Group are developing protocols that overcome the deficiencies of
   EtherIP.  In general, the standards track protocols produced by these
   IETF working groups should be used instead of EtherIP.

   The EtherIP protocol is used to tunnel Ethernet [DIX] and IEEE 802.3
   [CSMA/CD] media access control (MAC) frames (including IEEE 802.1Q
   [VLAN] datagrams) across an IP internet.  Tunneling is usually
   performed when the layer three protocol carried in the MAC frames is
   not IP or when encryption obscures the layer three protocol control
   information needed for routing.  EtherIP may be implemented in an end
   station to enable tunneling for that single station, or it may be
   implemented in a bridge-like station to enable tunneling for multiple
   stations connected to a particular local area network (LAN) segment.

Housley & Hollenbeck         Informational                      [Page 1]
RFC 3378                        EtherIP                   September 2002

   EtherIP may be used to enable communications between stations that
   implement Ethernet or IEEE 802.3 with a layer three protocol other
   than IP.  For example, two stations connected to different Ethernet
   LANs using the Xerox Network Systems Internetwork Datagram Protocol
   (IDP) [XNS] could employ EtherIP to enable communications across the
   Internet.

   EtherIP may be used to enable communications between stations that
   encrypt the Ethernet or IEEE 802.3 payload.  Regardless of the layer
   three protocol used, encryption obscures the layer three protocol
   control information, making routing impossible.  For example, two
   stations connected to different Ethernet LANs using IEEE 802.10b
   [SDE] could employ EtherIP to enable encrypted communications across
   the Internet.

   EtherIP may be implemented in a single station to provide tunneling
   of Ethernet or IEEE 802.3 frames for either of the reasons stated
   above.  Such implementations require processing rules to determine
   which MAC frames to tunnel and which MAC frames to ignore.  Most
   often, these processing rules are based on the destination address or
   the EtherType.

   EtherIP may be implemented in a bridge-like station to provide
   tunneling services for all stations connected to a particular LAN
   segment.  Such implementations promiscuously listen to all of the
   traffic on the LAN segment, then apply processing rules to determine
   which MAC frames to tunnel and which MAC frames to ignore.  MAC
   frames that require tunneling are encapsulated with EtherIP and IP,
   then transmitted to the local IP router for delivery to the bridge-
   like station serving the remote LAN.  Most often, these processing
   rules are based on the source address, the destination address, or
   the EtherType.  Care in establishing these rules must be exercised to
   ensure that the same MAC frame does not get transmitted endlessly
   between several bridge-like stations, especially when broadcast or
   multicast destination MAC addresses are used as selection criteria.
   Infinite loops can result if the topology is not restricted to a
   tree, but the construction of the tree is left to the human that is
   configuring the bridge-like stations.

1.1. Conventions Used In This Document

   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 [RFC2119].

Housley & Hollenbeck         Informational                      [Page 2]
RFC 3378                        EtherIP                   September 2002

2. Protocol Format

   EtherIP segments are sent and received as internet datagrams.  An
   Internet Protocol (IP) header carries several information fields,
   including an identifier for the next level protocol.  An EtherIP
   header follows the internet header, providing information specific to
   the EtherIP protocol.

   Internet Protocol version 4 (IPv4) [RFC791] defines an 8-bit field
   called "Protocol" to identify the next level protocol.  The value of
   this field MUST be set to 97 decimal (141 octal, 61 hex) to identify
   an EtherIP datagram.

   EtherIP datagrams contain a 16-bit header and a variable-length
   encapsulated Ethernet or IEEE 802.3 frame that immediately follows IP
   fields.

        +-----------------------+-----------------------------+
        |      |                |                             |
        |  IP  | EtherIP Header | Encapsulated Ethernet Frame |
        |      |                |                             |
        +-----------------------+-----------------------------+

                  Figure 1: EtherIP Datagram Description

   The 16-bit EtherIP header field consists of two parts: a 4-bit
   version field that identifies the EtherIP protocol version and a
   12-bit field reserved for future use.  The value of the version field
   MUST be 3 (three, '0011' binary).  The value of the reserved field
   MUST be 0 (zero).  Earlier versions of this protocol used an 8-bit
   header field.  The Xerox Ethernet Tunnel (XET) employed the 8-bit
   header.  The 16-bit header field provides memory alignment advantages
   in some implementation environments.

   In summary, the EtherIP Header has two fields:

      Bits 0-3:  Protocol version
      Bits 4-15: Reserved for future use

        0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |               |                                               |
     |    VERSION    |                   RESERVED                    |
     |               |                                               |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

                 Figure 2: EtherIP Header Format (in bits)

Housley & Hollenbeck         Informational                      [Page 3]
RFC 3378                        EtherIP                   September 2002

   The encapsulated Ethernet frame field contains a complete Ethernet or
   IEEE 802.3 frame of any type less the frame check sequence (FCS)
   value.  The IP checksum does not provide integrity protection for the
   Ethernet/IEEE 802.3 frame, so some higher-layer protocol encapsulated
   by the Ethernet/IEEE 802.3 frame is expected to provide the integrity
   protection.

3. Sending Procedures

   This section describes the processing to encapsulate an Ethernet or
   IEEE 802.3 MAC frame in an EtherIP datagram.  First, the
   implementation determines whether the MAC frame requires tunneling.
   Then, if tunneling is required, the MAC frame is processed according
   to the steps provided in this section.  Stations processing VLAN
   datagrams MAY need to examine the VLAN header to make appropriate
   tunneling decisions.

   An end station that implements EtherIP may tunnel some traffic, but
   not all traffic.  Thus, the first step in processing a MAC frame is
   to determine if the frame needs to be tunneled or not.  If the
   recipient station is connected to the same LAN as the source station,
   then tunneling is not needed.  If the network connecting the stations
   can route the layer three protocol, then tunneling is not needed.
   Other environment specific criteria MAY also be applied.  If
   tunneling is not needed, skip all EtherIP processing and perform
   normal data link layer processing to transmit the MAC frame.
   Otherwise, follow the steps described below.

   A bridge-like station promiscuously listens to all of the MAC frames
   on the LAN.  Each MAC frame read from the LAN is examined to
   determine if it needs to be tunneled.  If the recipient station is
   connected to the same LAN as the source station, then tunneling is
   not needed.  If the destination MAC address is a router serving the
   LAN, then tunneling is not needed.  Other environment specific
   criteria MAY also be applied.  If tunneling is not needed, then
   discard the MAC frame.  Otherwise, follow the steps described below.

   The EtherIP encapsulation process is as follows:

   1. Prepend the 16-bit EtherIP header to the MAC frame.  The EtherIP
      Version field MUST be set to 3 (three), and the EtherIP Reserved
      field MUST be set to 0 (zero).  The MAC frame MUST NOT include the
      FCS.

   2. Determine the destination IP address of the remote EtherIP
      station.  This address is usually determined from the destination
      MAC address.

Housley & Hollenbeck         Informational                      [Page 4]
RFC 3378                        EtherIP                   September 2002

   3. Encapsulate the EtherIP datagram in an IP datagram with the
      destination IP address determined in the previous step, and the
      IPv4 Protocol field MUST be set to 97 (decimal).

   4. Transmit the resulting IP datagram to the remote EtherIP station
      via the IP router serving the LAN.

4. Receiving Procedures

   This section describes the processing to decapsulate an Ethernet or
   IEEE 802.3 MAC frame from an EtherIP datagram.

   Since a bridge-like station promiscuously listens to all of the MAC
   frames on the LAN, it may need to separate the MAC frames that
   encapsulate IP datagrams addressed to it from MAC frames that are
   candidates for decapsulation.  The process for identifying MAC frames
   that are candidates for decapsulation is as follows:

   1. Perform normal data link layer processing to receive a suspected
      EtherIP datagram.

   2. If the recipient station is connected to the same LAN as the
      source station, then ignore the frame.  In most environments,
      frames with a source MAC address other than the IP router serving
      the LAN are ignored.

   3. If the network connecting the stations can route the layer three
      protocol, then decapsulation is not needed, and the frame is
      ignored.

   4. Ignore frames that do not contain an IP datagram.

   5. Examine the IPv4 protocol field to confirm that the value of the
      field is 97 (decimal).  If not, ignore the frame.

   Other environment specific criteria MAY also be applied.

   Upon reception of an IPv4 datagram with the Protocol field set to 97
   (decimal), the MAC frame is processed as follows:

   1. Examine the 16-bit EtherIP header.  Confirm that the value of the
      version field is 3 (three), and that the value of the Reserved
      field is 0 (zero).  Frames with other values MUST be discarded.

   2. Extract the encapsulated MAC frame from the EtherIP datagram.
      Note that the extracted frame MUST NOT include a FCS value.

Housley & Hollenbeck         Informational                      [Page 5]
RFC 3378                        EtherIP                   September 2002

   3. Perform normal data link layer processing to transmit the
      extracted MAC frame to the destination station on the LAN.  The
      FCS MUST be calculated and appended to the frame as part of the
      data link layer transmission processing.

5. IANA Considerations

   IANA has assigned IP protocol value 97 (decimal) for EtherIP.  No
   further action or review is required.

6. Security Considerations

   EtherIP can be used to enable the transfer of encrypted Ethernet or
   IEEE 802.3 frame payloads.  In this regard, EtherIP can improve
   security.  However, if a firewall permits EtherIP traffic to pass in
   and out of a protected enclave, arbitrary communications are enabled.
   Therefore, if a firewall is configured to permit communication using
   EtherIP, then additional checking of each frame is probably necessary
   to ensure that the security policy that the firewall is installed to
   enforce is not violated.

   Further, the addition of EtherIP can expose a particular environment
   to additional security threats.  Assumptions that might be
   appropriate when all communicating nodes are attached to one Ethernet
   segment or switch may no longer hold when nodes are attached to
   different Ethernet segments or switches are bridged together with
   EtherIP.  It is outside the scope of this specification, which
   documents an existing practice, to fully analyze and review the risks
   of Ethernet tunneling.  The IETF Pseudo-wire Emulation Working Group
   is doing work in this area, and this group is expected to provide
   information about general layering as well as specific Ethernet over
   IP documents.  An example should make the concern clear.  A number of
   IETF standards employ relatively weak security mechanisms when
   communicating nodes are expected to be connected to the same local
   area network.  The Virtual Router Redundancy Protocol [RFC2338] is
   one instance.  The relatively weak security mechanisms represent a
   greater vulnerability in an emulated Ethernet.  One solution is to
   protect the IP datagrams that carry EtherIP with IPsec [RFC2401].

   The IETF Pseudo-wire Emulation Working Group may document other
   security mechanisms as well.

Housley & Hollenbeck         Informational                      [Page 6]
RFC 3378                        EtherIP                   September 2002

7. Acknowledgements

   This document describes a protocol that was originally designed and
   implemented by Xerox Special Information Systems in 1991 and 1992.
   An earlier version of the protocol was provided as part of the Xerox
   Ethernet Tunnel (XET).

8. References

   [CSMA/CD] Institute of Electrical and Electronics Engineers:
             "Carrier Sense Multiple Access with Collision Detection
             (CSMA/CD) Access Method and Physical Layer Specifications",
             ANSI/IEEE Std 802.3-1985, 1985.

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

   [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
             1981.

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

   [RFC2338] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel,
             D., Hunt, P., Higginson, P., Shand, M. and A. Lindem,
             "Virtual Router Redundancy Protocol", RFC 2338, April 1998.

   [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
             Internet Protocol", RFC 2401, November 1998.

   [SDE]     Institute of Electrical and Electronics Engineers:
             "Interoperable LAN/MAN Security (SILS) Secure Data Exchange
             (SDE) (Clause 2)", IEEE Std 802.10b-1992, 1992.

   [XNS]     Xerox Corporation: "Internet Transport Protocols", XSIS
             028112, December 1981.

   [VLAN]    Institute of Electrical and Electronics Engineers: "IEEE
             Standard for Local and Metropolitan Area Networks: Virtual
             Bridge Local Area Networks", ANSI/IEEE Std 802.1Q-1998,
             1998.

Housley & Hollenbeck         Informational                      [Page 7]
RFC 3378                        EtherIP                   September 2002

9. Authors' Addresses

   Russell Housley
   RSA Laboratories
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA

   EMail: rhousley@rsasecurity.com

   Scott Hollenbeck
   VeriSign, Inc.
   21345 Ridgetop Circle
   Dulles, VA 20166-6503
   USA

   EMail: shollenbeck@verisign.com

Housley & Hollenbeck         Informational                      [Page 8]
RFC 3378                        EtherIP                   September 2002

10. Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

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

Housley & Hollenbeck         Informational                      [Page 9]