Internet Engineering Task Force R. Housley
Internet-Draft SPYRUS
October 13, 2000 S. Hollenbeck
Expires: April 13, 2001 VeriSign, Inc.
EtherIP: Tunneling Ethernet Frames in IP Datagrams
<draft-housley-etherip-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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-Drafts.
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
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes a protocol for tunneling Ethernet frames in IP
datagrams so that non-IP traffic can travel across an IP internet.
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 Expires April 13, 2001 [Page 1]
Internet-Draft EtherIP October 13, 2000
1. Introduction
The EtherIP protocol is used to tunnel Ethernet [DIX] and IEEE 802.3
[CSMA/CD] media access control (MAC) frames 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 and end station to enable tunneling for that single
station, or it may be implemented in a bridge-like station to enable
tunneling for all stations connected to a particular local area
network (LAN) segment.
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 XNS 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 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 bypass the tunnel processing.
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.
2. Protocol Format
Housley, Hollenbeck Expires April 13, 2001 [Page 2]
Internet-Draft EtherIP October 13, 2000
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. Internet
Protocol version 6 (IPv6) [RFC1883] defines the "Next Header" field
for this same purpose. The value of this field MUST be set to 97
decimal (141 octal, 61 hex) to identify an EtherIP datagram.
EtherIP datagrams contain an 8-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 8-bit EtherIP header field consists of two parts: a 4-bit version
field that identifies the EtherIP protocol version and a 4-bit field
reserved for future use. The value of the version field MUST be 2
(two, '0010' binary). The value of the reserved field MUST be 0
(zero).
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| | |
| VERSION | RESERVED |
| | |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 2: EtherIP Header Format (in bits)
Bits 0-3: Protocol version
Bits 4-7: Reserved for future use
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
Housley, Hollenbeck Expires April 13, 2001 [Page 3]
Internet-Draft EtherIP October 13, 2000
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.
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.
1. Prepend the EtherIP single-byte header to the MAC frame. The
EtherIP Version field MUST be set to 2 (two), 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. Prepend the IP address to the EtherIP datagram. The destination
address is determined in the previous step, and the IPv4 Protocol or
the IPv6 Next Header field MUST be set to 97 decimal.
4. Perform normal data link layer processing to transmit the resulting
IP datagram to 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. Upon reception of an
IPv4 datagram with the Protocol field or an IPv6 datagram with the
Next Header field set to 97 decimal, the MAC frame is processed
according to the steps provided in this section.
Housley, Hollenbeck Expires April 13, 2001 [Page 4]
Internet-Draft EtherIP October 13, 2000
The first step in processing a received MAC frame is to determine if
the frame needs to be decapsulated or not. If the recipient station
is connected to the same LAN as the source station, then decapsulation
is not needed. If the network connecting the stations can route the
layer three protocol, then decapsulation is not needed. Other
environment specific criteria MAY also be applied. If decapsulation
is not needed, skip all EtherIP processing and perform normal data
link layer processing to receive the MAC frame. Otherwise, follow the
steps described below.
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 described below.
1. Perform normal data link layer processing to receive a suspected
EtherIP datagram from the IP router serving the LAN. Ignore frames
that do not contain an IP datagram.
2. Examine the IPv4 protocol field or the IPv6 Next Header field to
confirm that the value of the field is 97 decimal. Ignore the frame
if not.
3. Examine the EtherIP single-byte header. Confirm that the value of
the version field is 2 (two), and that the value of the Reserved field
is 0 (zero). The frame MUST be discarded if these values are not
found.
4. Extract the encapsulated MAC frame from the EtherIP datagram. Note
that the extracted frame MUST NOT include a FCS value.
5. 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.
Housley, Hollenbeck Expires April 13, 2001 [Page 5]
Internet-Draft EtherIP October 13, 2000
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.
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] J. Postel: "Internet Protocol", RFC 791, September 1981.
[RFC1883] S. Deering and R. Hinden: "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, December 1995.
[RFC2119] S. Bradner: "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
Housley, Hollenbeck Expires April 13, 2001 [Page 6]
Internet-Draft EtherIP October 13, 2000
9. Author's Address
Russell Housley
SPYRUS
381 Elden Street
Suite 1120
Herndon, VA 20170
USA
housley@spyrus.com
Scott Hollenbeck
VeriSign Global Registry Services
21345 Ridgetop Circle
Dulles, VA 20166
USA
shollenbeck@verisign.com
Housley, Hollenbeck Expires April 13, 2001 [Page 7]
Internet-Draft EtherIP October 13, 2000
10. Full Copyright Statement
Copyright (C) The Internet Society 2000. 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 Expires April 13, 2001 [Page 8]