One document matched: draft-ietf-intarea-gre-ipv6-14.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-intarea-gre-ipv6-14" ipr="trust200902"
updates="">
<front>
<title abbrev="GRE IPv6">IPv6 Support for Generic Routing Encapsulation
(GRE)</title>
<author fullname="Carlos Pignataro" initials="C." surname="Pignataro">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>7200-12 Kit Creek Road</street>
<city>Research Triangle Park</city>
<region>North Carolina</region>
<code>27709</code>
<country>USA</country>
</postal>
<email>cpignata@cisco.com</email>
</address>
</author>
<author fullname="Ron Bonica" initials="R." surname="Bonica">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>2251 Corporate Park Drive</street>
<city>Herndon</city>
<region>Virginia</region>
<code/>
<country>USA</country>
</postal>
<email>rbonica@juniper.net</email>
</address>
</author>
<author fullname="Suresh Krishnan" initials="S.K." surname="Krishnan">
<organization>Ericsson</organization>
<address>
<postal>
<street>8400 Decarie Blvd.</street>
<city>Town of Mount Royal</city>
<region>QC</region>
<country>Canada</country>
</postal>
<phone>+1 514 345 7900 x42871</phone>
<email>suresh.krishnan@ericsson.com</email>
</address>
</author>
<date day="1" month="September" year="2015"/>
<area>Internet Area</area>
<workgroup>Intarea Working Group</workgroup>
<keyword>GRE</keyword>
<keyword>IPv6</keyword>
<abstract>
<t>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.</t>
<t>This document specifies GRE procedures for IPv6, used as either the
payload or delivery protocol.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119"/>.</t>
</note>
</front>
<middle>
<section anchor="Intro" title="Introduction">
<t><xref target="RFC2784">Generic Routing Encapsulation (GRE)</xref>
<xref target="RFC2890"/> can be used to carry any network-layer payload
protocol over any network-layer delivery protocol. Currently, GRE
procedures are specified for <xref target="RFC0791">IPv4</xref>, used as
either the payload or delivery protocol. However, GRE procedures are not
specified for <xref target="RFC2460">IPv6</xref>.</t>
<t>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.</t>
<section anchor="Terminology" title="Terminology">
<t>The following terms are used in this document:<list style="symbols">
<t>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.</t>
<t>GRE header - the GRE protocol header. The GRE header is
encapsulated in the GRE delivery header and encapsulates GRE
payload.</t>
<t>GRE payload - a network layer packet that is encapsulated by
the GRE header.</t>
<t>GRE overhead - the combined size of the GRE delivery header and
the GRE header, measured in bytes.</t>
<t>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.</t>
<t>Path MTU Discovery (PMTUD) - A procedure for dynamically
discovering the PMTU between two nodes on the Internet. PMTUD
procedures for IPv6 are defined in <xref target="RFC1981"/>.</t>
<t>GRE MTU (GMTU) - the maximum transmission unit, i.e., maximum
packet size in bytes, 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.</t>
</list></t>
</section>
</section>
<section anchor="Header" title="GRE Header Fields">
<t>This document does not change the GRE header format or any behaviors
specified by RFC 2784 or RFC 2890.</t>
<section title="Checksum Present">
<t>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.</t>
<t>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.</t>
<t>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:</t>
<t><list style="symbols">
<t>if the payload protocol is IPv4, the IPv4 header is protected
by both the GRE Checksum and the IPv4 Checksum</t>
<t>if the payload carries <xref target="RFC0793">TCP</xref>, the
TCP pseudo header, TCP header, and TCP payload are protected by
both the GRE Checksum and TCP Checksum</t>
<t>if the payload carries <xref target="RFC0768">UDP</xref>, the
UDP pseudo header, UDP header, and UDP payload are protected by
both the GRE Checksum and UDP Checksum</t>
</list></t>
<t>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.</t>
<t>Network operators should evaluate risk factors in their networks
and configure GRE ingress nodes appropriately.</t>
</section>
</section>
<section anchor="payload" title="IPv6 as GRE Payload">
<t>The following considerations apply to GRE tunnels that carry an IPv6
payload.</t>
<section title="GRE Protocol Type Considerations">
<t>The Protocol Type field in the GRE header MUST be set to <xref
target="RFC7042">Ether Type </xref> 0x86DD (IPv6).</t>
</section>
<section title="MTU Considerations">
<t>A GRE tunnel MUST be able to carry a 1280-byte IPv6 packet from
ingress to egress, without fragmenting the payload packet. All GRE
tunnels with a GMTU of 1280 bytes 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.</t>
<t>Before activating a GRE tunnel and periodically thereafter, the GRE
ingress node MUST verify the tunnel's ability to carry a 1280-byte
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.</t>
<t>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-byte
IPv6 packet addressed to itself through the tunnel under test.</t>
<t>Many existing <xref target="RFC7588">implementations </xref> 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.</t>
</section>
<section anchor="payMTU" title="Fragmentation Considerations">
<t>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.</t>
<t>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 bytes, the GRE ingress router MUST:</t>
<t><list style="symbols">
<t>discard the IPv6 payload packet</t>
<t>send an <xref target="RFC4443">ICMPv6 Packet Too Big
(PTB)</xref> message to the IPv6 payload packet source. The MTU
field in the ICMPv6 PTB message is set to the GMTU.</t>
</list></t>
<t>When the GRE ingress receives an IPv6 payload packet whose length
is greater than the GMTU, and the GMTU is less than 1280 bytes, the
GRE ingress router MUST:<list style="symbols">
<t>encapsulate the entire IPv6 packet in a single GRE header and
IP delivery header</t>
<t>fragment the delivery header, so that it can be reassembled by
the GRE egress</t>
</list></t>
</section>
</section>
<section anchor="Delivery" title="IPv6 as GRE Delivery Protocol">
<t>The following considerations apply when the delivery protocol is
IPv6.</t>
<section title="Next Header Considerations">
<t>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.</t>
<t>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.</t>
</section>
<section title="Checksum Considerations">
<t>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.</t>
<t>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.</t>
<t>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:</t>
<t><list style="letters">
<t>Drop the packet</t>
<t>De-encapsulate the payload and forward it to its intended
destination</t>
<t>De-encapsulate the payload and forward it to a node other than
its intended destination.</t>
</list>Behaviors a) and b) are acceptable. Behavior c) is not
acceptable.</t>
<t>Behavior c) is possible only when the following conditions are
true:</t>
<t><list style="numbers">
<t>The intended GRE egress node is a Virtual Private Network (VPN)
Provider Edge (PE) router.</t>
<t>The node to which the GRE delivery packet is mistakenly
delivered is also a VPN PE router.</t>
<t>VPNs are attached to both of the above-mentioned nodes. At
least two of these VPN's number hosts from non-unique (e.g., <xref
target="RFC1918"/>) address space.</t>
<t>The intended GRE egress node maintains state that causes it to
decapsulate the packet and forward the payload to its intended
destination</t>
<t>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.</t>
</list></t>
<t>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.</t>
<t>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.</t>
</section>
<section title="MTU Considerations">
<t>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.</t>
<t>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.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The Security Considerations section of <xref target="RFC4023"/>
identifies threats encountered when MPLS is delivered over GRE. These
threats apply to any GRE payload. As stated in RFC 4023, the various
threats can be mitigated through options such as authenticating and/or
encrypting the delivery packet using <xref
target="RFC4301">IPSec</xref>. 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.</t>
<t>More generally, security considerations for IPv6 are discussed in
<xref target="RFC4942"/>. Operational security for IPv6 is discussed in
<xref target="I-D.ietf-opsec-v6"/>, and security concerns for tunnels in
general are discussed in <xref target="RFC6169"/>.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.0791"?>
<?rfc include='reference.RFC.0768'?>
<?rfc include='reference.RFC.0793'?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.1981"?>
<?rfc include="reference.RFC.2460"?>
<?rfc include="reference.RFC.4023"?>
<?rfc include="reference.RFC.2784"?>
<?rfc include="reference.RFC.2890"?>
<?rfc include="reference.RFC.4301"?>
<?rfc include="reference.RFC.4443"?>
<?rfc ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4942"?>
<?rfc include="reference.I-D.ietf-opsec-v6.xml"?>
<?rfc include='reference.RFC.7042'?>
<?rfc include='reference.RFC.1918'?>
<?rfc include='reference.RFC.7588'?>
<?rfc include="reference.RFC.6169"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:47:11 |