summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3378.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3378.txt')
-rw-r--r--doc/rfc/rfc3378.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc3378.txt b/doc/rfc/rfc3378.txt
new file mode 100644
index 0000000..8dd8477
--- /dev/null
+++ b/doc/rfc/rfc3378.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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]
+