< draft-housley-etherip-03.txt		draft-housley-etherip-04.txt >
			A new Request for Comments is now available in online RFC libraries.
	Internet Engineering Task Force R. Housley		RFC 3378
	Internet-Draft RSA Laboratories
	April 3, 2002 S. Hollenbeck
	Expires: October 3, 2002 VeriSign, Inc.
	EtherIP: Tunneling Ethernet Frames in IP Datagrams
	<draft-housley-etherip-03.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 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.
	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 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.
	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].
	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 (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 on 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 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.
	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.
	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. 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,
	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.
	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 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.
	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.
	[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.
	[VLAN] Institute of Electrical and Electronics Engineers:		Title: EtherIP: Tunneling Ethernet Frames in IP Datagrams
	"IEEE Standard for Local and Metropolitan Area Networks:		Author(s): R. Housley, S. Hollenbeck
	Virtual Bridge Local Area Networks",		Status: Informational
	ANSI/IEEE Std 802.1Q-1998, 1998.		Date: September 2002
			Mailbox: rhousley@rsasecurity.com, shollenbeck@verisign.com
			Pages: 9
			Characters: 18803
			Updates/Obsoletes/SeeAlso: None
	9. Author's Address		I-D Tag: draft-housley-etherip-04.txt
	Russell Housley		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3378.txt
	RSA Laboratories
	918 Spring Knoll Drive
	Herndon, VA 20170
	USA
	rhousley@rsasecurity.com
	Scott Hollenbeck		This document describes the EtherIP, an early tunneling protocol, to
	VeriSign, Inc.		provide informational and historical context for the assignment of IP
	21345 Ridgetop Circle		protocol 97. EtherIP tunnels Ethernet and IEEE 802.3 media access
	Dulles, VA 20166-6503		control frames in IP datagrams so that non-IP traffic can traverse an
	USA		IP internet. The protocol is very lightweight, and it does not
	shollenbeck@verisign.com		provide protection against infinite loops.
	10. Full Copyright Statement
	Copyright (C) The Internet Society 2002. All Rights Reserved.		This memo provides information for the Internet community. It does
			not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	This document and translations of it may be copied and furnished to oth-		This announcement is sent to the IETF list and the RFC-DIST list.
	ers, and derivative works that comment on or otherwise explain it or		Requests to be added to or deleted from the IETF distribution list
	assist in its implementation may be prepared, copied, published and dis-		should be sent to IETF-REQUEST@IETF.ORG. Requests to be
	tributed, in whole or in part, without restriction of any kind, provided		added to or deleted from the RFC-DIST distribution list should
	that the above copyright notice and this paragraph are included on all		be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	such copies and derivative works. However, this document itself may not
	be modified in any way, such as by removing the copyright notice or ref-
	erences 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		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	revoked by the Internet Society or its successors or assigns.		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	This document and the information contained herein is provided on an "AS		To: rfc-info@RFC-EDITOR.ORG
	IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK		Subject: getting rfcs
	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 FIT-
	NESS FOR A PARTICULAR PURPOSE.
	Acknowledgement		help: ways_to_get_rfcs
	Funding for the RFC Editor function is currently provided by the Inter-		Requests for special distribution should be addressed to either the
	net Society. iety.		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
			specifically noted otherwise on the RFC itself, all RFCs are for
			unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 12 change blocks.
	337 lines changed or deleted		32 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/