draft-ietf-intarea-gre-ipv6-11.txt   draft-ietf-intarea-gre-ipv6-12.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 Intended status: Standards Track R. Bonica
Intended status: Standards Track Juniper Networks Expires: February 7, 2016 Juniper Networks
Expires: January 21, 2016 S. Krishnan S. Krishnan
Ericsson Ericsson
July 20, 2015 August 6, 2015
IPv6 Support for Generic Routing Encapsulation (GRE) IPv6 Support for Generic Routing Encapsulation (GRE)
draft-ietf-intarea-gre-ipv6-11 draft-ietf-intarea-gre-ipv6-12
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.
procedures are specified for IPv4, used as either the payload or Currently, GRE procedures are specified for IPv4, used as either the
delivery protocol. However, GRE procedures are not specified for payload or delivery protocol. However, GRE procedures are not
IPv6. specified for IPv6.
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 the GRE specification, RFC payload or delivery protocol.
2784.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 47 skipping to change at page 1, line 46
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 January 21, 2016. This Internet-Draft will expire on February 7, 2016.
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 36 skipping to change at page 2, line 36
3. IPv6 as GRE Payload . . . . . . . . . . . . . . . . . . . . . 4 3. IPv6 as GRE Payload . . . . . . . . . . . . . . . . . . . . . 4
3.1. GRE Protocol Type Considerations . . . . . . . . . . . . 4 3.1. GRE Protocol Type Considerations . . . . . . . . . . . . 4
3.2. MTU Considerations . . . . . . . . . . . . . . . . . . . 4 3.2. MTU Considerations . . . . . . . . . . . . . . . . . . . 4
3.3. Fragmentation Considerations . . . . . . . . . . . . . . 5 3.3. Fragmentation Considerations . . . . . . . . . . . . . . 5
4. IPv6 as GRE Delivery Protocol . . . . . . . . . . . . . . . . 6 4. IPv6 as GRE Delivery Protocol . . . . . . . . . . . . . . . . 6
4.1. Next Header Considerations . . . . . . . . . . . . . . . 6 4.1. Next Header Considerations . . . . . . . . . . . . . . . 6
4.2. Checksum Considerations . . . . . . . . . . . . . . . . . 6 4.2. Checksum Considerations . . . . . . . . . . . . . . . . . 6
4.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 7 4.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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. Currently, GRE procedures are specified for IPv4
used as either the payload or delivery protocol. However, GRE [RFC0791], used as either the payload or delivery protocol. However,
procedures are not specified for IPv6 [RFC2460]. GRE 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. Like RFC 2784, this document describes payload or delivery protocol. Like RFC 2784, this document describes
how GRE has been implemented by several vendors. It updates RFC how GRE has been implemented by several vendors.
2784.
1.1. Terminology 1.1. Terminology
The following terms are used in this document: 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.
skipping to change at page 4, line 38 skipping to change at page 4, line 36
However, if the GRE Checksum Present field is set to zero, the GRE However, if the GRE Checksum Present field is set to zero, the GRE
header is not protected by any checksum. Furthermore, depending on header is not protected by any checksum. Furthermore, depending on
which of the above-mentioned conditions are true, selected portions which of the above-mentioned conditions are true, selected portions
of the GRE payload will not be protected by any checksum. of the GRE payload will not be protected by any checksum.
Network operators should evaluate risk factors in their networks and Network operators should evaluate risk factors in their networks and
configure GRE ingress nodes appropriately. configure GRE ingress nodes appropriately.
3. IPv6 as GRE Payload 3. IPv6 as GRE Payload
The following considerations apply to GRE tunnels that carry IPv6 The following considerations apply to GRE tunnels that carry an IPv6
payload. payload.
3.1. GRE Protocol Type Considerations 3.1. GRE Protocol Type Considerations
The Protocol Type field in the GRE header MUST be set to Ether Type The Protocol Type field in the GRE header MUST be set to Ether Type
[ETYPES] 0x86DD. [ETYPES] 0x86DD (IPv6).
3.2. MTU Considerations 3.2. MTU Considerations
A GRE tunnel MUST be able to carry a 1280-byte IPv6 packet from A GRE tunnel MUST be able to carry a 1280-byte IPv6 packet from
ingress to egress, without fragmenting the payload packet. All GRE ingress to egress, without fragmenting the payload packet. All GRE
tunnels with a GMTU of 1280 bytes or greater satisfy this tunnels with a GMTU of 1280 bytes or greater satisfy this
requirement. GRE tunnels that can fragment and reassemble delivery requirement. GRE tunnels that can fragment and reassemble delivery
packets also satisfy this requirement, regardless of their GMTU. packets also satisfy this requirement, regardless of their GMTU.
However, the ability to fragment and reassemble delivery packets is However, the ability to fragment and reassemble delivery packets is
not a requirement of this specification. This specification requires not a requirement of this specification. This specification requires
only that GRE ingress nodes refrain from activating GRE tunnels that only that GRE ingress nodes refrain from activating GRE tunnels that
do not satisfy the above-mentioned requirement. do not satisfy the above-mentioned requirement.
Before activating a GRE tunnel and periodically thereafter, the GRE Before activating a GRE tunnel and periodically thereafter, the GRE
ingress node MUST execute procedures that verify the tunnel's ability ingress node MUST verify the tunnel's ability to carry a 1280-byte
to carry a 1280-byte IPv6 payload packet from ingress to egress, IPv6 payload packet from ingress to egress, without fragmenting the
without fragmenting the payload. Having executed those procedures, payload. Having executed those procedures, the GRE ingress node MUST
the GRE ingress node MUST activate or deactivate the tunnel activate or deactivate the tunnel accordingly.
accordingly.
Implementation details regarding the above-mentioned verification Implementation details regarding the above-mentioned verification
procedures are beyond the scope of this document. However, a GRE procedures are beyond the scope of this document. However, a GRE
ingress node can verify tunnel capabilities by sending a 1280-byte ingress node can verify tunnel capabilities by sending a 1280-byte
IPv6 packet addressed to itself through the tunnel under test. IPv6 packet addressed to itself through the tunnel under test.
Many existing implementations [I-D.ietf-intarea-gre-mtu] do not Many existing implementations [I-D.ietf-intarea-gre-mtu] do not
support the above-mentioned verification procedures. Unless deployed support the above-mentioned verification procedures. Unless deployed
in environments where the GMTU is guaranteed to be greater than 1280, in environments where the GMTU is guaranteed to be greater than 1280,
these implementations MUST be configured so that the GRE endpoints these implementations MUST be configured so that the GRE endpoints
skipping to change at page 7, line 6 skipping to change at page 6, line 51
b. De-encapsulate the payload and forward it to its intended b. De-encapsulate the payload and forward it to its intended
destination destination
c. De-encapsulate the payload and forward it to a node other than c. De-encapsulate the payload and forward it to a node other than
its intended destination. For example, the payload might be its intended destination. For example, the payload might be
intended for a node on one VPN, but delivered to an identically intended for a node on one VPN, but delivered to an identically
numbered node in another VPN. numbered node in another VPN.
Behaviors a) and b) are acceptable. Behavior c) is not acceptable. Behaviors a) and b) are acceptable. Behavior c) is not acceptable.
However, behavior c) is possible only when the payload destination
address is not globally unique and the GRE egress node provides
disambiguating context to that address.
Before deploying GRE over IPv6, network operators should consider the Before deploying GRE over IPv6, network operators should consider the
likelihood of behavior c) in their network. GRE over IPv6 MUST NOT likelihood of behavior c) in their network. GRE over IPv6 MUST NOT
be deployed other than where the network operator deems the risk be deployed other than where the network operator deems the risk
associated with behavior c) to be acceptable. associated with behavior c) to be acceptable.
The risk associated with behavior c) could be mitigated with end-to- The risk associated with behavior c) could be mitigated with end-to-
end authentication of the payload. end authentication of the payload.
4.3. MTU Considerations 4.3. MTU Considerations
skipping to change at page 7, line 35 skipping to change at page 7, line 35
delivery header. 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
The Security Considerations section of [RFC4023] identifies threats The Security Considerations section of [RFC4023] identifies threats
encountered when MPLS is delivered over GRE. These threats apply to encountered when MPLS is delivered over GRE. These threats apply to
any GRE payload. As stated in RFC 4023, these threats can be any GRE payload. As stated in RFC 4023, the various threats can be
mitigated by authenticating and/or encrypting the delivery packet mitigated through options such as authenticating and/or encrypting
using IPsec [RFC4301]. Alternatively when the payload is IPv6, these the delivery packet using IPSec [RFC4301]. Alternatively when the
threats can also be mitigated by authenticating and/or encrypting the payload is IPv6, these threats can also be mitigated by
payload using IPsec, instead of the delivery packet. Otherwise, the authenticating and/or encrypting the payload using IPsec, instead of
current specification introduces no security considerations beyond the delivery packet. Otherwise, the current specification introduces
those mentioned in RFC 2784. no security considerations beyond those mentioned in RFC 2784.
More generally, security considerations for IPv6 are discussed in More generally, security considerations for IPv6 are discussed in
[RFC4942]. Operational security for IPv6 is discussed in [RFC4942]. Operational security for IPv6 is discussed in
[I-D.ietf-opsec-v6], and security concerns for tunnels in general are [I-D.ietf-opsec-v6], and security concerns for tunnels in general are
discussed in [RFC6169]. discussed in [RFC6169].
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Fred Baker, Stewart Bryant, Carlos The authors would like to thank Fred Baker, Stewart Bryant, Benoit
Jesus Bernardos Cano, Dino Farinacci, David Farmer, Brian Haberman, Claise, Ben Campbell, Carlos Jesus Bernardos Cano, Spencer Dawkins,
Tom Herbert, Fred Templin, Joe Touch, Andrew Yourtchenko and Lucy Dino Farinacci, David Farmer, Brian Haberman, Tom Herbert, Kathleen
Yong for their thorough review and useful comments. Moriarty, Fred Templin, Joe Touch, Andrew Yourtchenko and Lucy Yong
for their thorough review and useful comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[ETYPES] IANA, "ETHER TYPES", 2014,
<http://www.iana.org/assignments/ieee-802-numbers>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>. <http://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>. <http://www.rfc-editor.org/info/rfc791>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
skipping to change at page 9, line 17 skipping to change at page 9, line 22
December 2005, <http://www.rfc-editor.org/info/rfc4301>. December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443, Protocol Version 6 (IPv6) Specification", RFC 4443,
DOI 10.17487/RFC4443, March 2006, DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>. <http://www.rfc-editor.org/info/rfc4443>.
8.2. Informative References 8.2. Informative References
[ETYPES] IANA, "ETHER TYPES", 2014,
<http://www.iana.org/assignments/ieee-802-numbers>.
[I-D.ietf-intarea-gre-mtu] [I-D.ietf-intarea-gre-mtu]
Bonica, R., Pignataro, C., and J. Touch, "A Widely- Bonica, R., Pignataro, C., and J. Touch, "A Widely-
Deployed Solution To The Generic Routing Encapsulation Deployed Solution To The Generic Routing Encapsulation
(GRE) Fragmentation Problem", draft-ietf-intarea-gre- (GRE) Fragmentation Problem", draft-ietf-intarea-gre-
mtu-05 (work in progress), May 2015. mtu-05 (work in progress), May 2015.
[I-D.ietf-opsec-v6] [I-D.ietf-opsec-v6]
Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational
Security Considerations for IPv6 Networks", draft-ietf- Security Considerations for IPv6 Networks", draft-ietf-
opsec-v6-06 (work in progress), March 2015. opsec-v6-06 (work in progress), March 2015.
 End of changes. 17 change blocks. 
39 lines changed or deleted 40 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/