rfc3378.txt

RFC 的详细文档！

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