rfc2784.txt

RFC 的详细文档！

   GRE uses an ETHER Type for the Protocol Type. New ETHER TYPES are
   assigned by Xerox Systems Institute [RFC1700].

8. Acknowledgments

   This document is derived from the original ideas of the authors of
   RFC 1701 and RFC 1702. Hitoshi Asaeda, Scott Bradner, Randy Bush,
   Brian Carpenter, Bill Fenner, Andy Malis, Thomas Narten, Dave Thaler,
   Tim Gleeson and others provided many constructive and insightful
   comments.

















Farinacci, et al.           Standards Track                     [Page 5]

RFC 2784             Generic Routing Encapsulation            March 2000


9. Appendix -- Known Issues

   This document specifies the behavior of currently deployed GRE
   implementations. As such, it does not attempt to address the
   following known issues:

   o Interaction Path MTU Discovery (PMTU) [RFC1191]

     Existing implementations of GRE, when using IPv4 as the Delivery
     Header, do not implement Path MTU discovery and do not set the
     Don't Fragment bit in the Delivery Header.  This can cause large
     packets to become fragmented within the tunnel and reassembled at
     the tunnel exit (independent of whether the payload packet is using
     PMTU).  If a tunnel entry point were to use Path MTU discovery,
     however, that tunnel entry point would also need to relay ICMP
     unreachable error messages (in particular the "fragmentation needed
     and DF set" code) back to the originator of the packet, which is
     not a requirement in this specification. Failure to properly relay
     Path MTU information to an originator can result in the following
     behavior: the originator sets the don't fragment bit, the packet
     gets dropped within the tunnel, but since the originator doesn't
     receive proper feedback, it retransmits with the same PMTU, causing
     subsequently transmitted packets to be dropped.

   o IPv6 as Delivery and/or Payload Protocol

     This specification describes the intersection of GRE currently
     deployed by multiple vendors. IPv6 as delivery and/or payload
     protocol is not included in the currently deployed versions of GRE.

   o Interaction with ICMP

   o Interaction with the Differentiated Services Architecture

   o Multiple and Looping Encapsulations

10. REFERENCES

   [ETYPES]  ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-
             numbers

   [RFC1122] Braden, R., "Requirements for Internet hosts -
             communication layers", STD 3, RFC 1122, October 1989.

   [RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
             November 1990.





Farinacci, et al.           Standards Track                     [Page 6]

RFC 2784             Generic Routing Encapsulation            March 2000


   [RFC1226] Kantor, B., "Internet Protocol Encapsulation of AX.25
             Frames", RFC 1226, May 1991.

   [RFC1234] Provan, D., "Tunneling IPX Traffic through IP Networks",
             RFC 1234, June 1991.

   [RFC1241] Woodburn, R. and D. Mills, "Scheme for an Internet
             Encapsulation Protocol: Version 1", RFC 1241, July 1991.

   [RFC1326] Tsuchiya, P., "Mutual Encapsulation Considered Dangerous",
             RFC 1326, May 1992.

   [RFC1479] Steenstrup, M., "Inter-Domain Policy Routing Protocol
             Specification: Version 1", RFC 1479, July 1993.

   [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
             1700, October 1994.

   [RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
             Routing Encapsulation", RFC 1701, October 1994.

   [RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
             Routing Encapsulation over IPv4 networks", RFC 1702,
             October 1994.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March, 1997.

   [RFC2408] Maughan, D., Schertler, M., Schneider, M. and J.  Turner,
             "Internet Security Association and Key Management Protocol
             (ISAKMP)", RFC 2408, November 1998.

   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
             October, 1998.

   [RFC2637] Hamzeh, K., et al., "Point-to-Point Tunneling Protocol
             (PPTP)", RFC 2637, July, 1999.













Farinacci, et al.           Standards Track                     [Page 7]

RFC 2784             Generic Routing Encapsulation            March 2000


11.  Authors' Addresses

   Dino Farinacci
   Procket Networks
   3850 No. First St., Ste. C
   San Jose, CA 95134

   EMail: [e-mail]


   Tony Li
   Procket Networks
   3850 No. First St., Ste. C
   San Jose, CA 95134

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Stan Hanks
   Enron Communications

   EMail: [e-mail]


   David Meyer
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA, 95134

   EMail: [e-mail]


   Paul Traina
   Juniper Networks
   EMail: [e-mail]














Farinacci, et al.           Standards Track                     [Page 8]

RFC 2784             Generic Routing Encapsulation            March 2000


12.  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.



















Farinacci, et al.           Standards Track                     [Page 9]