draft-ietf-intarea-gre-ipv6-10.txt   draft-ietf-intarea-gre-ipv6-11.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: December 28, 2015 S. Krishnan Expires: January 21, 2016 S. Krishnan
Ericsson Ericsson
June 26, 2015 July 20, 2015
IPv6 Support for Generic Routing Encapsulation (GRE) IPv6 Support for Generic Routing Encapsulation (GRE)
draft-ietf-intarea-gre-ipv6-10 draft-ietf-intarea-gre-ipv6-11
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 December 28, 2015. This Internet-Draft will expire on January 21, 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 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
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 . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8 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. 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].
skipping to change at page 3, line 49 skipping to change at page 3, line 49
associated with the path between the GRE ingress and the GRE associated with the path between the GRE ingress and the GRE
egress, minus the GRE overhead. 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 RFC 2784 or RFC 2890. specified by RFC 2784 or RFC 2890.
2.1. Checksum Present 2.1. Checksum Present
The GRE ingress node SHOULD set the Checksum Present field to zero. The GRE ingress node SHOULD set the Checksum Present field in the GRE
However, implementations MAY support a configuration option that header to zero. However, implementations MAY support a configuration
causes the GRE ingress node to set the Checksum Present field to one. option that causes the GRE ingress node to set the Checksum Present
field to one.
As per RFC 2784, the GRE egress node uses the Checksum Present field As per Section 2.2 of RFC 2784, the GRE egress node uses the Checksum
to calculate the length of the GRE header. If the Checksum Present Present field to calculate the length of the GRE header. If the
field is set to one, the GRE egress node MUST use the GRE Checksum to Checksum Present field is set to one, the GRE egress node MUST use
verify the integrity of the GRE header and payload. the GRE Checksum to verify the integrity of the GRE header and
payload.
Setting the Checksum Present field to zero reduces the computational Setting the Checksum Present field to zero reduces the computational
cost of GRE encapsulation and decapsulation. In many cases, the GRE cost of GRE encapsulation and decapsulation. In many cases, the GRE
Checksum is partially redundant with other checksums. For example: Checksum is partially redundant with other checksums. For example:
o if the payload protocol is IPv4, the IPv4 header is protected by o if the payload protocol is IPv4, the IPv4 header is protected by
both the GRE Checksum and the IPv4 Checksum both the GRE Checksum and the IPv4 Checksum
o if the payload carries TCP [RFC0793], the TCP pseudo header, TCP o if the payload carries TCP [RFC0793], the TCP pseudo header, TCP
header, and TCP payload are protected by both the GRE Checksum and header, and TCP payload are protected by both the GRE Checksum and
skipping to change at page 4, line 33 skipping to change at page 4, line 36
UDP Checksum UDP Checksum
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 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.
3.2. MTU Considerations 3.2. MTU Considerations
skipping to change at page 6, line 5 skipping to change at page 6, line 8
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 less than 1280 bytes, the GRE greater than the GMTU, and the GMTU is less than 1280 bytes, the GRE
ingress router MUST: 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
4. IPv6 As GRE Delivery Protocol 4. IPv6 as GRE Delivery Protocol
The following considerations apply when the delivery protocol is The following considerations apply when the delivery protocol is
IPv6. IPv6.
4.1. Next Header Considerations 4.1. Next Header Considerations
When the GRE delivery protocol is IPv6, the GRE header MAY 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.
skipping to change at page 7, line 41 skipping to change at page 7, line 43
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, these threats can be
mitigated by authenticating and/or encrypting the delivery packet mitigated by authenticating and/or encrypting the delivery packet
using IPsec [RFC4301]. Alternatively when the payload is IPv6, these using IPsec [RFC4301]. Alternatively when the payload is IPv6, these
threats can also be mitigated by authenticating and/or encrypting the threats can also be mitigated by authenticating and/or encrypting the
payload using IPsec, instead of the delivery packet. Otherwise, the payload using IPsec, instead of the delivery packet. Otherwise, the
current specification introduces no security considerations beyond current specification introduces no security considerations beyond
those mentioned in RFC 2784. those mentioned in RFC 2784.
More generically, 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, Carlos
Jesus Bernardos Cano, Dino Farinacci, David Farmer, Brian Haberman, Jesus Bernardos Cano, Dino Farinacci, David Farmer, Brian Haberman,
Tom Herbert, Fred Templin, Joe Touch, Andrew Yourtchenko and Lucy Tom Herbert, Fred Templin, Joe Touch, Andrew Yourtchenko and Lucy
Yong for their thorough review and useful comments. 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, [ETYPES] IANA, "ETHER TYPES", 2014,
<http://www.iana.org/assignments/ieee-802-numbers>. <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,
August 1980. DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
1981. DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
793, September 1981. 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 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996. for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (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. [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. DOI 10.17487/RFC2784, March 2000,
<http://www.rfc-editor.org/info/rfc2784>.
[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, DOI 10.17487/RFC2890, September 2000,
<http://www.rfc-editor.org/info/rfc2890>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
MPLS in IP or Generic Routing Encapsulation (GRE)", RFC "Encapsulating MPLS in IP or Generic Routing Encapsulation
4023, March 2005. (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 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. 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, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Message Protocol (ICMPv6) for the Internet Protocol Control Message Protocol (ICMPv6) for the Internet
Version 6 (IPv6) Specification", RFC 4443, March 2006. Protocol Version 6 (IPv6) Specification", RFC 4443,
DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>.
8.2. Informative References 8.2. Informative References
[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.
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
Co-existence Security Considerations", RFC 4942, September Co-existence Security Considerations", RFC 4942,
2007. DOI 10.17487/RFC4942, September 2007,
<http://www.rfc-editor.org/info/rfc4942>.
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns with IP Tunneling", RFC 6169, April 2011. Concerns with IP Tunneling", RFC 6169,
DOI 10.17487/RFC6169, April 2011,
<http://www.rfc-editor.org/info/rfc6169>.
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
USA USA
Email: cpignata@cisco.com Email: cpignata@cisco.com
 End of changes. 25 change blocks. 
37 lines changed or deleted 55 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/