Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+SearchTech-invite World Map Symbol

RFC 8504

BCP 220
Pages: 42
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: 6MAN

IPv6 Node Requirements

Part 1 of 4, p. 1 to 13
None     Next Section

Obsoletes:    6434


Top       ToC       Page 1 
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 Requirements

Abstract

   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.

Top      ToC       Page 2 
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

Top      ToC       Page 3 
     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

Top      ToC       Page 4 
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.

Top      ToC       Page 5 
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 Protocol

4.  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.

Top      ToC       Page 6 
   -  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.

Top      ToC       Page 7 
   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.

Top      ToC       Page 8 
   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

Top      ToC       Page 9 
   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.

Top      ToC       Page 10 
   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.

Top      ToC       Page 11 
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.

Top      ToC       Page 12 
   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].

Top      ToC       Page 13 
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)

Next Section