RFC 3378

EtherIP: Tunneling Ethernet Frames in IP Datagrams

📅 published September 2002, from ietf

RFC 3378: EtherIP ✨

Okay bestie, the title block is giving main character. This is RFC 3378 from the Network Working Group, and it's called EtherIP: Tunneling Ethernet Frames in IP Datagrams 🎀. The authors are R. Housley (RSA Laboratories) and S. Hollenbeck (VeriSign, Inc.) 👑. It's Category: Informational 📚, dated September 2002 🍓. It doesn't say it obsoletes or updates anything, so no drama there 🙈.

Status of This Memo 📜

This memo is here to give information to the Internet community 💜. It does not specify an Internet standard of any kind, so think of it as a helpful guide and not a rulebook 🦋. Distribution of this memo is unlimited 🌈.

Abstract 🌸

This doc describes EtherIP, an early tunneling protocol 🧚. It's here to give informational and historical context for the assignment of IP protocol 97 📖. EtherIP tunnels Ethernet and IEEE 802.3 media access control frames inside IP datagrams, so non-IP traffic can travel across an IP internet 🚀. The protocol is super 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 record the protocol for informational purposes and to give historical context for IANA's assignment of IP protocol 97 📚.

The IETF Layer Two Tunneling Protocol Extensions (L2TPEXT) Working Group and the IETF Pseudo Wire Emulation Edge-to-Edge (PWE3) Working Group are building protocols that overcome EtherIP's shortcomings 👑. Generally, the standards track protocols these working groups produce should be used instead of EtherIP 🫶.

EtherIP 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 done when the layer three protocol carried in the MAC frames is not IP, or when encryption hides the layer three protocol control information that routing needs 🔐. EtherIP may be implemented in an end station to tunnel for that single station. It may also be implemented in a bridge-like station to tunnel for multiple stations on a particular local area network (LAN) segment 💅.

EtherIP may be used so stations running Ethernet or IEEE 802.3 with a layer three protocol other than IP can talk to each other 🧚. For example, two stations on different Ethernet LANs using the Xerox Network Systems Internetwork Datagram Protocol (IDP) [XNS] could use EtherIP to communicate across the Internet 🍓.

EtherIP may also be used so stations that encrypt the Ethernet or IEEE 802.3 payload can still communicate 🔒. No matter which layer three protocol is in use, encryption hides the layer three protocol control information, which makes routing impossible 💀. For example, two stations on different Ethernet LANs using IEEE 802.10b [SDE] could use EtherIP for encrypted communication across the Internet 🫶.

EtherIP may be implemented in a single station to tunnel Ethernet or IEEE 802.3 frames for either of the reasons above 💖. These implementations need processing rules that decide which MAC frames to tunnel and which to ignore. Most often, those rules are based on the destination address or the EtherType 📏.

EtherIP may be implemented in a bridge-like station to provide tunneling for all stations on a particular LAN segment 🌸. These implementations promiscuously listen to all of the traffic on the LAN segment, then apply processing rules to decide which MAC frames to tunnel and which to ignore 👀. MAC frames that need tunneling are encapsulated with EtherIP and IP, then sent to the local IP router for delivery to the bridge-like station serving the remote LAN 🚀. Most often, those rules are based on the source address, the destination address, or the EtherType ✨. Care is needed when setting these rules so the same MAC frame doesn't get sent endlessly between several bridge-like stations, especially when broadcast or multicast destination MAC addresses are used as selection criteria 😭. Infinite loops can happen if the topology isn't restricted to a tree, but building the tree is left to the human 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] 💜.

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 and provides 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 the IP fields 🦋.

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

               Figure 1: EtherIP Datagram Description

The 16-bit EtherIP header field has 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, and the Xerox Ethernet Tunnel (XET) used that 8-bit header 🍓. The 16-bit header field gives 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)

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 that frame is expected to provide the integrity protection 🔐.

3. Sending Procedures 🚀

This section describes how to wrap an Ethernet or IEEE 802.3 MAC frame in an EtherIP datagram 💖. First, the implementation decides whether the MAC frame needs tunneling. If it does, the MAC frame goes through the steps in this section. Stations processing VLAN datagrams MAY need to look at the VLAN header to make the right tunneling decisions 👀.

An end station that implements EtherIP may tunnel some traffic but not all of it 🌐. So the first step in processing a MAC frame is deciding whether it needs tunneling 💅. If the recipient station is on the same LAN as the source station, tunneling is not needed ✨. If the network connecting the stations can route the layer three protocol, tunneling is not needed either 🦋. Other environment specific criteria MAY also be applied 📏. If tunneling is not needed, skip all EtherIP processing and do normal data link layer processing to send the MAC frame 🌈. Otherwise, follow the steps below 🎀.

A bridge-like station promiscuously listens to all of the MAC frames on the LAN 👀. Each MAC frame read from the LAN is checked to see if it needs tunneling 🌸. If the recipient station is on the same LAN as the source station, tunneling is not needed 🫶. If the destination MAC address belongs to a router serving the LAN, tunneling is not needed 🍓. Other environment specific criteria MAY also be applied 💜. If tunneling is not needed, discard the MAC frame 🙈. Otherwise, follow the steps below 🚀.

The EtherIP encapsulation process goes like this 💌:

  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.
  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 how to unwrap 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 the MAC frames that are candidates for decapsulation 👀. Here's how to spot those candidates 🔍:

  1. Do normal data link layer processing to receive a suspected EtherIP datagram.
  2. If the recipient station is on the same LAN as the source station, 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, decapsulation is not needed, and the frame is ignored 🌈.
  4. Ignore frames that do not contain an IP datagram 💅.
  5. Check the IPv4 protocol field to confirm its value is 97 (decimal). If not, ignore the frame 🫶.

Other environment specific criteria MAY also be applied 🦋.

When an IPv4 datagram arrives with the Protocol field set to 97 (decimal), the MAC frame is processed like this 🎀:

  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 🍓.
  3. Do normal data link layer processing to send 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 🔐✨

Okay bestie, this is the serious part 😭 EtherIP can be used to carry encrypted Ethernet or IEEE 802.3 frame payloads, so in that way it can actually improve security 🫶. BUT, if a firewall lets EtherIP traffic pass in and out of a protected enclave, then arbitrary communications are enabled 💀. So if a firewall is set up to permit EtherIP, then additional checking of each frame is probably necessary to make sure the firewall's security policy isn't getting violated. Non-negotiable, no cap 🙈

Letting EtherIP through the firewall without checking each frame can quietly open the door to whatever the firewall was built to keep out.

It also gets more complicated. Adding EtherIP can expose a whole environment to new security threats 😰 Assumptions that totally make sense when every communicating node is plugged into one Ethernet segment or switch may stop being true once nodes are on different Ethernet segments, or once switches are bridged together with EtherIP. Fully analyzing and reviewing the risks of Ethernet tunneling is outside the scope of this specification, which just documents an existing practice 📝 The IETF Pseudo-wire Emulation Working Group is working on this area, and this group is expected to provide information about general layering as well as specific Ethernet over IP documents 🧚

Here's an example that makes the concern clear 👀 A bunch of IETF standards use relatively weak security mechanisms when the communicating nodes are expected to be connected to the same local area network. The Virtual Router Redundancy Protocol [RFC2338] is one instance. Those weak mechanisms are a much bigger vulnerability in an emulated Ethernet, so 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 🌸

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.

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

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 🌈✨

📦 where this page comes from