EtherIP: Tunneling Ethernet Frames in IP Datagrams
RFC 3378

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

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