EtherIP: Tunneling Ethernet Frames in IP Datagrams
RFC 3378
Document | Type |
RFC - Informational
(September 2002; No errata)
Was draft-housley-etherip (tsv)
|
|
---|---|---|---|
Authors | Russ Housley , Scott Hollenbeck | ||
Last updated | 2015-10-14 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 3378 (Informational) | |
Action Holders |
(None)
|
||
Telechat date | |||
Responsible AD | Thomas Narten | ||
IESG note | published as RFC 3378 | ||
Send notices to | <housley@vigilsec.com> |
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 2002Show full document text