draft-ietf-intarea-gre-ipv6-14.txt   rfc7676.txt 
Intarea Working Group C. Pignataro Internet Engineering Task Force (IETF) C. Pignataro
Internet-Draft Cisco Systems Request for Comments: 7676 Cisco Systems
Intended status: Standards Track R. Bonica Category: Standards Track R. Bonica
Expires: March 4, 2016 Juniper Networks ISSN: 2070-1721 Juniper Networks
S. Krishnan S. Krishnan
Ericsson Ericsson
September 1, 2015 October 2015
IPv6 Support for Generic Routing Encapsulation (GRE) IPv6 Support for Generic Routing Encapsulation (GRE)
draft-ietf-intarea-gre-ipv6-14
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. layer payload protocol over any network-layer delivery protocol.
Currently, GRE procedures are specified for IPv4, used as either the Currently, GRE procedures are specified for IPv4, used as either the
payload or delivery protocol. However, GRE procedures are not payload or delivery protocol. However, GRE procedures are not
specified for 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. payload or delivery protocol.
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].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on March 4, 2016. 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.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. GRE Header Fields . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Checksum Present . . . . . . . . . . . . . . . . . . . . 3 2. GRE Header Fields . . . . . . . . . . . . . . . . . . . . . . 4
3. IPv6 as GRE Payload . . . . . . . . . . . . . . . . . . . . . 4 2.1. Checksum Present . . . . . . . . . . . . . . . . . . . . 4
3.1. GRE Protocol Type Considerations . . . . . . . . . . . . 4 3. IPv6 as GRE Payload . . . . . . . . . . . . . . . . . . . . . 5
3.2. MTU Considerations . . . . . . . . . . . . . . . . . . . 4 3.1. GRE Protocol Type Considerations . . . . . . . . . . . . 5
3.2. MTU Considerations . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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. Currently, GRE procedures are specified for IPv4 delivery protocol. Currently, GRE procedures are specified for IPv4
[RFC0791], used as either the payload or delivery protocol. However, [RFC791], used as either the payload or delivery protocol. However,
GRE 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. how GRE has been implemented by several vendors.
1.1. Terminology 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: 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 the 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.
o GRE overhead - the combined size of the GRE delivery header and o GRE overhead: The combined size of the GRE delivery header and the
the GRE header, measured in bytes. GRE header, measured in octets.
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 o GRE MTU (GMTU): The maximum transmission unit, i.e., maximum
packet size in bytes, that can be conveyed over a GRE tunnel packet size in octets, that can be conveyed over a GRE tunnel
without fragmentation of any kind. The GMTU is equal to the PMTU without fragmentation of any kind. The GMTU is equal to the PMTU
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
skipping to change at page 4, line 15 skipping to change at page 4, line 33
As per Section 2.2 of RFC 2784, the GRE egress node uses the Checksum 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 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 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 the GRE Checksum to verify the integrity of the GRE header and
payload. 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 [RFC793], 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
TCP Checksum TCP Checksum.
o if the payload carries UDP [RFC0768], the UDP pseudo header, UDP o If the payload carries UDP [RFC768], the UDP pseudo header, UDP
header, and UDP payload are protected by both the GRE Checksum and header, and UDP payload are protected by both the GRE Checksum and
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
skipping to change at page 4, line 46 skipping to change at page 5, line 17
The following considerations apply to GRE tunnels that carry an 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
[RFC7042] 0x86DD (IPv6). [RFC7042] 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-octet 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 octets 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 verify the tunnel's ability to carry a 1280-byte ingress node MUST verify the tunnel's ability to carry a 1280-octet
IPv6 payload packet from ingress to egress, without fragmenting the IPv6 payload packet from ingress to egress, without fragmenting the
payload. Having executed those procedures, the GRE ingress node MUST payload. Having executed those procedures, the GRE ingress node MUST
activate or deactivate the tunnel accordingly. activate or deactivate the tunnel 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-octet
IPv6 packet addressed to itself through the tunnel under test. IPv6 packet addressed to itself through the tunnel under test.
Many existing implementations [RFC7588] do not support the above- Many existing implementations [RFC7588] do not support the above-
mentioned verification procedures. Unless deployed in environments mentioned verification procedures. Unless deployed in environments
where the GMTU is guaranteed to be greater than 1280, these where the GMTU is guaranteed to be greater than 1280, these
implementations MUST be configured so that the GRE endpoints can implementations MUST be configured so that the GRE endpoints can
fragment and reassemble the GRE delivery packet. fragment and reassemble the GRE delivery packet.
3.3. Fragmentation Considerations 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
bytes, the GRE ingress router MUST: octets, 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.
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 octets, 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
skipping to change at page 6, line 42 skipping to change at page 7, line 13
be used to detect corruption of the IPv6 delivery header. be used to detect corruption of the IPv6 delivery header.
In one failure scenario, the destination address in the IPv6 delivery In one failure scenario, the destination address in the IPv6 delivery
header is corrupted. As a result, the IPv6 delivery packet is header is corrupted. As a result, the IPv6 delivery packet is
delivered to a node other than the intended GRE egress node. delivered to a node other than the intended GRE egress node.
Depending upon the state and configuration of that node, it will Depending upon the state and configuration of that node, it will
either: either:
a. Drop the packet a. Drop the packet
b. De-encapsulate the payload and forward it to its intended b. Decapsulate the payload and forward it to its intended
destination destination
c. De-encapsulate the payload and forward it to a node other than c. Decapsulate the payload and forward it to a node other than its
its intended destination. intended destination.
Behaviors a) and b) are acceptable. Behavior c) is not acceptable. Behaviors a) and b) are acceptable. Behavior c) is not acceptable.
Behavior c) is possible only when the following conditions are true: Behavior c) is possible only when the following conditions are true:
1. The intended GRE egress node is a Virtual Private Network (VPN) 1. The intended GRE egress node is a Virtual Private Network (VPN)
Provider Edge (PE) router. Provider Edge (PE) router.
2. The node to which the GRE delivery packet is mistakenly delivered 2. The node to which the GRE delivery packet is mistakenly delivered
is also a VPN PE router. is also a VPN PE router.
3. VPNs are attached to both of the above-mentioned nodes. At least 3. VPNs are attached to both of the above-mentioned nodes. At least
two of these VPN's number hosts from non-unique (e.g., [RFC1918]) two of these VPN's number hosts are from a non-unique (e.g.,
address space. [RFC1918]) address space.
4. The intended GRE egress node maintains state that causes it to 4. The intended GRE egress node maintains state that causes it to
decapsulate the packet and forward the payload to its intended decapsulate the packet and forward the payload to its intended
destination destination
5. The node to which the GRE delivery packet is mistakenly delivered 5. The node to which the GRE delivery packet is mistakenly delivered
maintains state that causes it to decapsulate the packet and maintains state that causes it to decapsulate the packet and
forward the payload to an identically numbered host in another forward the payload to an identically numbered host in another
VPN. VPN.
skipping to change at page 7, line 48 skipping to change at page 8, line 17
By default, the GRE ingress node cannot fragment the IPv6 delivery By default, the GRE ingress node cannot fragment the IPv6 delivery
header. However, implementations MAY support an optional header. However, implementations MAY support an optional
configuration in which the GRE ingress node can fragment the IPv6 configuration in which the GRE ingress node can fragment the IPv6
delivery header. delivery header.
Also by default, the GRE egress node cannot reassemble the IPv6 Also by default, the GRE egress node cannot reassemble the IPv6
delivery header. However, implementations MAY support an optional delivery header. However, implementations MAY support an optional
configuration in which the GRE egress node can reassemble the IPv6 configuration in which the GRE egress node can reassemble the IPv6
delivery header. delivery header.
5. IANA Considerations 5. Security Considerations
This document makes no request of IANA.
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, the various threats can be any GRE payload. As stated in RFC 4023, these various threats can be
mitigated through options such as authenticating and/or encrypting mitigated through options such as authenticating and/or encrypting
the delivery packet using IPSec [RFC4301]. Alternatively when the the delivery packet using IPsec [RFC4301]. Alternatively, when the
payload is IPv6, these threats can also be mitigated by payload is IPv6, these threats can also be mitigated by
authenticating and/or encrypting the payload using IPsec, instead of authenticating and/or encrypting the payload using IPsec, instead of
the delivery packet. Otherwise, the current specification introduces the delivery packet. Otherwise, the current specification introduces
no security considerations beyond 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 [OPSEC-V6],
[I-D.ietf-opsec-v6], and security concerns for tunnels in general are and security concerns for tunnels in general are discussed in
discussed in [RFC6169]. [RFC6169].
7. 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.
8. References 6. References
8.1. Normative References 6.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC768] 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, [RFC791] 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, [RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>. <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, DOI 10.17487/RFC1981, August for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <http://www.rfc-editor.org/info/rfc1981>. 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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
skipping to change at page 9, line 38 skipping to change at page 9, line 38
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
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 6.2. Informative References
[I-D.ietf-opsec-v6] [OPSEC-V6] Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational
Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational Security Considerations for IPv6 Networks", Work in
Security Considerations for IPv6 Networks", draft-ietf- Progress, draft-ietf-opsec-v6-07, September 2015.
opsec-v6-06 (work in progress), March 2015.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>. <http://www.rfc-editor.org/info/rfc1918>.
[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, Co-existence Security Considerations", RFC 4942,
DOI 10.17487/RFC4942, September 2007, DOI 10.17487/RFC4942, September 2007,
<http://www.rfc-editor.org/info/rfc4942>. <http://www.rfc-editor.org/info/rfc4942>.
skipping to change at page 10, line 26 skipping to change at page 10, line 21
IETF Protocol and Documentation Usage for IEEE 802 IETF Protocol and Documentation Usage for IEEE 802
Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
October 2013, <http://www.rfc-editor.org/info/rfc7042>. October 2013, <http://www.rfc-editor.org/info/rfc7042>.
[RFC7588] Bonica, R., Pignataro, C., and J. Touch, "A Widely [RFC7588] 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", RFC 7588, (GRE) Fragmentation Problem", RFC 7588,
DOI 10.17487/RFC7588, July 2015, DOI 10.17487/RFC7588, July 2015,
<http://www.rfc-editor.org/info/rfc7588>. <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.
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 United States
Email: cpignata@cisco.com Email: cpignata@cisco.com
Ron Bonica Ron Bonica
Juniper Networks Juniper Networks
2251 Corporate Park Drive 2251 Corporate Park Drive
Herndon, Virginia Herndon, Virginia
USA United States
Email: rbonica@juniper.net Email: rbonica@juniper.net
Suresh Krishnan Suresh Krishnan
Ericsson Ericsson
8400 Decarie Blvd. 8400 Decarie Blvd.
Town of Mount Royal, QC Town of Mount Royal, QC
Canada Canada
Phone: +1 514 345 7900 x42871 Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com Email: suresh.krishnan@ericsson.com
 End of changes. 48 change blocks. 
99 lines changed or deleted 91 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/