rfc3378.txt

RFC 的详细文档！

      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: [e-mail]


   Scott Hollenbeck
   VeriSign, Inc.
   21345 Ridgetop Circle
   Dulles, VA 20166-6503
   USA

   EMail: [e-mail]

































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]