draft-ietf-6man-rfc6434-bis-03.txt   draft-ietf-6man-rfc6434-bis-04.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: August 10, 2018 T. Winters Expires: August 26, 2018 T. Winters
UNH-IOL UNH-IOL
February 6, 2018 February 22, 2018
IPv6 Node Requirements IPv6 Node Requirements
draft-ietf-6man-rfc6434-bis-03 draft-ietf-6man-rfc6434-bis-04
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 August 10, 2018. This Internet-Draft will expire on August 26, 2018.
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
skipping to change at page 3, line 4 skipping to change at page 3, line 4
6.6. Default Address Selection for IPv6 - RFC 6724 . . . . . . 15 6.6. Default Address Selection for IPv6 - RFC 6724 . . . . . . 15
7. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Configuring Non-Address Information . . . . . . . . . . . . . 16 8. Configuring Non-Address Information . . . . . . . . . . . . . 16
8.1. DHCP for Other Configuration Information . . . . . . . . 16 8.1. DHCP for Other Configuration Information . . . . . . . . 16
8.2. Router Advertisements and Default Gateway . . . . . . . . 16 8.2. Router Advertisements and Default Gateway . . . . . . . . 16
8.3. IPv6 Router Advertisement Options for DNS 8.3. IPv6 Router Advertisement Options for DNS
Configuration - RFC 8106 . . . . . . . . . . . . . . . . 16 Configuration - RFC 8106 . . . . . . . . . . . . . . . . 16
8.4. DHCP Options versus Router Advertisement Options for Host 8.4. DHCP Options versus Router Advertisement Options for Host
Configuration . . . . . . . . . . . . . . . . . . . . . . 17 Configuration . . . . . . . . . . . . . . . . . . . . . . 17
9. Service Discovery Protocols . . . . . . . . . . . . . . . . . 17 9. Service Discovery Protocols . . . . . . . . . . . . . . . . . 17
10. IPv4 Support and Transition . . . . . . . . . . . . . . . . . 17 10. IPv4 Support and Transition . . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 20 13.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 21
13.2. Transforms and Algorithms . . . . . . . . . . . . . . . 21 13.2. Transforms and Algorithms . . . . . . . . . . . . . . . 21
14. Router-Specific Functionality . . . . . . . . . . . . . . . . 21 14. Router-Specific Functionality . . . . . . . . . . . . . . . . 21
14.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . . 21 14.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . . 21
14.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 198 . . . . . . . . . . . . . . . . . . . . . . . . . . 22
15. Constrained Devices . . . . . . . . . . . . . . . . . . . . . 22 15. Constrained Devices . . . . . . . . . . . . . . . . . . . . . 22
16. Network Management . . . . . . . . . . . . . . . . . . . . . 23 16. Network 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 . . . . . . . . . . . . . . 23 16.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . 23
16.1.2. Management Information Base for the Internet 16.1.2. Management Information Base for the Internet
Protocol (IP) . . . . . . . . . . . . . . . . . . . 23 Protocol (IP) . . . . . . . . . . . . . . . . . . . 23
16.2. YANG Data Models . . . . . . . . . . . . . . . . . . . . 23 16.1.3. Interface MIB . . . . . . . . . . . . . . . . . . . 24
16.2.1. IP Management YANG Model . . . . . . . . . . . . . . 23 16.2. YANG Data Models . . . . . . . . . . . . . . . . . . . . 24
16.2.2. System Management YANG Model . . . . . . . . . . . . 24 16.2.1. IP Management YANG Model . . . . . . . . . . . . . . 24
16.2.3. System 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 . . . . . . . . . . . . . . . . . 24 19. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 24
19.1. Authors and Acknowledgments (Current Document) . . . . . 24 19.1. Authors and Acknowledgments (Current Document) . . . . . 24
19.2. Authors and Acknowledgments from RFC 6434 . . . . . . . 24 19.2. Authors and Acknowledgments from RFC 6434 . . . . . . . 24
19.3. Authors and Acknowledgments from RFC 4294 . . . . . . . 24 19.3. Authors and Acknowledgments from RFC 4294 . . . . . . . 25
20. Appendix: Changes from RFC 6434 . . . . . . . . . . . . . . . 26 20. Appendix: Changes from RFC 6434 . . . . . . . . . . . . . . . 26
21. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 27 21. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 27
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
22.1. Normative References . . . . . . . . . . . . . . . . . . 29 22.1. Normative References . . . . . . . . . . . . . . . . . . 29
22.2. Informative References . . . . . . . . . . . . . . . . . 35 22.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
This document defines common functionality required by both IPv6 This document defines common functionality required by both IPv6
skipping to change at page 8, line 18 skipping to change at page 8, line 18
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 the the more than seven consecutive PAD1 options are present the packet
packet should be silently discarded. The rationale is that if should be silently discarded. The rationale is that if padding of
padding of eight or more bytes is required than the PADN option eight or more bytes is required than the PADN option should be used.
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
skipping to change at page 11, line 39 skipping to change at page 11, line 39
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.
5.8. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443 5.8. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443
ICMPv6 [RFC4443] MUST be supported. "Extended ICMP to Support Multi- ICMPv6 [RFC4443] MUST be supported. "Extended ICMP to Support Multi-
Part Messages" [RFC4884] MAY be supported. Part Messages" [RFC4884] MAY be supported.
5.9. Default Router Preferences and More-Specific Routes - RFC 4191 5.9. Default Router Preferences and More-Specific Routes - RFC 4191
"Default Router Preferences and More-Specific Routes" [RFC4191] "Default Router Preferences and More-Specific Routes" [RFC4191]
provides support for nodes attached to multiple (different) networks, provides support for nodes attached to multiple (different) networks,
each providing routers that advertise themselves as default routers each providing routers that advertise themselves as default routers
via Router Advertisements. In some scenarios, one router may provide via Router Advertisements. In some scenarios, one router may provide
connectivity to destinations the other router does not, and choosing connectivity to destinations the other router does not, and choosing
the "wrong" default router can result in reachability failures. In the "wrong" default router can result in reachability failures. In
order to resolve this scenario IPv6 Nodes MUST implement [RFC4191] order to resolve this scenario IPv6 Nodes MUST implement [RFC4191]
skipping to change at page 12, line 49 skipping to change at page 12, line 49
Nodes that may be deployed in environments where they would benefit Nodes that may be deployed in environments where they would benefit
from such early congestion notification SHOULD implement [RFC3168]. from such early congestion notification SHOULD implement [RFC3168].
In such cases, the updates presented in [RFC8311] may also be In such cases, the updates presented in [RFC8311] may also be
relevant. 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].
Implementations MUST also support the Multicast flag updates
documented in [RFC7371]
6.2. Host Address Availability Recommendations 6.2. Host Address Availability Recommendations
Hosts may be configured with addresses through a variety of methods, Hosts may be configured with addresses through a variety of methods,
including SLAAC, DHCPv6, or manual configuration. including SLAAC, DHCPv6, or manual configuration.
[RFC7934] recommends that networks provide general-purpose end hosts [RFC7934] recommends that networks provide general-purpose end hosts
with multiple global IPv6 addresses when they attach, and it with multiple global IPv6 addresses when they attach, and it
describes the benefits of and the options for doing so. Router describes the benefits of and the options for doing so. Routers
SHOULD support [RFC7934] for assigning multiple address to a host. SHOULD support [RFC7934] for assigning multiple address to a host.
Host SHOULD support assigning multiple addresses as described in Host SHOULD support assigning multiple addresses as described in
[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
skipping to change at page 15, line 26 skipping to change at page 15, line 29
some of which may require DHCPv6 for stateful address assignment. some of which may require DHCPv6 for stateful address assignment.
Consequently, all hosts SHOULD implement address configuration via Consequently, all hosts SHOULD implement address configuration via
DHCPv6. DHCPv6.
In the absence of observed Router Advertisement messages, IPv6 nodes In the absence of observed Router Advertisement messages, IPv6 nodes
MAY initiate DHCP to obtain IPv6 addresses and other configuration MAY initiate DHCP to obtain IPv6 addresses and other configuration
information, as described in Section 5.5.2 of [RFC4862]. information, as described in Section 5.5.2 of [RFC4862].
Where devices are likely to be carried by users and attached to Where devices are likely to be carried by users and attached to
multiple visisted networks, DHCPv6 client anonymity profiles SHOULD multiple visisted networks, DHCPv6 client anonymity profiles SHOULD
be supported as described in [RFC7844] to minimise the disclosure of be supported as described in [RFC7844] to minimise the disclosure of
identifying information. Section 5 of RFC7844 describes operational identifying information. Section 5 of RFC7844 describes operational
considerations on the use of such anonymity profiles. considerations on the use of such anonymity profiles.
6.6. Default Address Selection for IPv6 - RFC 6724 6.6. Default Address Selection for IPv6 - RFC 6724
IPv6 nodes will invariably have multiple addresses configured IPv6 nodes will invariably have multiple addresses configured
simultaneously, and thus will need to choose which addresses to use simultaneously, and thus will need to choose which addresses to use
for which communications. The rules specified in the Default Address for which communications. The rules specified in the Default Address
Selection for IPv6 [RFC6724] document MUST be implemented. [RFC8028] Selection for IPv6 [RFC6724] document MUST be implemented. [RFC8028]
updates rule 5.5 from [RFC6724]; implementations SHOULD implement updates rule 5.5 from [RFC6724]; implementations SHOULD implement
skipping to change at page 16, line 30 skipping to change at page 16, line 32
(non-address) configuration. If a host implementation supports (non-address) configuration. If a host implementation supports
applications or other protocols that require configuration that is applications or other protocols that require configuration that is
only available via DHCP, hosts SHOULD implement DHCP. For only available via DHCP, hosts SHOULD implement DHCP. For
specialized devices on which no such configuration need is present, specialized devices on which no such configuration need is present,
DHCP may not be necessary. DHCP may not be necessary.
An IPv6 node can use the subset of DHCP (described in [RFC3736]) to An IPv6 node can use the subset of DHCP (described in [RFC3736]) to
obtain other configuration information. obtain other configuration information.
If an IPv6 node implements DHCP it MUST implement the DNS options If an IPv6 node implements DHCP it MUST implement the DNS options
[RFC3646] as most deployments will expect this options are available. [RFC3646] as most deployments will expect this options are
available.
8.2. Router Advertisements and Default Gateway 8.2. Router Advertisements and Default Gateway
There is no defined DHCPv6 Gateway option. There is no defined DHCPv6 Gateway option.
Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
are thus expected to determine their default router information and are thus expected to determine their default router information and
on-link prefix information from received Router Advertisements. on-link prefix information from received Router Advertisements.
8.3. IPv6 Router Advertisement Options for DNS Configuration - RFC 8106 8.3. IPv6 Router Advertisement Options for DNS Configuration - RFC 8106
skipping to change at page 17, line 34 skipping to change at page 17, line 38
influence over what devices connect to the network and thus what influence over what devices connect to the network and thus what
configuration mechanisms they support, the operator may be able to configuration mechanisms they support, the operator may be able to
ensure that a particular mechanism is supported by all connected ensure that a particular mechanism is supported by all connected
hosts. In more open environments, however, where arbitrary devices hosts. In more open environments, however, where arbitrary devices
may connect (e.g., a WIFI hotspot), problems can arise. To maximize may connect (e.g., a WIFI hotspot), problems can arise. To maximize
interoperability in such environments, hosts would need to implement interoperability in such environments, hosts would need to implement
multiple configuration mechanisms to ensure interoperability. multiple configuration mechanisms to ensure interoperability.
9. Service Discovery Protocols 9. Service Discovery Protocols
[RFC6762] and [RFC6763] describe multicast DNS (mDNS) and DNS-Based [RFC6762] and [RFC6763] describe multicast DNS (mDNS) and DNS-Based
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.
skipping to change at page 19, line 8 skipping to change at page 19, line 12
provides support for expressing source filters on multicast group provides support for expressing source filters on multicast group
memberships. memberships.
"Extension to Sockets API for Mobile IPv6" [RFC4584] provides "Extension to Sockets API for Mobile IPv6" [RFC4584] provides
application support for accessing and enabling Mobile IPv6 [RFC6275] application support for accessing and enabling Mobile IPv6 [RFC6275]
features. features.
12. Mobility 12. Mobility
Mobile IPv6 [RFC6275] and associated specifications [RFC3776] Mobile IPv6 [RFC6275] and associated specifications [RFC3776]
[RFC4877] allow a node to change its point of attachment within the [RFC4877] allow a node to change its point of attachment within the
Internet, while maintaining (and using) a permanent address. All Internet, while maintaining (and using) a permanent address. All
communication using the permanent address continues to proceed as communication using the permanent address continues to proceed as
expected even as the node moves around. The definition of Mobile IP expected even as the node moves around. The definition of Mobile IP
includes requirements for the following types of nodes: includes requirements for the following types of nodes:
- mobile nodes - mobile nodes
- correspondent nodes with support for route optimization - correspondent nodes with support for route optimization
- home agents - home agents
skipping to change at page 20, line 46 skipping to change at page 20, line 48
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.
Because most common platforms now support IPv6 and have it enabled by Because most common platforms now support IPv6 and have it enabled by
default, IPv6 security is an issue for networks that are ostensibly default, IPv6 security is an issue for networks that are ostensibly
IPv4-only; see [RFC7123] for guidance on this area. IPv4-only; see [RFC7123] for guidance on this area.
13.1. Requirements 13.1. Requirements
"Security Architecture for the Internet Protocol" [RFC4301] SHOULD be "Security Architecture for the Internet Protocol" [RFC4301] SHOULD be
supported by all IPv6 nodes. Note that the IPsec Architecture supported by all IPv6 nodes. Note that the IPsec Architecture
requires (e.g., Section 4.5 of [RFC4301]) the implementation of both requires (e.g., Section 4.5 of [RFC4301]) the implementation of both
manual and automatic key management. Currently, the default manual and automatic key management. Currently, the default
automated key management protocol to implement is IKEv2. As required automated key management protocol to implement is IKEv2. As required
in [RFC4301], IPv6 nodes implementing the IPsec Architecture MUST in [RFC4301], IPv6 nodes implementing the IPsec Architecture MUST
implement ESP [RFC4303] and MAY implement AH [RFC4302]. implement ESP [RFC4303] and MAY implement AH [RFC4302].
skipping to change at page 22, line 35 skipping to change at page 22, line 44
Because of the wide range of deployment scenarios, support for DHCP Because of the wide range of deployment scenarios, support for DHCP
server functionality on routers is optional. However, routers server functionality on routers is optional. However, routers
targeted for deployment within more complex scenarios (as described targeted for deployment within more complex scenarios (as described
above) SHOULD support relay agent functionality. Note that "Basic above) SHOULD support relay agent functionality. Note that "Basic
Requirements for IPv6 Customer Edge Routers" [RFC7084] requires Requirements for IPv6 Customer Edge Routers" [RFC7084] requires
implementation of a DHCPv6 server function in IPv6 Customer Edge (CE) implementation of a DHCPv6 server function in IPv6 Customer Edge (CE)
routers. routers.
14.4. IPv6 Prefix Length Recommendation for Forwarding - BCP 198 14.4. IPv6 Prefix Length Recommendation for Forwarding - BCP 198
Forwarding nodes MUST conform to BCP 198 [RFC7608] and thus IPv6 Forwarding nodes MUST conform to BCP 198 [RFC7608] and thus IPv6
implementations of nodes that may forward packets MUST conform to the implementations of nodes that may forward packets MUST conform to the
rules specified in Section 5.1 of [RFC4632]. rules specified in Section 5.1 of [RFC4632].
15. Constrained Devices 15. Constrained Devices
The target for this document is general IPv6 nodes. In the case of The target for this document is general IPv6 nodes. In the case of
constrained nodes, with limited CPU, memory, bandwidth or power, constrained nodes, with limited CPU, memory, bandwidth or power,
support for certain IPv6 functionality may need to be considered due support for certain IPv6 functionality may need to be considered due
to those limitations. The requirements of this document are to those limitations. The requirements of this document are
RECOMMENDED for all nodes, including constrained nodes, but RECOMMENDED for all nodes, including constrained nodes, but
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 If an IPv6 node is concerned about the impact of IPv6 message power
consumption, it SHOULD want to implement the recommendations in consumption, it SHOULD want to implement the recommendations in
[RFC7772]. [RFC7772].
16. Network Management 16. Network 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.
A node supporting network management SHOULD support NETCONF [RFC6241] Existing network management protocols include SNMP [RFC3411], NETCONF
and SNMP configuration [RFC3411]. [RFC6241] and RESTCONF [RFC8040].
16.1. Management Information Base (MIB) Modules 16.1. Management Information Base (MIB) Modules
IPv6 MIBs have been updated since the last release of the document; IPv6 MIBs have been updated since the last release of the document;
[RFC8096] obseletes several MIBs, which nodes need no longer support. [RFC8096] obseletes several MIBs, which nodes need no longer
support.
The following two MIB modules SHOULD be supported by nodes that The following two MIB modules SHOULD be supported by nodes that
support a Simple Network Management Protocol (SNMP) agent. support a Simple Network Management Protocol (SNMP) agent.
16.1.1. IP Forwarding Table MIB 16.1.1. IP Forwarding Table MIB
The IP Forwarding Table MIB [RFC4292] SHOULD be supported by nodes The IP Forwarding Table MIB [RFC4292] SHOULD be supported by nodes
that support an SNMP agent. that support an SNMP agent.
16.1.2. Management Information Base for the Internet Protocol (IP) 16.1.2. Management Information Base for the Internet Protocol (IP)
The IP MIB [RFC4293] SHOULD be supported by nodes that support an The IP MIB [RFC4293] SHOULD be supported by nodes that support an
SNMP agent. SNMP agent.
16.1.3. Interface MIB
The Interface MIB [RFC2863] SHOULD be supported by nodes the support
an SNMP agent.
16.2. YANG Data Models 16.2. YANG Data Models
The following YANG data models SHOULD be supported by nodes that The following YANG data models SHOULD be supported by nodes that
support a NETCONF agent. support a NETCONF agent.
16.2.1. IP Management YANG Model 16.2.1. IP Management YANG Model
The IP Management YANG Model [RFC7277] SHOULD be supported by nodes The IP Management YANG Model [RFC7277] SHOULD be supported by nodes
that support NETCONF. that support NETCONF.
16.2.2. System Management YANG Model 16.2.2. Interface Management YANG Model
The System Management YANG Model [RFC7317] SHOULD be supported by
nodes that support NETCONF.
16.2.3. System Management YANG Model
The Interface Management YANG Model [RFC7223] SHOULD be supported by The Interface Management YANG Model [RFC7223] SHOULD be supported by
nodes that support NETCONF. nodes that support NETCONF.
17. Security Considerations 17. Security Considerations
This document does not directly affect the security of the Internet, This document does not directly affect the security of the Internet,
beyond the security considerations associated with the individual beyond the security considerations associated with the individual
protocols. protocols.
skipping to change at page 26, line 26 skipping to change at page 26, line 29
3. Removed DOD IPv6 Profile as it hasn't been updated. 3. Removed DOD IPv6 Profile as it hasn't been updated.
4. Updated to MLDv2 support to a MUST since nodes are restricted if 4. Updated to MLDv2 support to a MUST since nodes are restricted if
MLDv1 is used. MLDv1 is used.
5. Require DNS RA Options so SLAAC-only devices can get DNS, 5. Require DNS RA Options so SLAAC-only devices can get DNS,
RFC8106 is a MUST. RFC8106 is a MUST.
6. Require RFC3646 DNS Options for DHCPv6 implementations. 6. Require RFC3646 DNS Options for DHCPv6 implementations.
7. Added section on constrained devices. 7. Added RESTCONF and NETCONF as possible options to Network
management.
8. Added text on RFC7934, address availability to hosts (SHOULD). 8. Added section on constrained devices.
9. Added text on RFC7844, anonymity profiles for DHCPv6 clients. 9. Added text on RFC7934, address availability to hosts (SHOULD).
10. mDNS and DNS-SD added as updated service discovery. 10. Added text on RFC7844, anonymity profiles for DHCPv6 clients.
11. Added RFC8028 as a SHOULD as a method for solving multi-prefix 11. mDNS and DNS-SD added as updated service discovery.
12. Added RFC8028 as a SHOULD as a method for solving multi-prefix
network network
12. Added ECN RFC3168 as a SHOULD, since recent reports have shown 13. Added ECN RFC3168 as a SHOULD, since recent reports have shown
this as useful, and added a note on RFC8311, which is related. this as useful, and added a note on RFC8311, which is related.
13. Added reference to RFC7123 for Security over IPv4-only networks 14. Added reference to RFC7123 for Security over IPv4-only networks
14. Removed Jumbograms RFC2675 as they aren't deployed. 15. Removed Jumbograms RFC2675 as they aren't deployed.
15. 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
16. Added RFC7772 for power comsumptions considerations 17. Added RFC7772 for power comsumptions considerations
17. Added why /64 boundries for more detail - RFC 7421 18. Added why /64 boundries for more detail - RFC 7421
18. Added a Unique IPv6 Prefix per Host to support currently 19. Added a Unique IPv6 Prefix per Host to support currently
deployed IPv6 networks deployed IPv6 networks
19. Clarified RFC7066 was snapshot for 3GPP 20. Clarified RFC7066 was snapshot for 3GPP
20. Updated 4191 as a MUST, SHOULD for Type C Host as it helps solve 21. Updated 4191 as a MUST, SHOULD for Type C Host as it helps solve
multi-prefix problem multi-prefix problem
21. Removed IPv6 over ATM since there aren't many deployments 22. Removed IPv6 over ATM since there aren't many deployments
22. Added a note in Section 6.6 for RFC6724 Section 5.5/ 23. Added a note in Section 6.6 for RFC6724 Section 5.5/
23. Added MUST for BCP 198 for forwarding IPv6 packets 24. Added MUST for BCP 198 for forwarding IPv6 packets
24. Added reference to draft-ietf-v6ops-ipv6rtr-reqs as it has more 25. Added reference to draft-ietf-v6ops-ipv6rtr-reqs as it has more
recommendations for a Router recommendations for a Router
25. Added reference to RFC8064 for stable address creation. 26. Added reference to RFC8064 for stable address creation.
26. Added text on protection from excessive EH options 27. Added text on protection from excessive EH options
27. Added text on dangers of 1280 MTU UDP, esp. wrt DNS traffic 28. Added text on dangers of 1280 MTU UDP, esp. wrt DNS traffic
28. Added text to clarify RFC8200 behaviour for unrecognized EHs or 29. Added text to clarify RFC8200 behaviour for unrecognized EHs or
unrecognized ULPs unrecognized ULPs
21. Appendix: Changes from RFC 4294 21. Appendix: Changes from RFC 4294
There have been many editorial clarifications as well as significant There have been many editorial clarifications as well as significant
additions and updates. While this section highlights some of the additions and updates. While this section highlights some of the
changes, readers should not rely on this section for a comprehensive changes, readers should not rely on this section for a comprehensive
list of all changes. list of all changes.
1. Updated the Introduction to indicate that this document is an 1. Updated the Introduction to indicate that this document is an
skipping to change at page 29, line 31 skipping to change at page 29, line 36
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, Listener Discovery (MLD) for IPv6", RFC 2710,
DOI 10.17487/RFC2710, October 1999, DOI 10.17487/RFC2710, October 1999,
<https://www.rfc-editor.org/info/rfc2710>. <https://www.rfc-editor.org/info/rfc2710>.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, DOI 10.17487/RFC2711, October 1999, RFC 2711, DOI 10.17487/RFC2711, October 1999,
<https://www.rfc-editor.org/info/rfc2711>. <https://www.rfc-editor.org/info/rfc2711>.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
<https://www.rfc-editor.org/info/rfc2863>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>. 2003, <https://www.rfc-editor.org/info/rfc3315>.
skipping to change at page 34, line 5 skipping to change at page 34, line 14
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 7277, DOI 10.17487/RFC7277, June 2014, RFC 7277, DOI 10.17487/RFC7277, June 2014,
<https://www.rfc-editor.org/info/rfc7277>. <https://www.rfc-editor.org/info/rfc7277>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
System Management", RFC 7317, DOI 10.17487/RFC7317, August
2014, <https://www.rfc-editor.org/info/rfc7317>.
[RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E., [RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E.,
and W. George, "Enhanced Duplicate Address Detection", and W. George, "Enhanced Duplicate Address Detection",
RFC 7527, DOI 10.17487/RFC7527, April 2015, RFC 7527, DOI 10.17487/RFC7527, April 2015,
<https://www.rfc-editor.org/info/rfc7527>. <https://www.rfc-editor.org/info/rfc7527>.
[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>.
skipping to change at page 34, line 38 skipping to change at page 34, line 43
[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>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[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>.
skipping to change at page 39, line 11 skipping to change at page 39, line 20
[RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on [RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on
IPv4 Networks", RFC 7123, DOI 10.17487/RFC7123, February IPv4 Networks", RFC 7123, DOI 10.17487/RFC7123, February
2014, <https://www.rfc-editor.org/info/rfc7123>. 2014, <https://www.rfc-editor.org/info/rfc7123>.
[RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6
/64 Prefix from a Third Generation Partnership Project /64 Prefix from a Third Generation Partnership Project
(3GPP) Mobile Interface to a LAN Link", RFC 7278, (3GPP) Mobile Interface to a LAN Link", RFC 7278,
DOI 10.17487/RFC7278, June 2014, DOI 10.17487/RFC7278, June 2014,
<https://www.rfc-editor.org/info/rfc7278>. <https://www.rfc-editor.org/info/rfc7278>.
[RFC7371] Boucadair, M. and S. Venaas, "Updates to the IPv6
Multicast Addressing Architecture", RFC 7371,
DOI 10.17487/RFC7371, September 2014,
<https://www.rfc-editor.org/info/rfc7371>.
[RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S.,
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>.
skipping to change at page 40, line 9 skipping to change at page 40, line 25
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>. <http://www.antd.nist.gov/usgv6/usgv6-v1.pdf>.
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
John Loughney John Loughney
Intel Intel
Santa Clara, CA Santa Clara, CA
USA USA
Email: john.loughney@gmail.com Email: john.loughney@gmail.com
Timothy Winters Timothy Winters
University of New Hampshire, Interoperability Lab (UNH-IOL) University of New Hampshire, Interoperability Lab (UNH-IOL)
Durham, NH Durham, NH
United States United States
Email: twinters@iol.unh.edu Email: twinters@iol.unh.edu
 End of changes. 55 change blocks. 
68 lines changed or deleted 84 lines changed or added

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