draft-ietf-intarea-gre-ipv6-04.txt   draft-ietf-intarea-gre-ipv6-05.txt 
Intarea Working Group C. Pignataro Intarea Working Group C. Pignataro
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 2784 (if approved) R. Bonica Updates: 2784 (if approved) R. Bonica
Intended status: Standards Track Juniper Networks Intended status: Standards Track Juniper Networks
Expires: September 28, 2015 S. Krishnan Expires: October 12, 2015 S. Krishnan
Ericsson Ericsson
March 27, 2015 April 10, 2015
IPv6 Support for Generic Routing Encapsulation (GRE) IPv6 Support for Generic Routing Encapsulation (GRE)
draft-ietf-intarea-gre-ipv6-04 draft-ietf-intarea-gre-ipv6-05
Abstract Abstract
Generic Routing Encapsulation (GRE) can be used to carry any network- Generic Routing Encapsulation (GRE) can be used to carry any network-
layer payload protocol over any network-layer delivery protocol. GRE layer payload protocol over any network-layer delivery protocol. GRE
procedures are specified for IPv4, used as either the payload or procedures are specified for IPv4, used as either the payload or
delivery protocol. However, GRE procedures are not specified for delivery protocol. However, GRE procedures are not specified for
IPv6. IPv6.
This document specifies GRE procedures for IPv6, used as either the This document specifies GRE procedures for IPv6, used as either the
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 28, 2015. This Internet-Draft will expire on October 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. GRE Header Fields . . . . . . . . . . . . . . . . . . . . . . 3 2. GRE Header Fields . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Checksum Present . . . . . . . . . . . . . . . . . . . . 3 2.1. Checksum Present . . . . . . . . . . . . . . . . . . . . 3
2.2. Protocol Type . . . . . . . . . . . . . . . . . . . . . . 3 3. IPv6 As GRE Payload . . . . . . . . . . . . . . . . . . . . . 4
3. IPv6 as a GRE Payload . . . . . . . . . . . . . . . . . . . . 4 3.1. GRE Protocol Type Considerations . . . . . . . . . . . . 4
3.1. MTU Considerations . . . . . . . . . . . . . . . . . . . 4 3.2. MTU Considerations . . . . . . . . . . . . . . . . . . . 4
4. IPv6 as a GRE Delivery Protocol . . . . . . . . . . . . . . . 5 3.3. Fragmentation Considerations . . . . . . . . . . . . . . 4
4.1. Checksum Considerations . . . . . . . . . . . . . . . . . 5 4. IPv6 As GRE Delivery Protocol . . . . . . . . . . . . . . . . 5
4.2. MTU Considerations . . . . . . . . . . . . . . . . . . . 5 4.1. Next Header Considerations . . . . . . . . . . . . . . . 5
4.2. Checksum Considerations . . . . . . . . . . . . . . . . . 5
4.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
Generic Routing Encapsulation (GRE) [RFC2784] [RFC2890] can be used Generic Routing Encapsulation (GRE) [RFC2784] [RFC2890] can be used
to carry any network-layer payload protocol over any network-layer to carry any network-layer payload protocol over any network-layer
delivery protocol. GRE procedures are specified for IPv4 [RFC0791], delivery protocol. GRE procedures are specified for IPv4 [RFC0791],
used as either the payload or delivery protocol. However, GRE used as either the payload or delivery protocol. However, GRE
procedures are not specified for IPv6 [RFC2460]. procedures are not specified for IPv6 [RFC2460].
This document specifies GRE procedures for IPv6, used as either the This document specifies GRE procedures for IPv6, used as either the
payload or delivery protocol. It updates RFC 2784 [RFC2784]. Like payload or delivery protocol. Like RFC 2784, this document describes
RFC 2784, this specification describes GRE how has been implemented GRE how has been implemented by several vendors. It updates RFC 2784
by several vendors. .
1.1. Terminology 1.1. Terminology
The following terms are specific to GRE and are taken from [RFC2784]: The following terms are used in this document:
o GRE delivery header - an IPv4 or IPv6 header whose source address o GRE delivery header - an IPv4 or IPv6 header whose source address
represents the GRE ingress node and whose destination address represents the GRE ingress node and whose destination address
represents the GRE egress node. The GRE delivery header represents the GRE egress node. The GRE delivery header
encapsulates a GRE header. encapsulates a GRE header.
o GRE header - the GRE protocol header. The GRE header is o GRE header - the GRE protocol header. The GRE header is
encapsulated in the GRE delivery header and encapsulates GRE encapsulated in the GRE delivery header and encapsulates GRE
payload. payload.
o GRE payload - a network layer packet that is encapsulated by the o GRE payload - a network layer packet that is encapsulated by the
GRE header. GRE header.
The following terms are specific MTU discovery: o GRE overhead - the combined size of the GRE delivery header and
the GRE header, measured in bytes
o path MTU (PMTU) - the minimum MTU of all the links in a path 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 between a source node and a destination node. If the source and
destination node are connected through equal cost multipath destination node are connected through equal cost multipath
(ECMP), the PMTU is equal to the minimum link MTU of all links (ECMP), the PMTU is equal to the minimum link MTU of all links
contributing to the multipath. contributing to the multipath.
o Path MTU Discovery (PMTUD) - A procedure for dynamically o Path MTU Discovery (PMTUD) - A procedure for dynamically
discovering the PMTU between two nodes on the Internet. PMTUD discovering the PMTU between two nodes on the Internet. PMTUD
procedures for IPv6 are defined in [RFC1981]. procedures for IPv6 are defined in [RFC1981].
o 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
2. GRE Header Fields 2. GRE Header Fields
This document does not change the GRE header format or any behaviors This document does not change the GRE header format or any behaviors
specified by [RFC2784] or [RFC2890]. specified by RFC 2784 or RFC 2890.
2.1. Checksum Present 2.1. Checksum Present
When the delivery protocol is IPv6, the GRE ingress router SHOULD set When the delivery protocol is IPv6, the GRE ingress node SHOULD set
the Checksum Present field to zero. GRE egress routers MUST accept the Checksum Present field to zero. GRE egress nodes MUST accept
either a value of zero or one in this field. If the GRE egress either a value of zero or one in this field. If the GRE egress node
router receives a value of one, it MUST use that information to receives a value of one, it MUST use that information to calculate
calculate the GRE header length. It MUST also use the checksum to the GRE header length. It MUST also use the checksum to verify
verify packet integrity. packet integrity.
2.2. Protocol Type
The Protocol Type field contains the protocol type of the payload 3. IPv6 As GRE Payload
packet. Protocol Types are defined in [ETYPES]. An implementation
receiving a packet containing a Protocol Type which is not listed in
[ETYPES] SHOULD discard the packet.
3. IPv6 as a GRE Payload The following considerations apply to GRE tunnels that carry IPv6
payload.
When the GRE payload is IPv6, the Protocol Type field in the GRE 3.1. GRE Protocol Type Considerations
header MUST be set to 0x86DD.
3.1. MTU Considerations The Protocol Type field in the GRE header MUST be set to Ether Type
[ETYPES] 0x86DD.
The GRE ingress router maintains an estimate of the GRE MTU (GMTU). 3.2. MTU Considerations
The GMTU is equal to the PMTU associated with the path between the
GRE ingress and the GRE egress, minus the GRE overhead. The GRE
overhead is the combined length of the GRE and IP delivery headers.
The GRE ingress router obtains a PMTU estimate using any of the A GRE tunnel MUST be able to carry a 1280-byte IPv6 packet from
following: 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.
o System defaults Before activating a GRE tunnel and periodically thereafter, the GRE
ingress node MUST execute procedures that 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.
o Configuration 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.
o PMTUD 3.3. Fragmentation Considerations
When the GRE ingress receives an IPv6 payload packet whose length is 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 less than or equal to the GMTU, it can encapsulate and forward the
packet without fragmentation of any kind. In this case, the GRE packet without fragmentation of any kind. In this case, the GRE
ingress router MUST NOT fragment the payload or delivery packets. ingress router MUST NOT fragment the payload or delivery packets.
When the GRE ingress receives an IPv6 payload packet whose length is 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 greater than the GMTU, and the GMTU is greater than or equal to 1280
octets, the GRE ingress router MUST: bytes, the GRE ingress router MUST:
o discard the IPv6 payload packet o discard the IPv6 payload packet
o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the IPv6 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 payload packet source. The MTU field in the ICMPv6 PTB message is
set to the GMTU. set to the GMTU.
The GRE ingress router MUST support a configuration option that When the GRE ingress receives an IPv6 payload packet whose length is
determines how the GRE ingress behaves when it receives an IPv6 greater than the GMTU, and the GMTU is less than 1280 bytes, the GRE
payload packet whose length is greater than the GMTU, and the GMTU is ingress router MUST:
less than 1280 octets. In its default configuration, the GRE ingress
router MUST:
o encapsulate the entire IPv6 packet in a single GRE header and IP o encapsulate the entire IPv6 packet in a single GRE header and IP
delivery header delivery header
o fragment the delivery header, so that it can be reassembled by the o fragment the delivery header, so that it can be reassembled by the
GRE egress GRE egress
However, in an alternative configuration, the GRE ingress MAY: 4. IPv6 As GRE Delivery Protocol
o discard the IPv6 packet
o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the IPv6 The following considerations apply when the delivery protocol is
packet source. The MTU field in the ICMPv6 PTB message is set to IPv6.
the GMTU.
4. IPv6 as a GRE Delivery Protocol 4.1. Next Header Considerations
When the GRE delivery protocol is IPv6, the GRE header can When the GRE delivery protocol is IPv6, the GRE header MAY
immediately follow the GRE delivery header. Alternatively, IPv6 immediately follow the GRE delivery header. Alternatively, IPv6
extension headers MAY be inserted between the GRE delivery header and extension headers MAY be inserted between the GRE delivery header and
the GRE header. the GRE header.
If the GRE header immediately follows the GRE delivery header, the If the GRE header immediately follows the GRE delivery header, the
Next Header field in the IPv6 header of the GRE delivery packet MUST 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 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 delivery header and the GRE header, the Next Header field in the last
IPv6 extension header MUST be set to 47. IPv6 extension header MUST be set to 47.
4.1. Checksum Considerations 4.2. Checksum Considerations
As stated in [RFC2784], the Checksum field contains the IP (one's As stated in [RFC2784], the GRE header can contain a checksum. If
complement) checksum sum of the all the 16 bit words in the GRE present, the GRE header checksum can be used to detect corruption of
header and the payload packet. Therefore, the checksum does not the GRE header and GRE payload.
ensure the integrity of the IPv6 delivery header.
Because the IPv6 delivery header does not include a checksum of its The GRE header checksum cannot be used to detect corruption of the
own, it is subject to corruption. However, even if the delivery IPv6 delivery header. Furthermore, the IPv6 delivery header does not
header is corrupted, to likelihood of that corruption resulting in contain a checksum of its own. Therefore, no available checksum can
misdelivery of the payload is extremely low. be used to detect corruption of the IPv6 delivery header.
4.2. MTU Considerations 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:
"IPv6 requires that every link in the Internet have an MTU of 1280 a. Drop the packet
octets or greater. On any link that cannot convey a 1280-octet
packet in one piece, link-specific fragmentation and reassembly must
be provided at a layer below IPv6" [RFC2460].
IP adjacencies formed by GRE over IPv6 share this requirement. The b. De-encapsulate the payload and forward it to its intended
IP adjacency MUST have an MTU of 1280 octets or greater. This destination
requirement is fulfilled if all permissible paths between the GRE
ingress and GRE egress have PMTU greater than the 1280 plus the GRE
overhead.
In case all permissible routes between the GRE ingress and GRE egress c. De-encapsulate the payload and forward it to a node other than
do not have PMTU greater than 1280 plus the GRE overhead, its intended destination. For example, the payload might be
implementations MUST be capable of fragmenting and reassembling the intended for a node on one VPN, but delivered to an identically
GRE delivery header, as described in Section 3.1. numbered node in another VPN.
Behaviors a) and b) are acceptable. Behavior c) is not acceptable.
Before deploying GRE over IPv6, network operators should consider the
likelihood of behavior c) in their network. GRE over IPv6 is
deployable only in environments where the network operator deems the
risk associated with behavior c) to be acceptable.
The risk associated with behavior c) could be mitigated with end-to-
end authentication of the payload.
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. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
6. Security Considerations 6. Security Considerations
This document adds no additional security risks to GRE, beyond what The Security Considerations section of [RFC4023] addresses MPLS in
is specified in [RFC2784]. It also does not provide any additional GRE. However, it applies equally to the current specification.
security for GRE. Beyond that, the current specification introduces no security
considerations beyond those mentioned in RFC 2784.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Fred Baker, Dino Farinacci, Tom The authors would like to thank Fred Baker, Stewart Bryant, Dino
Herbert, Fred Templin, Joe Touch, Andrew Yourtchenko and Lucy Yong Farinacci, Tom Herbert, Fred Templin, Joe Touch, Andrew Yourtchenko
for their thorough review and useful comments. and Lucy Yong for their thorough review and useful comments.
8. Normative References 8. Normative References
[ETYPES] IANA, "ETHER TYPES", 2014, [ETYPES] IANA, "ETHER TYPES", 2014,
<http://www.iana.org/assignments/ieee-802-numbers/ <http://www.iana.org/assignments/ieee-802-numbers/
ieee-802-numbers.xhtml#ieee-802-numbers-1>. ieee-802-numbers.xhtml#ieee-802-numbers-1>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981. 1981.
skipping to change at page 6, line 48 skipping to change at page 7, line 30
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000. March 2000.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000. RFC 2890, September 2000.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
MPLS in IP or Generic Routing Encapsulation (GRE)", RFC
4023, March 2005.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006.
Authors' Addresses Authors' Addresses
Carlos Pignataro Carlos Pignataro
Cisco Systems Cisco Systems
7200-12 Kit Creek Road 7200-12 Kit Creek Road
Research Triangle Park, North Carolina 27709 Research Triangle Park, North Carolina 27709
 End of changes. 38 change blocks. 
86 lines changed or deleted 121 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/