RFC 8504
IPv6 Node Requirements
Internet Engineering Task Force (IETF) T. Chown Request for Comments: 8504 Jisc BCP: 220 J. Loughney Obsoletes: 6434 Intel Category: Best Current Practice T. Winters ISSN: 2070-1721 UNH-IOL January 2019 IPv6 Node RequirementsAbstract
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC 6434, and in turn RFC 4294. Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8504.
Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope of This Document . . . . . . . . . . . . . . . . . 4 1.2. Description of IPv6 Nodes . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. Abbreviations Used in This Document . . . . . . . . . . . . . 5 4. Sub-IP Layer . . . . . . . . . . . . . . . . . . . . . . . . 5 5. IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Internet Protocol Version 6 - RFC 8200 . . . . . . . . . 6 5.2. Support for IPv6 Extension Headers . . . . . . . . . . . 7 5.3. Protecting a Node from Excessive Extension Header Options 8 5.4. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . 9 5.5. SEcure Neighbor Discovery (SEND) - RFC 3971 . . . . . . . 11 5.6. IPv6 Router Advertisement Flags Option - RFC 5175 . . . . 11 5.7. Path MTU Discovery and Packet Size . . . . . . . . . . . 11 5.7.1. Path MTU Discovery - RFC 8201 . . . . . . . . . . . . 11 5.7.2. Minimum MTU Considerations . . . . . . . . . . . . . 12 5.8. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443 . . . . . . . . . . . . . . . . . . . . . . . . 12 5.9. Default Router Preferences and More-Specific Routes - RFC 4191 . . . . . . . . . . . . . . . . . . . . . . . . 12 5.10. First-Hop Router Selection - RFC 8028 . . . . . . . . . . 12 5.11. Multicast Listener Discovery (MLD) for IPv6 - RFC 3810 . 13 5.12. Explicit Congestion Notification (ECN) - RFC 3168 . . . . 13 6. Addressing and Address Configuration . . . . . . . . . . . . 13 6.1. IP Version 6 Addressing Architecture - RFC 4291 . . . . . 13 6.2. Host Address Availability Recommendations . . . . . . . . 13 6.3. IPv6 Stateless Address Autoconfiguration - RFC 4862 . . . 14 6.4. Privacy Extensions for Address Configuration in IPv6 - RFC 4941 . . . . . . . . . . . . . . . . . . . . . . . . 15
6.5. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 . 16
6.6. Default Address Selection for IPv6 - RFC 6724 . . . . . . 16
7. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Configuring Non-address Information . . . . . . . . . . . . . 17
8.1. DHCP for Other Configuration Information . . . . . . . . 17
8.2. Router Advertisements and Default Gateway . . . . . . . . 17
8.3. IPv6 Router Advertisement Options for DNS
Configuration - RFC 8106 . . . . . . . . . . . . . . . . 17
8.4. DHCP Options versus Router Advertisement Options for Host
Configuration . . . . . . . . . . . . . . . . . . . . . . 18
9. Service Discovery Protocols . . . . . . . . . . . . . . . . . 18
10. IPv4 Support and Transition . . . . . . . . . . . . . . . . . 18
10.1. Transition Mechanisms . . . . . . . . . . . . . . . . . 19
10.1.1. Basic Transition Mechanisms for IPv6 Hosts and
Routers - RFC 4213 . . . . . . . . . . . . . . . . . 19
11. Application Support . . . . . . . . . . . . . . . . . . . . . 19
11.1. Textual Representation of IPv6 Addresses - RFC 5952 . . 19
11.2. Application Programming Interfaces (APIs) . . . . . . . 19
12. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 22
13.2. Transforms and Algorithms . . . . . . . . . . . . . . . 22
14. Router-Specific Functionality . . . . . . . . . . . . . . . . 22
14.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . . 22
14.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . 22
14.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 . 23
14.4. IPv6 Prefix Length Recommendation for Forwarding -
BCP 198 . . . . . . . . . . . . . . . . . . . . . . . . 23
15. Constrained Devices . . . . . . . . . . . . . . . . . . . . . 23
16. IPv6 Node Management . . . . . . . . . . . . . . . . . . . . 24
16.1. Management Information Base (MIB) Modules . . . . . . . 24
16.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . 24
16.1.2. Management Information Base for the Internet
Protocol (IP) . . . . . . . . . . . . . . . . . . . 24
16.1.3. Interface MIB . . . . . . . . . . . . . . . . . . . 24
16.2. YANG Data Models . . . . . . . . . . . . . . . . . . . . 25
16.2.1. IP Management YANG Model . . . . . . . . . . . . . . 25
16.2.2. Interface Management YANG Model . . . . . . . . . . 25
17. Security Considerations . . . . . . . . . . . . . . . . . . . 25
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
19.1. Normative References . . . . . . . . . . . . . . . . . . 25
19.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Changes from RFC 6434 . . . . . . . . . . . . . . . 38
Appendix B. Changes from RFC 4294 to RFC 6434 . . . . . . . . . 39
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction
This document defines common functionality required by both IPv6 hosts and routers. Many IPv6 nodes will implement optional or additional features, but this document collects and summarizes requirements from other published Standards Track documents in one place. This document tries to avoid discussion of protocol details and references RFCs for this purpose. This document is intended to be an applicability statement and to provide guidance as to which IPv6 specifications should be implemented in the general case and which specifications may be of interest to specific deployment scenarios. This document does not update any individual protocol document RFCs. Although this document points to different specifications, it should be noted that in many cases, the granularity of a particular requirement will be smaller than a single specification, as many specifications define multiple, independent pieces, some of which may not be mandatory. In addition, most specifications define both client and server behavior in the same specification, while many implementations will be focused on only one of those roles. This document defines a minimal level of requirement needed for a device to provide useful Internet service and considers a broad range of device types and deployment scenarios. Because of the wide range of deployment scenarios, the minimal requirements specified in this document may not be sufficient for all deployment scenarios. It is perfectly reasonable (and indeed expected) for other profiles to define additional or stricter requirements appropriate for specific usage and deployment environments. As an example, this document does not mandate that all clients support DHCP, but some deployment scenarios may deem it appropriate to make such a requirement. As another example, NIST has defined profiles for specialized requirements for IPv6 in target environments (see [USGv6]). 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 that they should adhere to Jon Postel's Robustness Principle: "Be conservative in what you do, be liberal in what you accept from others" [RFC793].1.1. Scope of This Document
IPv6 covers many specifications. It is intended that IPv6 will be deployed in many different situations and environments. Therefore, it is important to develop requirements for IPv6 nodes to ensure interoperability.
1.2. Description of IPv6 Nodes
From "Internet Protocol, Version 6 (IPv6) Specification" [RFC8200], we have the following definitions: IPv6 node - a device that implements IPv6. IPv6 router - a node that forwards IPv6 packets not explicitly addressed to itself. IPv6 host - any IPv6 node that is not a router.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.3. Abbreviations Used in This Document
AH Authentication Header DAD Duplicate Address Detection ESP Encapsulating Security Payload ICMP Internet Control Message Protocol IKE Internet Key Exchange MIB Management Information Base MLD Multicast Listener Discovery MTU Maximum Transmission Unit NA Neighbor Advertisement NBMA Non-Broadcast Multi-Access ND Neighbor Discovery NS Neighbor Solicitation NUD Neighbor Unreachability Detection PPP Point-to-Point Protocol4. Sub-IP Layer
An IPv6 node MUST include support for one or more IPv6 link-layer specifications. Which link-layer specifications an implementation should include will depend upon what link layers are supported by the hardware available on the system. It is possible for a conformant IPv6 node to support IPv6 on some of its interfaces and not on others. As IPv6 is run over new Layer 2 technologies, it is expected that new specifications will be issued. We list here some of the Layer 2 technologies for which an IPv6 specification has been developed. It is provided for informational purposes only and may not be complete.
- Transmission of IPv6 Packets over Ethernet Networks [RFC2464] - Transmission of IPv6 Packets over Frame Relay Networks Specification [RFC2590] - Transmission of IPv6 Packets over IEEE 1394 Networks [RFC3146] - Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel [RFC4338] - Transmission of IPv6 Packets over IEEE 802.15.4 Networks [RFC4944] - Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks [RFC5121] - IP version 6 over PPP [RFC5072] In addition to traditional physical link layers, it is also possible to tunnel IPv6 over other protocols. Examples include: - Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) [RFC4380] - Basic Transition Mechanisms for IPv6 Hosts and Routers (see Section 3 of [RFC4213])5. IP Layer
5.1. Internet Protocol Version 6 - RFC 8200
The Internet Protocol version 6 is specified in [RFC8200]. This specification MUST be supported. The node MUST follow the packet transmission rules in RFC 8200. All conformant IPv6 implementations MUST be capable of sending and receiving IPv6 packets; forwarding functionality MAY be supported. Nodes MUST always be able to send, receive, and process Fragment headers. 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. To mitigate a variety of potential attacks, nodes SHOULD avoid using predictable Fragment Identification values in Fragment headers, as discussed in [RFC7739]. All nodes SHOULD support the setting and use of the IPv6 Flow Label field as defined in the IPv6 Flow Label specification [RFC6437]. Forwarding nodes such as routers and load distributors MUST NOT depend only on Flow Label values being uniformly distributed. It is 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 chosen from an approximation to a discrete uniform distribution.5.2. Support for IPv6 Extension Headers
RFC 8200 specifies extension headers and the processing for these 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 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 header is not recognized by a node, that action applies whether the value is an unrecognized extension header or an unrecognized upper- layer protocol (ULP). An IPv6 node MUST be able to process these extension headers. An exception is Routing Header type 0 (RH0), which was deprecated by [RFC5095] due to security concerns and which MUST be treated as an unrecognized routing type. Further, [RFC7045] adds specific requirements for the processing of extension headers, in particular that any forwarding node along an IPv6 packet's path, which forwards the packet for any reason, SHOULD do so regardless of any extension headers that are present.
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- Fragment headers MUST consist of the IPv6 header plus any extension headers that MUST be processed by nodes en route to the destination, that is, all headers up to and including the Routing header if present, else the Hop-by-Hop Options header if present, else no extension headers. On reassembly, if the first fragment does not include all headers through an upper-layer header, then that fragment 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. Defining new IPv6 extension headers is not recommended, unless there 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 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, it needs 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 Extension Header Options
As per RFC 8200, end hosts are expected to process all extension headers, destination options, and hop-by-hop options in a packet. Given that the only limit on the number and size of extension headers is the MTU, the processing of received packets could be considerable. 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 may place limits on the number and sizes of extension headers and options it is willing to process. A host MAY limit the number of consecutive PAD1 options in destination options or hop-by-hop options to 7. In this case, if there are more than 7 consecutive PAD1 options present, the packet MAY be silently discarded. The rationale is that if padding of 8 or more bytes is required, then the PADN option SHOULD be used. A host MAY limit the number of bytes in a PADN option to be less than 8. In such a case, if a PADN option is present that has a length greater than 7, the packet SHOULD be silently discarded. The rationale for this guideline is that the purpose of padding is for alignment and 8 bytes is the maximum alignment used in IPv6. A host MAY disallow unknown options in destination options or hop-by- hop options. This SHOULD be configurable where the default is to accept unknown options and process them per [RFC8200]. If a packet
with unknown options is received and the host is configured to disallow them, then the packet SHOULD be silently discarded. A host MAY impose a limit on the maximum number of non-padding options allowed in the destination options and hop-by-hop extension headers. If this feature is supported, the maximum number SHOULD be configurable, and the default value SHOULD be set to 8. The limits for destination options and hop-by-hop options may be separately configurable. If a packet is received and the number of destination or hop-by-hop options exceeds the limit, then the packet SHOULD be silently discarded. A host MAY impose a limit on the maximum length of Destination Options or Hop-by-Hop Options extension headers. This value SHOULD be configurable, and the default is to accept options of any length. If a packet is received and the length of the Destination or Hop-by- Hop Options extension header exceeds the length limit, then the packet SHOULD be silently discarded.5.4. Neighbor Discovery for IPv6 - RFC 4861
Neighbor Discovery is defined in [RFC4861]; the definition was updated by [RFC5942]. Neighbor Discovery MUST be supported with the noted exceptions below. RFC 4861 states: Unless specified otherwise (in a document that covers operating IP over a particular link type) this document applies to all link types. However, because ND uses link-layer multicast for some of its services, it is possible that on some link types (e.g., Non-Broadcast Multi-Access (NBMA) links), alternative protocols or mechanisms to implement those services will be specified (in the appropriate document covering the operation of IP over a particular link type). The services described in this document that are not directly dependent on multicast, such as Redirects, Next-hop determination, Neighbor Unreachability Detection, etc., are expected to be provided as specified in this document. The details of how one uses ND on NBMA links are addressed in [RFC2491]. Some detailed analysis of Neighbor Discovery follows: Router Discovery is how hosts locate routers that reside on an attached link. Hosts MUST support Router Discovery functionality. Prefix Discovery is how hosts discover the set of address prefixes that define which destinations are on-link for an attached link. Hosts MUST support Prefix Discovery.
Hosts MUST also implement Neighbor Unreachability Detection (NUD) for all paths between hosts and neighboring nodes. NUD is not required for paths between routers. However, all nodes MUST respond to unicast Neighbor Solicitation (NS) messages. [RFC7048] discusses NUD, in particular cases where it behaves too impatiently. It states that if a node transmits more than a certain number of packets, then it SHOULD use the exponential backoff of the retransmit timer, up to a certain threshold point. Hosts MUST support the sending of Router Solicitations and the receiving of Router Advertisements (RAs). The ability to understand individual RA options is dependent on supporting the functionality making use of the particular option. [RFC7559] discusses packet loss resiliency for Router Solicitations and requires that nodes MUST use a specific exponential backoff algorithm for retransmission of Router Solicitations. All nodes MUST support the sending and receiving of Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages. NS and NA messages are required for Duplicate Address Detection (DAD). Hosts SHOULD support the processing of Redirect functionality. Routers MUST support the sending of Redirects, though not necessarily for every individual packet (e.g., due to rate limiting). Redirects are only useful on networks supporting hosts. In core networks dominated by routers, Redirects are typically disabled. The sending of Redirects SHOULD be disabled by default on routers intended to be deployed on core networks. They MAY be enabled by default on routers intended to support hosts on edge networks. As specified in [RFC6980], nodes MUST NOT employ IPv6 fragmentation for sending any of the following Neighbor Discovery and SEcure Neighbor Discovery messages: Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, Router Advertisement, Redirect, or Certification Path Solicitation. Nodes MUST silently ignore any of these messages on receipt if fragmented. See RFC 6980 for details and motivation. "IPv6 Host-to-Router Load Sharing" [RFC4311] includes additional recommendations on how to select from a set of available routers. [RFC4311] SHOULD be supported.
5.5. SEcure Neighbor Discovery (SEND) - RFC 3971
SEND [RFC3971] and Cryptographically Generated Addresses (CGAs) [RFC3972] provide a way to secure the message exchanges of Neighbor Discovery. SEND has the potential to address certain classes of spoofing attacks, but it does not provide specific protection for threats from off-link attackers. There have been relatively few implementations of SEND in common operating systems and platforms since its publication in 2005; thus, deployment experience remains very limited to date. At this time, support for SEND is considered optional. Due to the complexity in deploying SEND and its heavyweight provisioning, its deployment is only likely to be considered where nodes are operating in a particularly strict security environment.5.6. IPv6 Router Advertisement Flags Option - RFC 5175
Router Advertisements include an 8-bit field of single-bit Router Advertisement flags. The Router Advertisement Flags Option extends 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, while 2 remain available for future assignment. No flags have been defined that make use of the new option; thus, strictly speaking, there is no requirement to implement the option today. However, implementations that are able to pass unrecognized options to a higher-level entity that may be able to understand them (e.g., a user-level process using a "raw socket" facility) MAY take steps to handle the option in anticipation of a future usage.5.7. Path MTU Discovery and Packet Size
5.7.1. Path MTU Discovery - RFC 8201
"Path MTU Discovery for IP version 6" [RFC8201] SHOULD be supported. From [RFC8200]: It is strongly recommended that IPv6 nodes implement Path MTU Discovery [RFC8201], in order to discover and take advantage of path MTUs greater than 1280 octets. However, a minimal IPv6 implementation (e.g., in a boot ROM) may simply restrict itself to sending packets no larger than 1280 octets, and omit implementation of Path MTU Discovery. The rules in [RFC8200] and [RFC5722] MUST be followed for packet fragmentation and reassembly.
As described in RFC 8201, nodes implementing Path MTU Discovery and sending packets larger than the IPv6 minimum link MTU are susceptible to problematic connectivity if ICMPv6 messages are blocked or not transmitted. For example, this will result in connections that complete the TCP three-way handshake correctly but then hang when 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 MUST NOT be filtered, as per the recommendation in [RFC4890]). An alternative 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
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 sender use a large MTU if they can, in order to avoid gratuitous fragmentation-caused packet drops.5.8. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443
ICMPv6 [RFC4443] MUST be supported. "Extended ICMP to Support Multi- Part Messages" [RFC4884] MAY be supported.5.9. Default Router Preferences and More-Specific Routes - RFC 4191
"Default Router Preferences and More-Specific Routes" [RFC4191] provides support for nodes attached to multiple (different) networks, each providing routers that advertise themselves as default routers via Router Advertisements. In some scenarios, one router may provide connectivity to destinations that the other router does not, and choosing the "wrong" default router can result in reachability failures. In order to resolve this scenario, IPv6 nodes MUST implement [RFC4191] and SHOULD implement the Type C host role defined in RFC 4191.5.10. First-Hop Router Selection - RFC 8028
In multihomed scenarios, where a host has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 ingress filtering, the host may have multiple routers to choose from. Hosts that may be deployed in such multihomed environments SHOULD follow the guidance given in [RFC8028].
5.11. Multicast Listener Discovery (MLD) for IPv6 - RFC 3810
Nodes that need to join multicast groups MUST support MLDv2 [RFC3810]. MLD is needed by any node that is expected to receive and process multicast traffic; in particular, MLDv2 is required for support for source-specific multicast (SSM) as per [RFC4607]. Previous versions of this specification only required MLDv1 [RFC2710] to be implemented on all nodes. Since participation of any MLDv1-only nodes on a link require that all other nodes on the link then operate in version 1 compatibility mode, the requirement to support MLDv2 on all nodes was upgraded to a MUST. Further, SSM is now the preferred multicast distribution method, rather than Any- Source Multicast (ASM). Note that Neighbor Discovery (as used on most link types -- see Section 5.4) depends on multicast and requires that nodes join Solicited Node multicast addresses.5.12. Explicit Congestion Notification (ECN) - RFC 3168
An ECN-aware router sets a mark in the IP header in order to signal impending congestion, rather than dropping a packet. The receiver of the packet echoes the congestion indication to the sender, which can then reduce its transmission rate as if it detected a dropped packet. Nodes SHOULD support ECN [RFC3168] by implementing an interface for the upper layer to access and by setting the ECN bits in the IP header. The benefits of using ECN are documented in [RFC8087].
(page 13 continued on part 2)
