draft-ietf-6man-rfc6434-bis-08.txt   draft-ietf-6man-rfc6434-bis-09.txt 
Internet Engineering Task Force T. Chown Internet Engineering Task Force T. Chown
Internet-Draft Jisc Internet-Draft Jisc
Obsoletes: 6434 (if approved) J. Loughney Obsoletes: 6434 (if approved) J. Loughney
Intended status: Best Current Practice Intel Intended status: Best Current Practice Intel
Expires: September 20, 2018 T. Winters Expires: January 17, 2019 T. Winters
UNH-IOL UNH-IOL
March 19, 2018 July 16, 2018
IPv6 Node Requirements IPv6 Node Requirements
draft-ietf-6man-rfc6434-bis-08 draft-ietf-6man-rfc6434-bis-09
Abstract Abstract
This document defines requirements for IPv6 nodes. It is expected This document defines requirements for IPv6 nodes. It is expected
that IPv6 will be deployed in a wide range of devices and situations. that IPv6 will be deployed in a wide range of devices and situations.
Specifying the requirements for IPv6 nodes allows IPv6 to function Specifying the requirements for IPv6 nodes allows IPv6 to function
well and interoperate in a large number of situations and well and interoperate in a large number of situations and
deployments. deployments.
This document obsoletes RFC 6434, and in turn RFC 4294. This document obsoletes RFC 6434, and in turn RFC 4294.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 20, 2018. This Internet-Draft will expire on January 17, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of This Document . . . . . . . . . . . . . . . . . 4 1.1. Scope of This Document . . . . . . . . . . . . . . . . . 4
1.2. Description of IPv6 Nodes . . . . . . . . . . . . . . . . 5 1.2. Description of IPv6 Nodes . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Abbreviations Used in This Document . . . . . . . . . . . . . 5 3. Abbreviations Used in This Document . . . . . . . . . . . . . 5
4. Sub-IP Layer . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Sub-IP Layer . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Internet Protocol Version 6 - RFC 8200 . . . . . . . . . 6 5.1. Internet Protocol Version 6 - RFC 8200 . . . . . . . . . 6
5.2. Support for IPv6 Extension Headers . . . . . . . . . . . 7 5.2. Support for IPv6 Extension Headers . . . . . . . . . . . 7
5.3. Protecting a node from excessive EH options . . . . . . . 8 5.3. Protecting a node from excessive EH options . . . . . . . 8
5.4. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . 9 5.4. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . 9
5.5. SEcure Neighbor Discovery (SEND) - RFC 3971 . . . . . . . 10 5.5. SEcure Neighbor Discovery (SEND) - RFC 3971 . . . . . . . 10
5.6. IPv6 Router Advertisement Flags Option - RFC 5175 . . . . 11 5.6. IPv6 Router Advertisement Flags Option - RFC 5175 . . . . 11
skipping to change at page 3, line 15 skipping to change at page 3, line 15
10.1. Transition Mechanisms . . . . . . . . . . . . . . . . . 18 10.1. Transition Mechanisms . . . . . . . . . . . . . . . . . 18
10.1.1. Basic Transition Mechanisms for IPv6 Hosts and 10.1.1. Basic Transition Mechanisms for IPv6 Hosts and
Routers - RFC 4213 . . . . . . . . . . . . . . . . . 18 Routers - RFC 4213 . . . . . . . . . . . . . . . . . 18
11. Application Support . . . . . . . . . . . . . . . . . . . . . 18 11. Application Support . . . . . . . . . . . . . . . . . . . . . 18
11.1. Textual Representation of IPv6 Addresses - RFC 5952 . . 18 11.1. Textual Representation of IPv6 Addresses - RFC 5952 . . 18
11.2. Application Programming Interfaces (APIs) . . . . . . . 18 11.2. Application Programming Interfaces (APIs) . . . . . . . 18
12. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 19
13. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 21 13.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 21
13.2. Transforms and Algorithms . . . . . . . . . . . . . . . 21 13.2. Transforms and Algorithms . . . . . . . . . . . . . . . 21
14. Router-Specific Functionality . . . . . . . . . . . . . . . . 22 14. Router-Specific Functionality . . . . . . . . . . . . . . . . 21
14.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . . 22 14.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . . 22
14.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . 22 14.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . 22
14.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 . 22 14.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 . 22
14.4. IPv6 Prefix Length Recommendation for Forwarding - BCP 14.4. IPv6 Prefix Length Recommendation for Forwarding - BCP
198 . . . . . . . . . . . . . . . . . . . . . . . . . . 23 198 . . . . . . . . . . . . . . . . . . . . . . . . . . 23
15. Constrained Devices . . . . . . . . . . . . . . . . . . . . . 23 15. Constrained Devices . . . . . . . . . . . . . . . . . . . . . 23
16. Network Management . . . . . . . . . . . . . . . . . . . . . 23 16. IPv6 Node Management . . . . . . . . . . . . . . . . . . . . 23
16.1. Management Information Base (MIB) Modules . . . . . . . 23 16.1. Management Information Base (MIB) Modules . . . . . . . 23
16.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . 24 16.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . 24
16.1.2. Management Information Base for the Internet 16.1.2. Management Information Base for the Internet
Protocol (IP) . . . . . . . . . . . . . . . . . . . 24 Protocol (IP) . . . . . . . . . . . . . . . . . . . 24
16.1.3. Interface MIB . . . . . . . . . . . . . . . . . . . 24 16.1.3. Interface MIB . . . . . . . . . . . . . . . . . . . 24
16.2. YANG Data Models . . . . . . . . . . . . . . . . . . . . 24 16.2. YANG Data Models . . . . . . . . . . . . . . . . . . . . 24
16.2.1. IP Management YANG Model . . . . . . . . . . . . . . 24 16.2.1. IP Management YANG Model . . . . . . . . . . . . . . 24
16.2.2. Interface Management YANG Model . . . . . . . . . . 24 16.2.2. Interface Management YANG Model . . . . . . . . . . 24
17. Security Considerations . . . . . . . . . . . . . . . . . . . 24 17. Security Considerations . . . . . . . . . . . . . . . . . . . 24
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
19. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 25 19. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 24
19.1. Authors and Acknowledgments (Current Document) . . . . . 25 19.1. Authors and Acknowledgments (Current Document) . . . . . 25
19.2. Authors and Acknowledgments from RFC 6434 . . . . . . . 25 19.2. Authors and Acknowledgments from RFC 6434 . . . . . . . 25
19.3. Authors and Acknowledgments from RFC 4294 . . . . . . . 25 19.3. Authors and Acknowledgments from RFC 4294 . . . . . . . 25
20. Appendix: Changes from RFC 6434 . . . . . . . . . . . . . . . 25 20. Appendix: Changes from RFC 6434 . . . . . . . . . . . . . . . 25
21. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 27 21. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 27
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
22.1. Normative References . . . . . . . . . . . . . . . . . . 28 22.1. Normative References . . . . . . . . . . . . . . . . . . 28
22.2. Informative References . . . . . . . . . . . . . . . . . 35 22.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
skipping to change at page 4, line 30 skipping to change at page 4, line 30
This document defines a minimal level of requirement needed for a This document defines a minimal level of requirement needed for a
device to provide useful internet service and considers a broad range device to provide useful internet service and considers a broad range
of device types and deployment scenarios. Because of the wide range of device types and deployment scenarios. Because of the wide range
of deployment scenarios, the minimal requirements specified in this of deployment scenarios, the minimal requirements specified in this
document may not be sufficient for all deployment scenarios. It is document may not be sufficient for all deployment scenarios. It is
perfectly reasonable (and indeed expected) for other profiles to perfectly reasonable (and indeed expected) for other profiles to
define additional or stricter requirements appropriate for specific define additional or stricter requirements appropriate for specific
usage and deployment environments. For example, this document does usage and deployment environments. For example, this document does
not mandate that all clients support DHCP, but some deployment not mandate that all clients support DHCP, but some deployment
scenarios may deem it appropriate to make such a requirement. For scenarios may deem it appropriate to make such a requirement. For
example, government agencies in the USA have defined profiles for example, NIST has defined profiles for specialized requirements for
specialized requirements for IPv6 in target environments (see IPv6 in target environments (see [USGv6]).
[USGv6]).
As it is not always possible for an implementer to know the exact As it is not always possible for an implementer to know the exact
usage of IPv6 in a node, an overriding requirement for IPv6 nodes is usage of IPv6 in a node, an overriding requirement for IPv6 nodes is
that they should adhere to Jon Postel's Robustness Principle: "Be that they should adhere to Jon Postel's Robustness Principle: "Be
conservative in what you do, be liberal in what you accept from conservative in what you do, be liberal in what you accept from
others" [RFC0793]. others" [RFC0793].
1.1. Scope of This Document 1.1. Scope of This Document
IPv6 covers many specifications. It is intended that IPv6 will be IPv6 covers many specifications. It is intended that IPv6 will be
deployed in many different situations and environments. Therefore, deployed in many different situations and environments. Therefore,
it is important to develop requirements for IPv6 nodes to ensure it is important to develop requirements for IPv6 nodes to ensure
interoperability. interoperability.
This document assumes that all IPv6 nodes meet the minimum
requirements specified here.
1.2. Description of IPv6 Nodes 1.2. Description of IPv6 Nodes
From the Internet Protocol, Version 6 (IPv6) Specification [RFC8200], From the Internet Protocol, Version 6 (IPv6) Specification [RFC8200],
we have the following definitions: we have the following definitions:
IPv6 node - a device that implements IPv6. IPv6 node - a device that implements IPv6.
IPv6 router - a node that forwards IPv6 packets not explicitly IPv6 router - a node that forwards IPv6 packets not explicitly
addressed to itself. addressed to itself.
IPv6 host - any node that is not a router. IPv6 host - any IPv6 node that is not a router.
2. Requirements Language 2. 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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119]
8174 [RFC8174] when, and only when, they appear in all capitals, as
show here.
3. Abbreviations Used in This Document 3. Abbreviations Used in This Document
AH Authentication Header AH Authentication Header
DAD Duplicate Address Detection DAD Duplicate Address Detection
ESP Encapsulating Security Payload ESP Encapsulating Security Payload
ICMP Internet Control Message Protocol ICMP Internet Control Message Protocol
IKE Internet Key Exchange IKE Internet Key Exchange
MIB Management Information Base MIB Management Information Base
MLD Multicast Listener Discovery MLD Multicast Listener Discovery
MTU Maximum Transmission Unit MTU Maximum Transmission Unit
NA Neighbor Advertisement NA Neighbor Advertisement
NBMA Non-Broadcast Multiple Access NBMA Non-Broadcast Multiple Access
ND Neighbor Discovery ND Neighbor Discovery
NS Neighbor Solicitation NS Neighbor Solicitation
NUD Neighbor Unreachability Detection NUD Neighbor Unreachability Detection
PPP Point-to-Point Protocol PPP Point-to-Point Protocol
4. Sub-IP Layer 4. Sub-IP Layer
An IPv6 node must include support for one or more IPv6 link-layer An IPv6 node MUST include support for one or more IPv6 link-layer
specifications. Which link-layer specifications an implementation specifications. Which link-layer specifications an implementation
should include will depend upon what link-layers are supported by the should include will depend upon what link-layers are supported by the
hardware available on the system. It is possible for a conformant hardware available on the system. It is possible for a conformant
IPv6 node to support IPv6 on some of its interfaces and not on IPv6 node to support IPv6 on some of its interfaces and not on
others. others.
As IPv6 is run over new layer 2 technologies, it is expected that new As IPv6 is run over new layer 2 technologies, it is expected that new
specifications will be issued. In the following, we list some of the specifications will be issued. In the following, we list some of the
layer 2 technologies for which an IPv6 specification has been layer 2 technologies for which an IPv6 specification has been
developed. It is provided for informational purposes only and may developed. It is provided for informational purposes only and may
skipping to change at page 6, line 45 skipping to change at page 6, line 42
The Internet Protocol Version 6 is specified in [RFC8200]. This The Internet Protocol Version 6 is specified in [RFC8200]. This
specification MUST be supported. specification MUST be supported.
The node MUST follow the packet transmission rules in RFC 8200. The node MUST follow the packet transmission rules in RFC 8200.
All conformant IPv6 implementations MUST be capable of sending and All conformant IPv6 implementations MUST be capable of sending and
receiving IPv6 packets; forwarding functionality MAY be supported. receiving IPv6 packets; forwarding functionality MAY be supported.
Nodes MUST always be able to send, receive, and process fragment Nodes MUST always be able to send, receive, and process fragment
headers. headers.
IPv6 nodes must not create overlapping fragments. Also, when IPv6 nodes MUST not create overlapping fragments. Also, when
reassembling an IPv6 datagram, if one or more of its constituent reassembling an IPv6 datagram, if one or more of its constituent
fragments is determined to be an overlapping fragment, the entire fragments is determined to be an overlapping fragment, the entire
datagram (and any constituent fragments) must be silently discarded. datagram (and any constituent fragments) MUST be silently discarded.
See [RFC5722] for more information. See [RFC5722] for more information.
As recommended in [RFC8021], nodes MUST NOT generate atomic As recommended in [RFC8021], nodes MUST NOT generate atomic
fragments, i.e., where the fragment is a whole datagram. As per fragments, i.e., where the fragment is a whole datagram. As per
[RFC6946], if a receiving node reassembling a datagram encounters an [RFC6946], if a receiving node reassembling a datagram encounters an
atomic fragment, it should be processed as a fully reassembled atomic fragment, it should be processed as a fully reassembled
packet, and any other fragments that match this packet should be packet, and any other fragments that match this packet should be
processed independently. processed independently.
To mitigate a variety of potential attacks, nodes SHOULD avoid using To mitigate a variety of potential attacks, nodes SHOULD avoid using
predictable fragment Identification values in Fragment Headers, as predictable fragment Identification values in Fragment Headers, as
discussed in [RFC7739]. discussed in [RFC7739].
All nodes SHOULD support the setting and use of the IPv6 Flow Label All nodes SHOULD support the setting and use of the IPv6 Flow Label
skipping to change at page 7, line 40 skipping to change at page 7, line 37
in the case of multicast) identified in the Destination Address field in the case of multicast) identified in the Destination Address field
of the IPv6 header. of the IPv6 header.
Any unrecognized extension headers or options MUST be processed as Any unrecognized extension headers or options MUST be processed as
described in RFC 8200. Note that where Section 4 of RFC 8200 refers described in RFC 8200. Note that where Section 4 of RFC 8200 refers
to the action to be taken when a Next Header value in the current to the action to be taken when a Next Header value in the current
header is not recognized by a node, that action applies whether the header is not recognized by a node, that action applies whether the
value is an unrecognized Extension Header or an unrecognized upper value is an unrecognized Extension Header or an unrecognized upper
layer protocol (ULP). layer protocol (ULP).
An IPv6 node MUST be able to process these headers. An exception is An IPv6 node MUST be able to process these extension headers. An
Routing Header type 0 (RH0), which was deprecated by [RFC5095] due to exception is Routing Header type 0 (RH0), which was deprecated by
security concerns and which MUST be treated as an unrecognized [RFC5095] due to security concerns and which MUST be treated as an
routing type. unrecognized routing type.
Further, [RFC7045] adds specific requirements for processing of Further, [RFC7045] adds specific requirements for processing of
Extension Headers, in particular that any forwarding node along an Extension Headers, in particular that any forwarding node along an
IPv6 packet's path, which forwards the packet for any reason, SHOULD IPv6 packet's path, which forwards the packet for any reason, SHOULD
do so regardless of any extension headers that are present. do so regardless of any extension headers that are present.
As per RFC 8200, when a node fragments an IPv6 datagram, it MUST As per RFC 8200, when a node fragments an IPv6 datagram, it MUST
include the entire IPv6 Header Chain in the first fragment. The Per- include the entire IPv6 Header Chain in the first fragment. The Per-
Fragment headers must consist of the IPv6 header plus any extension Fragment headers MUST consist of the IPv6 header plus any extension
headers that must be processed by nodes en route to the destination, headers that MUST be processed by nodes en route to the destination,
that is, all headers up to and including the Routing header if that is, all headers up to and including the Routing header if
present, else the Hop-by-Hop Options header if present, else no present, else the Hop-by-Hop Options header if present, else no
extension headers. On reassembly, if the first fragment does not extension headers. On reassembly, if the first fragment does not
include all headers through an Upper-Layer header, then that fragment include all headers through an Upper-Layer header, then that fragment
should be discarded and an ICMP Parameter Problem, Code 3, message SHOULD be discarded and an ICMP Parameter Problem, Code 3, message
should be sent to the source of the fragment, with the Pointer field SHOULD be sent to the source of the fragment, with the Pointer field
set to zero. See [RFC7112] for a discussion of why oversized IPv6 set to zero. See [RFC7112] for a discussion of why oversized IPv6
Extension Header chains are avoided. Extension Header chains are avoided.
Defining new IPv6 extension headers is not recommended, unless there Defining new IPv6 extension headers is not recommended, unless there
are no existing IPv6 extension headers that can be used by specifying are no existing IPv6 extension headers that can be used by specifying
a new option for that IPv6 extension header. A proposal to specify a a new option for that IPv6 extension header. A proposal to specify a
new IPv6 extension header must include a detailed technical new IPv6 extension header MUST include a detailed technical
explanation of why an existing IPv6 extension header can not be used explanation of why an existing IPv6 extension header can not be used
for the desired new function, and in such cases need to follow the for the desired new function, and in such cases need to follow the
format described in Section 8 of RFC 8200. For further background format described in Section 8 of RFC 8200. For further background
reading on this topic, see [RFC6564]. reading on this topic, see [RFC6564].
5.3. Protecting a node from excessive EH options 5.3. Protecting a node from excessive EH options
As per RFC 8200, end hosts are expected to process all extension As per RFC 8200, end hosts are expected to process all extension
headers, destination options, and hop-by-hop options in a packet. headers, destination options, and hop-by-hop options in a packet.
Given that the only limit on the number and size of extension headers Given that the only limit on the number and size of extension headers
is the MTU, the processing of received packets could be considerable. is the MTU, the processing of received packets could be considerable.
It is also conceivable that a long chain of extension headers might It is also conceivable that a long chain of extension headers might
be used as a form of denial-of-service attack. Accordingly, a host be used as a form of denial-of-service attack. Accordingly, a host
may place limits on the number and sizes of extension headers and may place limits on the number and sizes of extension headers and
options it is willing to process. options it is willing to process.
A host MAY limit the number of consecutive PAD1 options in A host MAY limit the number of consecutive PAD1 options in
destination options or hop-by-hop options to seven. In this case, if destination options or hop-by-hop options to seven. In this case, if
the more than seven consecutive PAD1 options are present the packet the more than seven consecutive PAD1 options are present the packet
should be silently discarded. The rationale is that if padding of MAY be silently discarded. The rationale is that if padding of eight
eight or more bytes is required than the PADN option should be used. or more bytes is required than the PADN option SHOULD be used.
A host MAY limit number of bytes in a PADN option to be less than A host MAY limit number of bytes in a PADN option to be less than
eight. In such a case, if a PADN option is present that has a length eight. In such a case, if a PADN option is present that has a length
greater than seven then the packet should be silently discarded. The greater than seven then the packet SHOULD be silently discarded. The
rationale for this guideline is that the purpose of padding is for rationale for this guideline is that the purpose of padding is for
alignment and eight bytes is the maximum alignment used in IPv6. alignment and eight bytes is the maximum alignment used in IPv6.
A host MAY disallow unknown options in destination options or hop-by- A host MAY disallow unknown options in destination options or hop-by-
hop options. This should be configurable where the default is to hop options. This SHOULD be configurable where the default is to
accept unknown options and process them per [RFC8200]. If a packet accept unknown options and process them per [RFC8200]. If a packet
with unknown options is received and the host is configured to with unknown options is received and the host is configured to
disallow them, then the packet should be silently discarded. disallow them, then the packet SHOULD be silently discarded.
A host MAY impose a limit on the maximum number of non-padding A host MAY impose a limit on the maximum number of non-padding
options allowed in a destination options and hop-by-hop extension options allowed in the destination options and hop-by-hop extension
headers. If this feature is supported the maximum number should be headers. If this feature is supported the maximum number SHOULD be
configurable and the default value SHOULD be set to eight. The configurable and the default value SHOULD be set to eight. The
limits for destination options and hop-by-hop options may be limits for destination options and hop-by-hop options may be
separately configurable. If a packet is received and the number of separately configurable. If a packet is received and the number of
destination or hop-by-hop optines exceeds the limit, then the packet destination or hop-by-hop options exceeds the limit, then the packet
should be silently discarded. SHOULD be silently discarded.
A host MAY impose a limit on the maximum length of destination A host MAY impose a limit on the maximum length of destination
options or hop-by-hop options extension header. This value should be options or hop-by-hop options extension header. This value SHOULD be
configurable and the default is to accept options of any length. If configurable and the default is to accept options of any length. If
a packet is received and the length of destination or hop-by-hop a packet is received and the length of destination or hop-by-hop
options extension header exceeds the length limit, then the packet options extension header exceeds the length limit, then the packet
should be silently discarded. SHOULD be silently discarded.
5.4. Neighbor Discovery for IPv6 - RFC 4861 5.4. Neighbor Discovery for IPv6 - RFC 4861
Neighbor Discovery is defined in [RFC4861]; the definition was Neighbor Discovery is defined in [RFC4861]; the definition was
updated by [RFC5942]. Neighbor Discovery SHOULD be supported. RFC updated by [RFC5942]. Neighbor Discovery SHOULD be supported. RFC
4861 states: 4861 states:
Unless specified otherwise (in a document that covers operating IP Unless specified otherwise (in a document that covers operating IP
over a particular link type) this document applies to all link over a particular link type) this document applies to all link
types. However, because ND uses link-layer multicast for some of types. However, because ND uses link-layer multicast for some of
skipping to change at page 10, line 17 skipping to change at page 10, line 15
[RFC7048] discusses NUD, in particular cases where it behaves too [RFC7048] discusses NUD, in particular cases where it behaves too
impatiently. It states that if a node transmits more than a certain impatiently. It states that if a node transmits more than a certain
number of packets, then it SHOULD use the exponential backoff of the number of packets, then it SHOULD use the exponential backoff of the
retransmit timer, up to a certain threshold point. retransmit timer, up to a certain threshold point.
Hosts MUST support the sending of Router Solicitations and the Hosts MUST support the sending of Router Solicitations and the
receiving of Router Advertisements. The ability to understand receiving of Router Advertisements. The ability to understand
individual Router Advertisement options is dependent on supporting individual Router Advertisement options is dependent on supporting
the functionality making use of the particular option. the functionality making use of the particular option.
[RFC7559] discusses packet loss resliency for Router Solicitations, [RFC7559] discusses packet loss resiliency for Router Solicitations,
and requires that nodes MUST use a specific exponential backoff and requires that nodes MUST use a specific exponential backoff
algorithm for RS retransmissions. algorithm for RS retransmissions.
All nodes MUST support the sending and receiving of Neighbor All nodes MUST support the sending and receiving of Neighbor
Solicitation (NS) and Neighbor Advertisement (NA) messages. NS and Solicitation (NS) and Neighbor Advertisement (NA) messages. NS and
NA messages are required for Duplicate Address Detection (DAD). NA messages are required for Duplicate Address Detection (DAD).
Hosts SHOULD support the processing of Redirect functionality. Hosts SHOULD support the processing of Redirect functionality.
Routers MUST support the sending of Redirects, though not necessarily Routers MUST support the sending of Redirects, though not necessarily
for every individual packet (e.g., due to rate limiting). Redirects for every individual packet (e.g., due to rate limiting). Redirects
are only useful on networks supporting hosts. In core networks are only useful on networks supporting hosts. In core networks
dominated by routers, Redirects are typically disabled. The sending dominated by routers, Redirects are typically disabled. The sending
of Redirects SHOULD be disabled by default on backbone routers. They of Redirects SHOULD be disabled by default on routers intended to
MAY be enabled by default on routers intended to support hosts on deployed on core networks. They MAY be enabled by default on routers
edge networks. intended to support hosts on edge networks.
"IPv6 Host-to-Router Load Sharing" [RFC4311] includes additional "IPv6 Host-to-Router Load Sharing" [RFC4311] includes additional
recommendations on how to select from a set of available routers. recommendations on how to select from a set of available routers.
[RFC4311] SHOULD be supported. [RFC4311] SHOULD be supported.
5.5. SEcure Neighbor Discovery (SEND) - RFC 3971 5.5. SEcure Neighbor Discovery (SEND) - RFC 3971
SEND [RFC3971] and Cryptographically Generated Addresses (CGAs) SEND [RFC3971] and Cryptographically Generated Addresses (CGAs)
[RFC3972] provide a way to secure the message exchanges of Neighbor [RFC3972] provide a way to secure the message exchanges of Neighbor
Discovery. SEND has the potential to address certain classes of Discovery. SEND has the potential to address certain classes of
skipping to change at page 11, line 42 skipping to change at page 11, line 40
sending packets no larger than 1280 octets, and omit sending packets no larger than 1280 octets, and omit
implementation of Path MTU Discovery. implementation of Path MTU Discovery.
The rules in [RFC8200] and [RFC5722] MUST be followed for packet The rules in [RFC8200] and [RFC5722] MUST be followed for packet
fragmentation and reassembly. fragmentation and reassembly.
As described in RFC 8201, nodes implementing Path MTU Discovery and As described in RFC 8201, nodes implementing Path MTU Discovery and
sending packets larger than the IPv6 minimum link MTU are susceptible sending packets larger than the IPv6 minimum link MTU are susceptible
to problematic connectivity if ICMPv6 messages are blocked or not to problematic connectivity if ICMPv6 messages are blocked or not
transmitted. For example, this will result in connections that transmitted. For example, this will result in connections that
complete the TCP three- way handshake correctly but then hang when complete the TCP three-way handshake correctly but then hang when
data is transferred. This state is referred to as a black-hole data is transferred. This state is referred to as a black-hole
connection [RFC2923]. Path MTU Discovery relies on ICMPv6 Packet Too connection [RFC2923]. Path MTU Discovery relies on ICMPv6 Packet Too
Big (PTB) to determine the MTU of the path (and thus these should not Big (PTB) to determine the MTU of the path (and thus these MUST not
be filtered, as per the recommendation in [RFC4890]). be filtered, as per the recommendation in [RFC4890]).
An extension to Path MTU Discovery defined in RFC 8201 can be found An alternative to Path MTU Discovery defined in RFC 8201 can be found
in [RFC4821], which defines a method for Packetization Layer Path MTU in [RFC4821], which defines a method for Packetization Layer Path MTU
Discovery (PLPMTUD) designed for use over paths where delivery of Discovery (PLPMTUD) designed for use over paths where delivery of
ICMPv6 messages to a host is not assured. ICMPv6 messages to a host is not assured.
5.7.2. Minimum MTU considerations 5.7.2. Minimum MTU considerations
While an IPv6 link MTU can be set to 1280 bytes, it is recommended While an IPv6 link MTU can be set to 1280 bytes, it is recommended
that for IPv6 UDP in particular, which includes DNS operation, the that for IPv6 UDP in particular, which includes DNS operation, the
sender use a large MTU if they can, in order to avoid gratuitous sender use a large MTU if they can, in order to avoid gratuitous
fragmentation-caused packet drops. fragmentation-caused packet drops.
skipping to change at page 13, line 11 skipping to change at page 13, line 11
operate in version 1 compatibility mode, the requirement to support operate in version 1 compatibility mode, the requirement to support
MLDv2 on all nodes was upgraded to a MUST. Further, SSM is now the MLDv2 on all nodes was upgraded to a MUST. Further, SSM is now the
preferred multicast distribution method, rather than ASM. preferred multicast distribution method, rather than ASM.
Note that Neighbor Discovery (as used on most link types -- see Note that Neighbor Discovery (as used on most link types -- see
Section 5.4) depends on multicast and requires that nodes join Section 5.4) depends on multicast and requires that nodes join
Solicited Node multicast addresses. Solicited Node multicast addresses.
5.12. Explicit Congestion Notification (ECN) - RFC 3168 5.12. Explicit Congestion Notification (ECN) - RFC 3168
An ECN-aware router may set a mark in the IP header in order to An ECN-aware router sets a mark in the IP header in order to signal
signal impending congestion, rather than dropping a packet. The impending congestion, rather than dropping a packet. The receiver of
receiver of the packet echoes the congestion indication to the the packet echoes the congestion indication to the sender, which can
sender, which can then reduce its transmission rate as if it detected then reduce its transmission rate as if it detected a dropped packet.
a dropped packet.
Nodes that may be deployed in environments where they would benefit Nodes SHOULD support [RFC3168] by implementing an interface for the
from such early congestion notification SHOULD implement [RFC3168]. upper layer to access and set the ECN bits in the IP header. The
In such cases, the updates presented in [RFC8311] may also be benefits of using ECN are documented in [RFC8087].
relevant.
6. Addressing and Address Configuration 6. Addressing and Address Configuration
6.1. IP Version 6 Addressing Architecture - RFC 4291 6.1. IP Version 6 Addressing Architecture - RFC 4291
The IPv6 Addressing Architecture [RFC4291] MUST be supported. The IPv6 Addressing Architecture [RFC4291] MUST be supported.
The current IPv6 Address Architecture is based on a 64-bit boundary The current IPv6 Address Architecture is based on a 64-bit boundary
for subnet prefixes. The reasoning behind this decision is for subnet prefixes. The reasoning behind this decision is
documented in [RFC7421]. documented in [RFC7421].
skipping to change at page 14, line 8 skipping to change at page 14, line 8
[RFC7934]. [RFC7934].
Nodes SHOULD support the capability to be assigned a prefix per host Nodes SHOULD support the capability to be assigned a prefix per host
as documented in [RFC8273]. Such an approach can offer improved host as documented in [RFC8273]. Such an approach can offer improved host
isolation and enhanced subscriber management on shared network isolation and enhanced subscriber management on shared network
segments. segments.
6.3. IPv6 Stateless Address Autoconfiguration - RFC 4862 6.3. IPv6 Stateless Address Autoconfiguration - RFC 4862
Hosts MUST support IPv6 Stateless Address Autoconfiguration. It is Hosts MUST support IPv6 Stateless Address Autoconfiguration. It is
recommended, as described in [RFC8064], that unless there is a RECOMMENDED, as described in [RFC8064], that unless there is a
specific requirement for MAC addresses to be embedded in an IID, specific requirement for MAC addresses to be embedded in an IID,
nodes follow the procedure in [RFC7217] to generate SLAAC-based nodes follow the procedure in [RFC7217] to generate SLAAC-based
addresses, rather than using [RFC4862]. Addresses generated through addresses, rather than using [RFC4862]. Addresses generated through
RFC7217 will be the same whenever a given device (re)appears on the RFC7217 will be the same whenever a given device (re)appears on the
same subnet (with a specific IPv6 prefix), but the IID will vary on same subnet (with a specific IPv6 prefix), but the IID will vary on
each subnet visited. each subnet visited.
Nodes that are routers MUST be able to generate link-local addresses Nodes that are routers MUST be able to generate link-local addresses
as described in [RFC4862]. as described in [RFC4862].
skipping to change at page 15, line 11 skipping to change at page 15, line 11
automate the detection of looped back IPv6 ND messages used by DAD. automate the detection of looped back IPv6 ND messages used by DAD.
Nodes SHOULD implement this behaviour where such detection is Nodes SHOULD implement this behaviour where such detection is
beneficial. beneficial.
6.4. Privacy Extensions for Address Configuration in IPv6 - RFC 4941 6.4. Privacy Extensions for Address Configuration in IPv6 - RFC 4941
A node using Stateless Address Autoconfiguration [RFC4862] to form a A node using Stateless Address Autoconfiguration [RFC4862] to form a
globally unique IPv6 address using its MAC address to generate the globally unique IPv6 address using its MAC address to generate the
IID will see that IID remain the same on any visited network, even IID will see that IID remain the same on any visited network, even
though the network prefix part changes. Thus it is possible for 3rd though the network prefix part changes. Thus it is possible for 3rd
party devices such nodes communicate with to track the activities of party device to track the activities of the node they communicate
the node as it moves around the network. Privacy Extensions for with, as that node moves around the network. Privacy Extensions for
Stateless Address Autoconfiguration [RFC4941] address this concern by Stateless Address Autoconfiguration [RFC4941] address this concern by
allowing nodes to configure an additional temporary address where the allowing nodes to configure an additional temporary address where the
IID is effectively randomly generated. Privacy addresses are then IID is effectively randomly generated. Privacy addresses are then
used as source addresses for new communications initiated by the used as source addresses for new communications initiated by the
node. node.
General issues regarding privacy issues for IPv6 addressing are General issues regarding privacy issues for IPv6 addressing are
discussed in [RFC7721]. discussed in [RFC7721].
RFC 4941 SHOULD be supported. In some scenarios, such as dedicated RFC 4941 SHOULD be supported. In some scenarios, such as dedicated
skipping to change at page 18, line 24 skipping to change at page 18, line 24
Service Discovery (DNS-SD) respectively. These protocols, Service Discovery (DNS-SD) respectively. These protocols,
collectively commonly referred to as the 'Bonjour' protocols after collectively commonly referred to as the 'Bonjour' protocols after
their naming by Apple, provide the means for devices to discover their naming by Apple, provide the means for devices to discover
services within a local link and, in the absence of a unicast DNS services within a local link and, in the absence of a unicast DNS
service, to exchange naming information. service, to exchange naming information.
Where devices are to be deployed in networks where service dicovery Where devices are to be deployed in networks where service dicovery
would be beneficial, e.g., for users seeking to discover printers or would be beneficial, e.g., for users seeking to discover printers or
display devices, mDNS and DNS-SD SHOULD be supported. display devices, mDNS and DNS-SD SHOULD be supported.
The IETF dnssd WG is defining solutions for DNS-based service
discovery in multi-link networks.
10. IPv4 Support and Transition 10. IPv4 Support and Transition
IPv6 nodes MAY support IPv4. IPv6 nodes MAY support IPv4.
10.1. Transition Mechanisms 10.1. Transition Mechanisms
10.1.1. Basic Transition Mechanisms for IPv6 Hosts and Routers - RFC 10.1.1. Basic Transition Mechanisms for IPv6 Hosts and Routers - RFC
4213 4213
If an IPv6 node implements dual stack and tunneling, then [RFC4213] If an IPv6 node implements dual stack and tunneling, then [RFC4213]
skipping to change at page 20, line 45 skipping to change at page 20, line 41
security and protects an entire IP packet by encapsulating the security and protects an entire IP packet by encapsulating the
orginal IP packet and then pre-pending a new IP header. In orginal IP packet and then pre-pending a new IP header. In
Transport-mode, IPsec provides security for the transport-layer (and Transport-mode, IPsec provides security for the transport-layer (and
above) by encapsulating only the transport-layer (and above) portion above) by encapsulating only the transport-layer (and above) portion
of the IP packet (i.e., without adding a 2nd IP header). of the IP packet (i.e., without adding a 2nd IP header).
Although IPsec can be used with manual keying in some cases, such Although IPsec can be used with manual keying in some cases, such
usage has limited applicability and is not recommended. usage has limited applicability and is not recommended.
A range of security technologies and approaches proliferate today A range of security technologies and approaches proliferate today
(e.g., IPsec, Transport Layer Security (TLS), Secure SHell (SSH), SSL (e.g., IPsec, Transport Layer Security (TLS), Secure SHell (SSH), TLS
VPNS, etc.) No one approach has emerged as an ideal technology for VPNS, etc.) No one approach has emerged as an ideal technology for
all needs and environments. Moreover, IPsec is not viewed as the all needs and environments. Moreover, IPsec is not viewed as the
ideal security technology in all cases and is unlikely to displace ideal security technology in all cases and is unlikely to displace
the others. the others.
Previously, IPv6 mandated implementation of IPsec and recommended the Previously, IPv6 mandated implementation of IPsec and recommended the
key management approach of IKE. This document updates that key management approach of IKE. This document updates that
recommendation by making support of the IPsec Architecture [RFC4301] recommendation by making support of the IPsec Architecture [RFC4301]
a SHOULD for all IPv6 nodes. Note that the IPsec Architecture a SHOULD for all IPv6 nodes. Note that the IPsec Architecture
requires (e.g., Section 4.5 of RFC 4301) the implementation of both requires (e.g., Section 4.5 of RFC 4301) the implementation of both
manual and automatic key management. Currently, the default manual and automatic key management. Currently, the recommended
automated key management protocol to implement is IKEv2 [RFC7296]. automated key management protocol to implement is IKEv2 [RFC7296].
This document recognizes that there exists a range of device types This document recognizes that there exists a range of device types
and environments where approaches to security other than IPsec can be and environments where approaches to security other than IPsec can be
justified. For example, special-purpose devices may support only a justified. For example, special-purpose devices may support only a
very limited number or type of applications, and an application- very limited number or type of applications, and an application-
specific security approach may be sufficient for limited management specific security approach may be sufficient for limited management
or configuration capabilities. Alternatively, some devices may run or configuration capabilities. Alternatively, some devices may run
on extremely constrained hardware (e.g., sensors) where the full on extremely constrained hardware (e.g., sensors) where the full
IPsec Architecture is not justified. IPsec Architecture is not justified.
skipping to change at page 23, line 33 skipping to change at page 23, line 30
compromises may need to be made in certain cases. Where such compromises may need to be made in certain cases. Where such
compromises are made, the interoperability of devices should be compromises are made, the interoperability of devices should be
strongly considered, paticularly where this may impact other nodes on strongly considered, paticularly where this may impact other nodes on
the same link, e.g., only supporting MLDv1 will affect other nodes. the same link, e.g., only supporting MLDv1 will affect other nodes.
The IETF 6LowPAN (IPv6 over Low Power LWPAN) WG defined six RFCs, The IETF 6LowPAN (IPv6 over Low Power LWPAN) WG defined six RFCs,
including a general overview and problem statement ([RFC4919], the including a general overview and problem statement ([RFC4919], the
means by which IPv6 packets are transmitted over IEEE 802.15.4 means by which IPv6 packets are transmitted over IEEE 802.15.4
networks [RFC4944] and ND optimisations for that medium [RFC6775]. networks [RFC4944] and ND optimisations for that medium [RFC6775].
If an IPv6 node is concerned about the impact of IPv6 message power IPv6 nodes that are battery-powered SHOULD implement the
consumption, it SHOULD want to implement the recommendations in recommendations in [RFC7772].
[RFC7772].
16. Network Management 16. IPv6 Node Management
Network management MAY be supported by IPv6 nodes. However, for IPv6 Network management MAY be supported by IPv6 nodes. However, for IPv6
nodes that are embedded devices, network management may be the only nodes that are embedded devices, network management may be the only
possible way of controlling these nodes. possible way of controlling these nodes.
Existing network management protocols include SNMP [RFC3411], NETCONF Existing network management protocols include SNMP [RFC3411], NETCONF
[RFC6241] and RESTCONF [RFC8040]. [RFC6241] and RESTCONF [RFC8040].
16.1. Management Information Base (MIB) Modules 16.1. Management Information Base (MIB) Modules
skipping to change at page 26, line 27 skipping to change at page 26, line 24
9. Added text on RFC7934, address availability to hosts (SHOULD). 9. Added text on RFC7934, address availability to hosts (SHOULD).
10. Added text on RFC7844, anonymity profiles for DHCPv6 clients. 10. Added text on RFC7844, anonymity profiles for DHCPv6 clients.
11. mDNS and DNS-SD added as updated service discovery. 11. mDNS and DNS-SD added as updated service discovery.
12. Added RFC8028 as a SHOULD as a method for solving multi-prefix 12. Added RFC8028 as a SHOULD as a method for solving multi-prefix
network network
13. Added ECN RFC3168 as a SHOULD, since recent reports have shown 13. Added ECN RFC3168 as a SHOULD
this as useful, and added a note on RFC8311, which is related.
14. Added reference to RFC7123 for Security over IPv4-only networks 14. Added reference to RFC7123 for Security over IPv4-only networks
15. Removed Jumbograms RFC2675 as they aren't deployed. 15. Removed Jumbograms RFC2675 as they aren't deployed.
16. Updated Obseleted RFCs to the new version of the RFC including 16. Updated Obseleted RFCs to the new version of the RFC including
2460, 1981, 7321, 4307 2460, 1981, 7321, 4307
17. Added RFC7772 for power comsumptions considerations 17. Added RFC7772 for power comsumptions considerations
skipping to change at page 34, line 15 skipping to change at page 34, line 5
[RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss [RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss
Resiliency for Router Solicitations", RFC 7559, Resiliency for Router Solicitations", RFC 7559,
DOI 10.17487/RFC7559, May 2015, DOI 10.17487/RFC7559, May 2015,
<https://www.rfc-editor.org/info/rfc7559>. <https://www.rfc-editor.org/info/rfc7559>.
[RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix
Length Recommendation for Forwarding", BCP 198, RFC 7608, Length Recommendation for Forwarding", BCP 198, RFC 7608,
DOI 10.17487/RFC7608, July 2015, DOI 10.17487/RFC7608, July 2015,
<https://www.rfc-editor.org/info/rfc7608>. <https://www.rfc-editor.org/info/rfc7608>.
[RFC7739] Gont, F., "Security Implications of Predictable Fragment
Identification Values", RFC 7739, DOI 10.17487/RFC7739,
February 2016, <https://www.rfc-editor.org/info/rfc7739>.
[RFC8021] Gont, F., Liu, W., and T. Anderson, "Generation of IPv6 [RFC8021] Gont, F., Liu, W., and T. Anderson, "Generation of IPv6
Atomic Fragments Considered Harmful", RFC 8021, Atomic Fragments Considered Harmful", RFC 8021,
DOI 10.17487/RFC8021, January 2017, DOI 10.17487/RFC8021, January 2017,
<https://www.rfc-editor.org/info/rfc8021>. <https://www.rfc-editor.org/info/rfc8021>.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
Hosts in a Multi-Prefix Network", RFC 8028, Hosts in a Multi-Prefix Network", RFC 8028,
DOI 10.17487/RFC8028, November 2016, DOI 10.17487/RFC8028, November 2016,
<https://www.rfc-editor.org/info/rfc8028>. <https://www.rfc-editor.org/info/rfc8028>.
skipping to change at page 34, line 43 skipping to change at page 34, line 29
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers", "Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017, RFC 8064, DOI 10.17487/RFC8064, February 2017,
<https://www.rfc-editor.org/info/rfc8064>. <https://www.rfc-editor.org/info/rfc8064>.
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017, RFC 8106, DOI 10.17487/RFC8106, March 2017,
<https://www.rfc-editor.org/info/rfc8106>. <https://www.rfc-editor.org/info/rfc8106>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
skipping to change at page 35, line 18 skipping to change at page 35, line 11
Payload (ESP) and Authentication Header (AH)", RFC 8221, Payload (ESP) and Authentication Header (AH)", RFC 8221,
DOI 10.17487/RFC8221, October 2017, DOI 10.17487/RFC8221, October 2017,
<https://www.rfc-editor.org/info/rfc8221>. <https://www.rfc-editor.org/info/rfc8221>.
[RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault,
"Algorithm Implementation Requirements and Usage Guidance "Algorithm Implementation Requirements and Usage Guidance
for the Internet Key Exchange Protocol Version 2 (IKEv2)", for the Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 8247, DOI 10.17487/RFC8247, September 2017, RFC 8247, DOI 10.17487/RFC8247, September 2017,
<https://www.rfc-editor.org/info/rfc8247>. <https://www.rfc-editor.org/info/rfc8247>.
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", RFC 8311,
DOI 10.17487/RFC8311, January 2018,
<https://www.rfc-editor.org/info/rfc8311>.
22.2. Informative References 22.2. Informative References
[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,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>. September 1997, <https://www.rfc-editor.org/info/rfc2205>.
skipping to change at page 39, line 27 skipping to change at page 39, line 16
Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit
Boundary in IPv6 Addressing", RFC 7421, Boundary in IPv6 Addressing", RFC 7421,
DOI 10.17487/RFC7421, January 2015, DOI 10.17487/RFC7421, January 2015,
<https://www.rfc-editor.org/info/rfc7421>. <https://www.rfc-editor.org/info/rfc7421>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>. <https://www.rfc-editor.org/info/rfc7721>.
[RFC7739] Gont, F., "Security Implications of Predictable Fragment
Identification Values", RFC 7739, DOI 10.17487/RFC7739,
February 2016, <https://www.rfc-editor.org/info/rfc7739>.
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy
Consumption of Router Advertisements", BCP 202, RFC 7772, Consumption of Router Advertisements", BCP 202, RFC 7772,
DOI 10.17487/RFC7772, February 2016, DOI 10.17487/RFC7772, February 2016,
<https://www.rfc-editor.org/info/rfc7772>. <https://www.rfc-editor.org/info/rfc7772>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844, Profiles for DHCP Clients", RFC 7844,
DOI 10.17487/RFC7844, May 2016, DOI 10.17487/RFC7844, May 2016,
<https://www.rfc-editor.org/info/rfc7844>. <https://www.rfc-editor.org/info/rfc7844>.
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
"Host Address Availability Recommendations", BCP 204, "Host Address Availability Recommendations", BCP 204,
RFC 7934, DOI 10.17487/RFC7934, July 2016, RFC 7934, DOI 10.17487/RFC7934, July 2016,
<https://www.rfc-editor.org/info/rfc7934>. <https://www.rfc-editor.org/info/rfc7934>.
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using
Explicit Congestion Notification (ECN)", RFC 8087,
DOI 10.17487/RFC8087, March 2017,
<https://www.rfc-editor.org/info/rfc8087>.
[RFC8096] Fenner, B., "The IPv6-Specific MIB Modules Are Obsolete", [RFC8096] Fenner, B., "The IPv6-Specific MIB Modules Are Obsolete",
RFC 8096, DOI 10.17487/RFC8096, April 2017, RFC 8096, DOI 10.17487/RFC8096, April 2017,
<https://www.rfc-editor.org/info/rfc8096>. <https://www.rfc-editor.org/info/rfc8096>.
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
<https://www.rfc-editor.org/info/rfc8273>. <https://www.rfc-editor.org/info/rfc8273>.
[POSIX] IEEE, "IEEE Std. 1003.1-2008 Standard for Information [POSIX] IEEE, "IEEE Std. 1003.1-2008 Standard for Information
Technology -- Portable Operating System Interface (POSIX), Technology -- Portable Operating System Interface (POSIX),
ISO/IEC 9945:2009", <http://www.ieee.org>. ISO/IEC 9945:2009", <http://www.ieee.org>.
[USGv6] National Institute of Standards and Technology, "A Profile [USGv6] National Institute of Standards and Technology, "A Profile
for IPv6 in the U.S. Government - Version 1.0", July 2008, for IPv6 in the U.S. Government - Version 1.0", July 2008,
<http://www.antd.nist.gov/usgv6/usgv6-v1.pdf>. <https://doi.org/10.6028/NIST.SP.500-267Ar1>.
Authors' Addresses Authors' Addresses
Tim Chown Tim Chown
Jisc Jisc
Lumen House, Library Avenue Lumen House, Library Avenue
Harwell Oxford, Didcot OX11 0SG Harwell Oxford, Didcot OX11 0SG
United Kingdom United Kingdom
Email: tim.chown@jisc.ac.uk Email: tim.chown@jisc.ac.uk
 End of changes. 49 change blocks. 
80 lines changed or deleted 74 lines changed or added

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