doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc7676.txt b/doc/rfc/rfc7676.txt
new file mode 100644
index 0000000..2187d95
--- /dev/null
+++ b/doc/rfc/rfc7676.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      C. Pignataro
+Request for Comments: 7676                                 Cisco Systems
+Category: Standards Track                                      R. Bonica
+ISSN: 2070-1721                                         Juniper Networks
+                                                             S. Krishnan
+                                                                Ericsson
+                                                            October 2015
+
+
+          IPv6 Support for Generic Routing Encapsulation (GRE)
+
+Abstract
+
+   Generic Routing Encapsulation (GRE) can be used to carry any network-
+   layer payload protocol over any network-layer delivery protocol.
+   Currently, GRE procedures are specified for IPv4, used as either the
+   payload or delivery protocol.  However, GRE procedures are not
+   specified for IPv6.
+
+   This document specifies GRE procedures for IPv6, used as either the
+   payload or delivery protocol.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7676.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                    [Page 1]
+
+RFC 7676                        GRE IPv6                    October 2015
+
+
+Copyright Notice
+
+   Copyright (c) 2015 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
+     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  GRE Header Fields . . . . . . . . . . . . . . . . . . . . . .   4
+     2.1.  Checksum Present  . . . . . . . . . . . . . . . . . . . .   4
+   3.  IPv6 as GRE Payload . . . . . . . . . . . . . . . . . . . . .   5
+     3.1.  GRE Protocol Type Considerations  . . . . . . . . . . . .   5
+     3.2.  MTU Considerations  . . . . . . . . . . . . . . . . . . .   5
+     3.3.  Fragmentation Considerations  . . . . . . . . . . . . . .   5
+   4.  IPv6 as GRE Delivery Protocol . . . . . . . . . . . . . . . .   6
+     4.1.  Next Header Considerations  . . . . . . . . . . . . . . .   6
+     4.2.  Checksum Considerations . . . . . . . . . . . . . . . . .   6
+     4.3.  MTU Considerations  . . . . . . . . . . . . . . . . . . .   8
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
+     6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                    [Page 2]
+
+RFC 7676                        GRE IPv6                    October 2015
+
+
+1.  Introduction
+
+   Generic Routing Encapsulation (GRE) [RFC2784] [RFC2890] can be used
+   to carry any network-layer payload protocol over any network-layer
+   delivery protocol.  Currently, GRE procedures are specified for IPv4
+   [RFC791], used as either the payload or delivery protocol.  However,
+   GRE procedures are not specified for IPv6 [RFC2460].
+
+   This document specifies GRE procedures for IPv6, used as either the
+   payload or delivery protocol.  Like RFC 2784, this document describes
+   how GRE has been implemented by several vendors.
+
+1.1.  Requirements Language
+
+   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].
+
+1.2.  Terminology
+
+   The following terms are used in this document:
+
+   o  GRE delivery header: An IPv4 or IPv6 header whose source address
+      represents the GRE ingress node and whose destination address
+      represents the GRE egress node.  The GRE delivery header
+      encapsulates a GRE header.
+
+   o  GRE header: The GRE protocol header.  The GRE header is
+      encapsulated in the GRE delivery header and encapsulates the GRE
+      payload.
+
+   o  GRE payload: A network-layer packet that is encapsulated by the
+      GRE header.
+
+   o  GRE overhead: The combined size of the GRE delivery header and the
+      GRE header, measured in octets.
+
+   o  Path MTU (PMTU): The minimum MTU of all the links in a path
+      between a source node and a destination node.  If the source and
+      destination node are connected through Equal-Cost Multipath
+      (ECMP), the PMTU is equal to the minimum link MTU of all links
+      contributing to the multipath.
+
+   o  Path MTU Discovery (PMTUD): A procedure for dynamically
+      discovering the PMTU between two nodes on the Internet.  PMTUD
+      procedures for IPv6 are defined in [RFC1981].
+
+
+
+
+
+Pignataro, et al.            Standards Track                    [Page 3]
+
+RFC 7676                        GRE IPv6                    October 2015
+
+
+   o  GRE MTU (GMTU): The maximum transmission unit, i.e., maximum
+      packet size in octets, that can be conveyed over a GRE tunnel
+      without fragmentation of any kind.  The GMTU is equal to the PMTU
+      associated with the path between the GRE ingress and the GRE
+      egress, minus the GRE overhead.
+
+2.  GRE Header Fields
+
+   This document does not change the GRE header format or any behaviors
+   specified by RFC 2784 or RFC 2890.
+
+2.1.  Checksum Present
+
+   The GRE ingress node SHOULD set the Checksum Present field in the GRE
+   header to zero.  However, implementations MAY support a configuration
+   option that causes the GRE ingress node to set the Checksum Present
+   field to one.
+
+   As per Section 2.2 of RFC 2784, the GRE egress node uses the Checksum
+   Present field to calculate the length of the GRE header.  If the
+   Checksum Present field is set to one, the GRE egress node MUST use
+   the GRE Checksum to verify the integrity of the GRE header and
+   payload.
+
+   Setting the Checksum Present field to zero reduces the computational
+   cost of GRE encapsulation and decapsulation.  In many cases, the GRE
+   Checksum is partially redundant with other checksums.  For example:
+
+   o  If the payload protocol is IPv4, the IPv4 header is protected by
+      both the GRE Checksum and the IPv4 Checksum.
+
+   o  If the payload carries TCP [RFC793], the TCP pseudo header, TCP
+      header, and TCP payload are protected by both the GRE Checksum and
+      TCP Checksum.
+
+   o  If the payload carries UDP [RFC768], the UDP pseudo header, UDP
+      header, and UDP payload are protected by both the GRE Checksum and
+      UDP Checksum.
+
+   However, if the GRE Checksum Present field is set to zero, the GRE
+   header is not protected by any checksum.  Furthermore, depending on
+   which of the above-mentioned conditions are true, selected portions
+   of the GRE payload will not be protected by any checksum.
+
+   Network operators should evaluate risk factors in their networks and
+   configure GRE ingress nodes appropriately.
+
+
+
+
+
+Pignataro, et al.            Standards Track                    [Page 4]
+
+RFC 7676                        GRE IPv6                    October 2015
+
+
+3.  IPv6 as GRE Payload
+
+   The following considerations apply to GRE tunnels that carry an IPv6
+   payload.
+
+3.1.  GRE Protocol Type Considerations
+
+   The Protocol Type field in the GRE header MUST be set to Ether Type
+   [RFC7042] 0x86DD (IPv6).
+
+3.2.  MTU Considerations
+
+   A GRE tunnel MUST be able to carry a 1280-octet IPv6 packet from
+   ingress to egress, without fragmenting the payload packet.  All GRE
+   tunnels with a GMTU of 1280 octets or greater satisfy this
+   requirement.  GRE tunnels that can fragment and reassemble delivery
+   packets also satisfy this requirement, regardless of their GMTU.
+   However, the ability to fragment and reassemble delivery packets is
+   not a requirement of this specification.  This specification requires
+   only that GRE ingress nodes refrain from activating GRE tunnels that
+   do not satisfy the above-mentioned requirement.
+
+   Before activating a GRE tunnel and periodically thereafter, the GRE
+   ingress node MUST verify the tunnel's ability to carry a 1280-octet
+   IPv6 payload packet from ingress to egress, without fragmenting the
+   payload.  Having executed those procedures, the GRE ingress node MUST
+   activate or deactivate the tunnel accordingly.
+
+   Implementation details regarding the above-mentioned verification
+   procedures are beyond the scope of this document.  However, a GRE
+   ingress node can verify tunnel capabilities by sending a 1280-octet
+   IPv6 packet addressed to itself through the tunnel under test.
+
+   Many existing implementations [RFC7588] do not support the above-
+   mentioned verification procedures.  Unless deployed in environments
+   where the GMTU is guaranteed to be greater than 1280, these
+   implementations MUST be configured so that the GRE endpoints can
+   fragment and reassemble the GRE delivery packet.
+
+3.3.  Fragmentation Considerations
+
+   When the GRE ingress receives an IPv6 payload packet whose length is
+   less than or equal to the GMTU, it can encapsulate and forward the
+   packet without fragmentation of any kind.  In this case, the GRE
+   ingress router MUST NOT fragment the payload or delivery packets.
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                    [Page 5]
+
+RFC 7676                        GRE IPv6                    October 2015
+
+
+   When the GRE ingress receives an IPv6 payload packet whose length is
+   greater than the GMTU, and the GMTU is greater than or equal to 1280
+   octets, the GRE ingress router MUST:
+
+   o  discard the IPv6 payload packet
+
+   o  send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the IPv6
+      payload packet source.  The MTU field in the ICMPv6 PTB message is
+      set to the GMTU.
+
+   When the GRE ingress receives an IPv6 payload packet whose length is
+   greater than the GMTU, and the GMTU is less than 1280 octets, the GRE
+   ingress router MUST:
+
+   o  encapsulate the entire IPv6 packet in a single GRE header and IP
+      delivery header
+
+   o  fragment the delivery header, so that it can be reassembled by the
+      GRE egress
+
+4.  IPv6 as GRE Delivery Protocol
+
+   The following considerations apply when the delivery protocol is
+   IPv6.
+
+4.1.  Next Header Considerations
+
+   When the GRE delivery protocol is IPv6, the GRE header MAY
+   immediately follow the GRE delivery header.  Alternatively, IPv6
+   extension headers MAY be inserted between the GRE delivery header and
+   the GRE header.
+
+   If the GRE header immediately follows the GRE delivery header, the
+   Next Header field in the IPv6 header of the GRE delivery packet MUST
+   be set to 47.  If extension headers are inserted between the GRE
+   delivery header and the GRE header, the Next Header field in the last
+   IPv6 extension header MUST be set to 47.
+
+4.2.  Checksum Considerations
+
+   As stated in [RFC2784], the GRE header can contain a checksum.  If
+   present, the GRE header checksum can be used to detect corruption of
+   the GRE header and GRE payload.
+
+   The GRE header checksum cannot be used to detect corruption of the
+   IPv6 delivery header.  Furthermore, the IPv6 delivery header does not
+   contain a checksum of its own.  Therefore, no available checksum can
+   be used to detect corruption of the IPv6 delivery header.
+
+
+
+Pignataro, et al.            Standards Track                    [Page 6]
+
+RFC 7676                        GRE IPv6                    October 2015
+
+
+   In one failure scenario, the destination address in the IPv6 delivery
+   header is corrupted.  As a result, the IPv6 delivery packet is
+   delivered to a node other than the intended GRE egress node.
+   Depending upon the state and configuration of that node, it will
+   either:
+
+   a.  Drop the packet
+
+   b.  Decapsulate the payload and forward it to its intended
+       destination
+
+   c.  Decapsulate the payload and forward it to a node other than its
+       intended destination.
+
+   Behaviors a) and b) are acceptable.  Behavior c) is not acceptable.
+
+   Behavior c) is possible only when the following conditions are true:
+
+   1.  The intended GRE egress node is a Virtual Private Network (VPN)
+       Provider Edge (PE) router.
+
+   2.  The node to which the GRE delivery packet is mistakenly delivered
+       is also a VPN PE router.
+
+   3.  VPNs are attached to both of the above-mentioned nodes.  At least
+       two of these VPN's number hosts are from a non-unique (e.g.,
+       [RFC1918]) address space.
+
+   4.  The intended GRE egress node maintains state that causes it to
+       decapsulate the packet and forward the payload to its intended
+       destination
+
+   5.  The node to which the GRE delivery packet is mistakenly delivered
+       maintains state that causes it to decapsulate the packet and
+       forward the payload to an identically numbered host in another
+       VPN.
+
+   While the failure scenario described above is extremely unlikely, a
+   single misdelivered packet can adversely impact applications running
+   on the node to which the packet is misdelivered.  Furthermore,
+   leaking packets across VPN boundaries also constitutes a security
+   breach.  The risk associated with behavior c) could be mitigated with
+   end-to-end authentication of the payload.
+
+   Before deploying GRE over IPv6, network operators should consider the
+   likelihood of behavior c) in their network.  GRE over IPv6 MUST NOT
+   be deployed other than where the network operator deems the risk
+   associated with behavior c) to be acceptable.
+
+
+
+Pignataro, et al.            Standards Track                    [Page 7]
+
+RFC 7676                        GRE IPv6                    October 2015
+
+
+4.3.  MTU Considerations
+
+   By default, the GRE ingress node cannot fragment the IPv6 delivery
+   header.  However, implementations MAY support an optional
+   configuration in which the GRE ingress node can fragment the IPv6
+   delivery header.
+
+   Also by default, the GRE egress node cannot reassemble the IPv6
+   delivery header.  However, implementations MAY support an optional
+   configuration in which the GRE egress node can reassemble the IPv6
+   delivery header.
+
+5.  Security Considerations
+
+   The Security Considerations section of [RFC4023] identifies threats
+   encountered when MPLS is delivered over GRE.  These threats apply to
+   any GRE payload.  As stated in RFC 4023, these various threats can be
+   mitigated through options such as authenticating and/or encrypting
+   the delivery packet using IPsec [RFC4301].  Alternatively, when the
+   payload is IPv6, these threats can also be mitigated by
+   authenticating and/or encrypting the payload using IPsec, instead of
+   the delivery packet.  Otherwise, the current specification introduces
+   no security considerations beyond those mentioned in RFC 2784.
+
+   More generally, security considerations for IPv6 are discussed in
+   [RFC4942].  Operational security for IPv6 is discussed in [OPSEC-V6],
+   and security concerns for tunnels in general are discussed in
+   [RFC6169].
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+              DOI 10.17487/RFC0768, August 1980,
+              <http://www.rfc-editor.org/info/rfc768>.
+
+   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
+              DOI 10.17487/RFC0791, September 1981,
+              <http://www.rfc-editor.org/info/rfc791>.
+
+   [RFC793]   Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, DOI 10.17487/RFC0793, September 1981,
+              <http://www.rfc-editor.org/info/rfc793>.
+
+   [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
+              for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
+              1996, <http://www.rfc-editor.org/info/rfc1981>.
+
+
+
+Pignataro, et al.            Standards Track                    [Page 8]
+
+RFC 7676                        GRE IPv6                    October 2015
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
+              December 1998, <http://www.rfc-editor.org/info/rfc2460>.
+
+   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
+              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
+              DOI 10.17487/RFC2784, March 2000,
+              <http://www.rfc-editor.org/info/rfc2784>.
+
+   [RFC2890]  Dommety, G., "Key and Sequence Number Extensions to GRE",
+              RFC 2890, DOI 10.17487/RFC2890, September 2000,
+              <http://www.rfc-editor.org/info/rfc2890>.
+
+   [RFC4023]  Worster, T., Rekhter, Y., and E. Rosen, Ed.,
+              "Encapsulating MPLS in IP or Generic Routing Encapsulation
+              (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
+              <http://www.rfc-editor.org/info/rfc4023>.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
+              December 2005, <http://www.rfc-editor.org/info/rfc4301>.
+
+   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
+              Control Message Protocol (ICMPv6) for the Internet
+              Protocol Version 6 (IPv6) Specification", RFC 4443,
+              DOI 10.17487/RFC4443, March 2006,
+              <http://www.rfc-editor.org/info/rfc4443>.
+
+6.2.  Informative References
+
+   [OPSEC-V6] Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational
+              Security Considerations for IPv6 Networks", Work in
+              Progress, draft-ietf-opsec-v6-07, September 2015.
+
+   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
+              and E. Lear, "Address Allocation for Private Internets",
+              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
+              <http://www.rfc-editor.org/info/rfc1918>.
+
+   [RFC4942]  Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
+              Co-existence Security Considerations", RFC 4942,
+              DOI 10.17487/RFC4942, September 2007,
+              <http://www.rfc-editor.org/info/rfc4942>.
+
+
+
+Pignataro, et al.            Standards Track                    [Page 9]
+
+RFC 7676                        GRE IPv6                    October 2015
+
+
+   [RFC6169]  Krishnan, S., Thaler, D., and J. Hoagland, "Security
+              Concerns with IP Tunneling", RFC 6169,
+              DOI 10.17487/RFC6169, April 2011,
+              <http://www.rfc-editor.org/info/rfc6169>.
+
+   [RFC7042]  Eastlake 3rd, D. and J. Abley, "IANA Considerations and
+              IETF Protocol and Documentation Usage for IEEE 802
+              Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
+              October 2013, <http://www.rfc-editor.org/info/rfc7042>.
+
+   [RFC7588]  Bonica, R., Pignataro, C., and J. Touch, "A Widely
+              Deployed Solution to the Generic Routing Encapsulation
+              (GRE) Fragmentation Problem", RFC 7588,
+              DOI 10.17487/RFC7588, July 2015,
+              <http://www.rfc-editor.org/info/rfc7588>.
+
+Acknowledgements
+
+   The authors would like to thank Fred Baker, Stewart Bryant, Benoit
+   Claise, Ben Campbell, Carlos Jesus Bernardos Cano, Spencer Dawkins,
+   Dino Farinacci, David Farmer, Brian Haberman, Tom Herbert, Kathleen
+   Moriarty, Fred Templin, Joe Touch, Andrew Yourtchenko, and Lucy Yong
+   for their thorough review and useful comments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                   [Page 10]
+
+RFC 7676                        GRE IPv6                    October 2015
+
+
+Authors' Addresses
+
+   Carlos Pignataro
+   Cisco Systems
+   7200-12 Kit Creek Road
+   Research Triangle Park, North Carolina  27709
+   United States
+
+   Email: cpignata@cisco.com
+
+
+   Ron Bonica
+   Juniper Networks
+   2251 Corporate Park Drive
+   Herndon, Virginia
+   United States
+
+   Email: rbonica@juniper.net
+
+
+   Suresh Krishnan
+   Ericsson
+   8400 Decarie Blvd.
+   Town of Mount Royal, QC
+   Canada
+
+   Phone: +1 514 345 7900 x42871
+   Email: suresh.krishnan@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                   [Page 11]
+