draft-ietf-6man-rfc6434-bis-05.txt   draft-ietf-6man-rfc6434-bis-06.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 31, 2018 T. Winters Expires: September 4, 2018 T. Winters
UNH-IOL UNH-IOL
February 27, 2018 March 3, 2018
IPv6 Node Requirements IPv6 Node Requirements
draft-ietf-6man-rfc6434-bis-05 draft-ietf-6man-rfc6434-bis-06
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 31, 2018. This Internet-Draft will expire on September 4, 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 2, line 24 skipping to change at page 2, line 24
1.2. Description of IPv6 Nodes . . . . . . . . . . . . . . . . 5 1.2. Description of IPv6 Nodes . . . . . . . . . . . . . . . . 5
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 . . . . 10 5.6. IPv6 Router Advertisement Flags Option - RFC 5175 . . . . 11
5.7. Path MTU Discovery and Packet Size . . . . . . . . . . . 11 5.7. Path MTU Discovery and Packet Size . . . . . . . . . . . 11
5.7.1. Path MTU Discovery - RFC 8201 . . . . . . . . . . . . 11 5.7.1. Path MTU Discovery - RFC 8201 . . . . . . . . . . . . 11
5.7.2. Minimum MTU considerations . . . . . . . . . . . . . 11 5.7.2. Minimum MTU considerations . . . . . . . . . . . . . 12
5.8. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 5.8. ICMP for the Internet Protocol Version 6 (IPv6) - RFC
4443 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4443 . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.9. Default Router Preferences and More-Specific Routes - RFC 5.9. Default Router Preferences and More-Specific Routes - RFC
4191 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4191 . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.10. First-Hop Router Selection - RFC 8028 . . . . . . . . . . 12 5.10. First-Hop Router Selection - RFC 8028 . . . . . . . . . . 12
5.11. Multicast Listener Discovery (MLD) for IPv6 - RFC 3810 . 12 5.11. Multicast Listener Discovery (MLD) for IPv6 - RFC 3810 . 12
5.12. Explicit Congestion Notification (ECN) - RFC 3168 . . . . 12 5.12. Explicit Congestion Notification (ECN) - RFC 3168 . . . . 13
6. Addressing and Address Configuration . . . . . . . . . . . . 12 6. Addressing and Address Configuration . . . . . . . . . . . . 13
6.1. IP Version 6 Addressing Architecture - RFC 4291 . . . . . 12 6.1. IP Version 6 Addressing Architecture - RFC 4291 . . . . . 13
6.2. Host Address Availability Recommendations . . . . . . . . 13 6.2. Host Address Availability Recommendations . . . . . . . . 13
6.3. IPv6 Stateless Address Autoconfiguration - RFC 4862 . . . 13 6.3. IPv6 Stateless Address Autoconfiguration - RFC 4862 . . . 14
6.4. Privacy Extensions for Address Configuration in IPv6 - 6.4. Privacy Extensions for Address Configuration in IPv6 -
RFC 4941 . . . . . . . . . . . . . . . . . . . . . . . . 14 RFC 4941 . . . . . . . . . . . . . . . . . . . . . . . . 15
6.5. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 . 15 6.5. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 . 15
6.6. Default Address Selection for IPv6 - RFC 6724 . . . . . . 15 6.6. Default Address Selection for IPv6 - RFC 6724 . . . . . . 16
7. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . 17
8.3. IPv6 Router Advertisement Options for DNS 8.3. IPv6 Router Advertisement Options for DNS
Configuration - RFC 8106 . . . . . . . . . . . . . . . . 16 Configuration - RFC 8106 . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . 18
10. IPv4 Support and Transition . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 21 14. Router-Specific Functionality . . . . . . . . . . . . . . . . 22
14.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 198 . . . . . . . . . . . . . . . . . . . . . . . . . . 23
15. Constrained Devices . . . . . . . . . . . . . . . . . . . . . 22 15. Constrained Devices . . . . . . . . . . . . . . . . . . . . . 23
16. Network Management . . . . . . . . . . . . . . . . . . . . . 23 16. Network Management . . . . . . . . . . . . . . . . . . . . . 23
16.1. Management Information Base (MIB) Modules . . . . . . . 23 16.1. Management Information Base (MIB) Modules . . . . . . . 24
16.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . 23 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) . . . . . . . . . . . . . . . . . . . 23 Protocol (IP) . . . . . . . . . . . . . . . . . . . 24
16.1.3. Interface MIB . . . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . . . 25
19. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 24 19. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 25
19.1. Authors and Acknowledgments (Current Document) . . . . . 24 19.1. Authors and Acknowledgments (Current Document) . . . . . 25
19.2. Authors and Acknowledgments from RFC 6434 . . . . . . . 24 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 . . . . . . . . . . . . . . . 26 20. Appendix: Changes from RFC 6434 . . . . . . . . . . . . . . . 25
21. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 27 21. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 27
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
22.1. Normative References . . . . . . . . . . . . . . . . . . 29 22.1. Normative References . . . . . . . . . . . . . . . . . . 28
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
hosts and routers. Many IPv6 nodes will implement optional or hosts and routers. Many IPv6 nodes will implement optional or
additional features, but this document collects and summarizes additional features, but this document collects and summarizes
requirements from other published Standards Track documents in one requirements from other published Standards Track documents in one
place. place.
skipping to change at page 6, line 43 skipping to change at page 6, line 43
5.1. Internet Protocol Version 6 - RFC 8200 5.1. Internet Protocol Version 6 - RFC 8200
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. Overlapping fragments MUST be handled as described in headers.
[RFC5722].
IPv6 nodes must not create overlapping fragments. Also, when
reassembling an IPv6 datagram, if one or more of its constituent
fragments is determined to be an overlapping fragment, the entire
datagram (and any constituent fragments) must be silently discarded.
See [RFC5722] for more information.
As recommended in [RFC8021], nodes MUST NOT generate atomic
fragments, i.e., where the fragment is a whole datagram. As per
[RFC6946], if a receiving node reassembling a datagram encounters an
atomic fragment, it should be processed as a fully reassembled
packet, and any other fragments that match this packet should be
processed independently.
[RFC6946] discusses IPv6 atomic fragments, and recommends that IPv6 [RFC6946] discusses IPv6 atomic fragments, and recommends that IPv6
atomic fragments are processed independently of any other fragments, atomic fragments are processed independently of any other fragments,
to protect against fragmentation-based attacks. [RFC8021] goes to protect against fragmentation-based attacks.
further and recommends the deprecation of atomic fragments. Nodes
thus MUST NOT generate atomic fragments.
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
field as defined in the IPv6 Flow Label specification [RFC6437]. field as defined in the IPv6 Flow Label specification [RFC6437].
Forwarding nodes such as routers and load distributors MUST NOT Forwarding nodes such as routers and load distributors MUST NOT
depend only on Flow Label values being uniformly distributed. It is depend only on Flow Label values being uniformly distributed. It is
RECOMMENDED that source hosts support the flow label by setting the RECOMMENDED that source hosts support the flow label by setting the
Flow Label field for all packets of a given flow to the same value Flow Label field for all packets of a given flow to the same value
chosen from an approximation to a discrete uniform distribution. chosen from an approximation to a discrete uniform distribution.
5.2. Support for IPv6 Extension Headers 5.2. Support for IPv6 Extension Headers
RFC 8200 specifies extension headers and the processing for these RFC 8200 specifies extension headers and the processing for these
headers. headers.
Extension headers (except for the Hop-by-Hop Options header) are not
processed, inserted, or deleted by any node along a packet's delivery
path, until the packet reaches the node (or each of the set of nodes,
in the case of multicast) identified in the Destination Address field
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 headers. An exception is
Routing Header type 0 (RH0), which was deprecated by [RFC5095] due to Routing Header type 0 (RH0), which was deprecated by [RFC5095] due to
security concerns and which MUST be treated as an unrecognized security concerns and which MUST be treated as an unrecognized
routing type. 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.
[RFC7112] discusses issues with oversized IPv6 Extension Header As per RFC 8200, when a node fragments an IPv6 datagram, it MUST
chains, and states that when a node fragments an IPv6 datagram, it include the entire IPv6 Header Chain in the first fragment. The Per-
MUST include the entire IPv6 Header Chain in the First Fragment. Fragment headers must consist of the IPv6 header plus any extension
headers that must be processed by nodes en route to the destination,
As stated in RFC8200, extension headers (except for the Hop-by-Hop that is, all headers up to and including the Routing header if
Options header) are not processed, inserted, or deleted by any node present, else the Hop-by-Hop Options header if present, else no
along a packet's delivery path, until the packet reaches the node (or extension headers. On reassembly, if the first fragment does not
each of the set of nodes, in the case of multicast) identified in the include all headers through an Upper-Layer header, then that fragment
Destination Address field of the IPv6 header. should be discarded and an ICMP Parameter Problem, Code 3, message
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
Extension Header chains are avoided.
It should be noted that when future, new Extension Headers are Defining new IPv6 extension headers is not recommended, unless there
defined, the consistent format described in Section 4 of [RFC6564] are no existing IPv6 extension headers that can be used by specifying
MUST be followed. a new option for that IPv6 extension header. A proposal to specify a
new IPv6 extension header must include a detailed technical
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
format described in Section 8 of RFC 8200. For further background
reading on this topic, see [RFC6564].
5.3. Protecting a node from excessive EH options 5.3. Protecting a node from excessive EH options
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
skipping to change at page 10, line 31 skipping to change at page 10, line 50
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
spoofing attacks, but it does not provide specific protection for spoofing attacks, but it does not provide specific protection for
threats from off-link attackers. threats from off-link attackers.
There have been relatively few implementations of SEND in common There have been relatively few implementations of SEND in common
operating systems and platforms, and thus deployment experience has operating systems and platforms since its publication in 2005, and
been limited to date. thus deployment experience remains very limited to date.
At this time, SEND is considered optional. Due to the complexity in At this time, support for SEND is considered optional. Due to the
deploying SEND, and its heavyweight provisioning, its deployment is complexity in deploying SEND, and its heavyweight provisioning, its
only likely to be considered where nodes are operating in a deployment is only likely to be considered where nodes are operating
particularly strict security environment. in a particularly strict security environment.
5.6. IPv6 Router Advertisement Flags Option - RFC 5175 5.6. IPv6 Router Advertisement Flags Option - RFC 5175
Router Advertisements include an 8-bit field of single-bit Router Router Advertisements include an 8-bit field of single-bit Router
Advertisement flags. The Router Advertisement Flags Option extends Advertisement flags. The Router Advertisement Flags Option extends
the number of available flag bits by 48 bits. At the time of this the number of available flag bits by 48 bits. At the time of this
writing, 6 of the original 8 single-bit flags have been assigned, writing, 6 of the original 8 single-bit flags have been assigned,
while 2 remain available for future assignment. No flags have been while 2 remain available for future assignment. No flags have been
defined that make use of the new option, and thus, strictly speaking, defined that make use of the new option, and thus, strictly speaking,
there is no requirement to implement the option today. However, there is no requirement to implement the option today. However,
skipping to change at page 11, line 22 skipping to change at page 11, line 41
It is strongly recommended that IPv6 nodes implement Path MTU It is strongly recommended that IPv6 nodes implement Path MTU
Discovery [RFC8201], in order to discover and take advantage of Discovery [RFC8201], in order to discover and take advantage of
path MTUs greater than 1280 octets. However, a minimal IPv6 path MTUs greater than 1280 octets. However, a minimal IPv6
implementation (e.g., in a boot ROM) may simply restrict itself to implementation (e.g., in a boot ROM) may simply restrict itself to
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.
One operational issue with Path MTU Discovery occurs when, contrary As described in RFC 8201, nodes implementing Path MTU Discovery and
to the guidance in [RFC4890], firewalls block ICMP Packet Too Big sending packets larger than the IPv6 minimum link MTU are susceptible
messages. Path MTU Discovery relies on such messages to determine to problematic connectivity if ICMPv6 messages are blocked or not
what size messages can be successfully sent. "Packetization Layer transmitted. For example, this will result in connections that
Path MTU Discovery" [RFC4821] avoids having a dependency on Packet complete the TCP three- way handshake correctly but then hang when
Too Big messages. data is transferred. This state is referred to as a black-hole
connection [RFC2923]. Path MTU Discovery relies on ICMPv6 Packet Too
Big (PTB) to determine the MTU of the path (and thus these should not
be filtered, as per the recommendation in [RFC4890]).
An extension to Path MTU Discovery defined in RFC 8201 can be found
in [RFC4821], which defines a method for Packetization Layer Path MTU
Discovery (PLPMTUD) designed for use over paths where delivery of
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.
5.8. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443 5.8. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443
skipping to change at page 22, line 50 skipping to change at page 23, line 21
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 this Section,
constrained nodes, with limited CPU, memory, bandwidth or power, we briefly discuss considerations for constrained devices.
support for certain IPv6 functionality may need to be considered due
to those limitations. The requirements of this document are In the case of constrained nodes, with limited CPU, memory, bandwidth
RECOMMENDED for all nodes, including constrained nodes, but or power, support for certain IPv6 functionality may need to be
considered due to those limitations. While the requirements of this
document are RECOMMENDED for all nodes, including constrained nodes,
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].
skipping to change at page 25, line 8 skipping to change at page 25, line 31
iteration of this document, RFC6434. iteration of this document, RFC6434.
For this version of the document, the authors thanked Hitoshi Asaeda, For this version of the document, the authors thanked Hitoshi Asaeda,
Brian Carpenter, Tim Chown, Ralph Droms, Sheila Frankel, Sam Hartman, Brian Carpenter, Tim Chown, Ralph Droms, Sheila Frankel, Sam Hartman,
Bob Hinden, Paul Hoffman, Pekka Savola, Yaron Sheffer, and Dave Bob Hinden, Paul Hoffman, Pekka Savola, Yaron Sheffer, and Dave
Thaler. Thaler.
19.3. Authors and Acknowledgments from RFC 4294 19.3. Authors and Acknowledgments from RFC 4294
The original version of this document (RFC 4294) was written by the The original version of this document (RFC 4294) was written by the
IPv6 Node Requirements design team: IPv6 Node Requirements design team, which had the following members:
Jari Arkko, Marc Blanchet, Samita Chakrabarti, Alain Durand, Gerard
Jari Arkko Gastaud, Jun-ichiro Itojun Hagino, Atsushi Inoue, Masahiro Ishiyama,
jari.arkko@ericsson.com John Loughney, Rajiv Raghunarayan, Shoichi Sakane, Dave Thaler, and
Juha Wiljakka.
Marc Blanchet
marc.blanchet@viagenie.qc.ca
Samita Chakrabarti
samita.chakrabarti@eng.sun.com
Alain Durand
alain.durand@sun.com
Gerard Gastaud
gerard.gastaud@alcatel.fr
Jun-ichiro Itojun Hagino
itojun@iijlab.net
Atsushi Inoue
inoue@isl.rdc.toshiba.co.jp
Masahiro Ishiyama
masahiro@isl.rdc.toshiba.co.jp
John Loughney
john.loughney@nokia.com
Rajiv Raghunarayan
raraghun@cisco.com
Shoichi Sakane
shouichi.sakane@jp.yokogawa.com
Dave Thaler
dthaler@windows.microsoft.com
Juha Wiljakka
juha.wiljakka@Nokia.com
The authors would like to thank Ran Atkinson, Jim Bound, Brian The authors would like to thank Ran Atkinson, Jim Bound, Brian
Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas
Narten, Juha Ollila, and Pekka Savola for their comments. Thanks to Narten, Juha Ollila, and Pekka Savola for their comments. Thanks to
Mark Andrews for comments and corrections on DNS text. Thanks to Mark Andrews for comments and corrections on DNS text. Thanks to
Alfred Hoenes for tracking the updates to various RFCs. Alfred Hoenes for tracking the updates to various RFCs.
20. Appendix: Changes from RFC 6434 20. Appendix: Changes from RFC 6434
There have been many editorial clarifications as well as significant There have been many editorial clarifications as well as significant
skipping to change at page 27, line 30 skipping to change at page 27, line 20
26. Added reference to RFC8064 for stable address creation. 26. Added reference to RFC8064 for stable address creation.
27. Added text on protection from excessive EH options 27. Added text on protection from excessive EH options
28. 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
29. 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
30. Removed dated email addresses from design team acknowledgements
for RFC 4294.
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
applicability statement and is aimed at general nodes. applicability statement and is aimed at general nodes.
skipping to change at page 36, line 19 skipping to change at page 36, line 5
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
over Non-Broadcast Multiple Access (NBMA) networks", over Non-Broadcast Multiple Access (NBMA) networks",
RFC 2491, DOI 10.17487/RFC2491, January 1999, RFC 2491, DOI 10.17487/RFC2491, January 1999,
<https://www.rfc-editor.org/info/rfc2491>. <https://www.rfc-editor.org/info/rfc2491>.
[RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of [RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of
IPv6 Packets over Frame Relay Networks Specification", IPv6 Packets over Frame Relay Networks Specification",
RFC 2590, DOI 10.17487/RFC2590, May 1999, RFC 2590, DOI 10.17487/RFC2590, May 1999,
<https://www.rfc-editor.org/info/rfc2590>. <https://www.rfc-editor.org/info/rfc2590>.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
RFC 2923, DOI 10.17487/RFC2923, September 2000,
<https://www.rfc-editor.org/info/rfc2923>.
[RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets [RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets
over IEEE 1394 Networks", RFC 3146, DOI 10.17487/RFC3146, over IEEE 1394 Networks", RFC 3146, DOI 10.17487/RFC3146,
October 2001, <https://www.rfc-editor.org/info/rfc3146>. October 2001, <https://www.rfc-editor.org/info/rfc3146>.
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6) Hain, "Representing Internet Protocol version 6 (IPv6)
Addresses in the Domain Name System (DNS)", RFC 3363, Addresses in the Domain Name System (DNS)", RFC 3363,
DOI 10.17487/RFC3363, August 2002, DOI 10.17487/RFC3363, August 2002,
<https://www.rfc-editor.org/info/rfc3363>. <https://www.rfc-editor.org/info/rfc3363>.
 End of changes. 36 change blocks. 
108 lines changed or deleted 116 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/