6.  Addressing and Address Configuration

6.1.  IP Version 6 Addressing Architecture - RFC 4291

   The IPv6 Addressing Architecture [RFC4291] MUST be supported.

   The current IPv6 Address Architecture is based on a 64-bit boundary
   for subnet prefixes.  The reasoning behind this decision is
   documented in [RFC7421].

   Implementations MUST also support the multicast flag updates
   documented in [RFC7371].

6.2.  Host Address Availability Recommendations

   Hosts may be configured with addresses through a variety of methods,
   including Stateless Address Autoconfiguration (SLAAC), DHCPv6, or
   manual configuration.

   [RFC7934] recommends that networks provide general-purpose end hosts
   with multiple global IPv6 addresses when they attach, and it
   describes the benefits of and the options for doing so.  Routers
   SHOULD support [RFC7934] for assigning multiple addresses to a host.
   A host SHOULD support assigning multiple addresses as described in
   [RFC7934].

   Nodes SHOULD support the capability to be assigned a prefix per host
   as documented in [RFC8273].  Such an approach can offer improved host
   isolation and enhanced subscriber management on shared network
   segments.

6.3.  IPv6 Stateless Address Autoconfiguration - RFC 4862

   Hosts MUST support IPv6 Stateless Address Autoconfiguration.  It is
   RECOMMENDED, as described in [RFC8064], that unless there is a
   specific requirement for Media Access Control (MAC) addresses to be
   embedded in an Interface Identifier (IID), nodes follow the procedure
   in [RFC7217] to generate SLAAC-based addresses, rather than use
   [RFC4862].  Addresses generated using the method described in
   [RFC7217] will be the same whenever a given device (re)appears on the
   same subnet (with a specific IPv6 prefix), but the IID will vary on
   each subnet visited.

   Nodes that are routers MUST be able to generate link-local addresses
   as described in [RFC4862].

   From RFC 4862:

      The autoconfiguration process specified in this document applies
      only to hosts and not routers.  Since host autoconfiguration uses
      information advertised by routers, routers will need to be
      configured by some other means.  However, it is expected that
      routers will generate link-local addresses using the mechanism
      described in this document.  In addition, routers are expected to
      successfully pass the Duplicate Address Detection procedure
      described in this document on all addresses prior to assigning
      them to an interface.

   All nodes MUST implement Duplicate Address Detection.  Quoting from
   Section 5.4 of RFC 4862:

      Duplicate Address Detection MUST be performed on all unicast
      addresses prior to assigning them to an interface, regardless of
      whether they are obtained through stateless autoconfiguration,
      DHCPv6, or manual configuration, with the following exceptions
      [noted therein].

   "Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC4429]
   specifies a mechanism to reduce delays associated with generating
   addresses via Stateless Address Autoconfiguration [RFC4862].  RFC
   4429 was developed in conjunction with Mobile IPv6 in order to reduce
   the time needed to acquire and configure addresses as devices quickly
   move from one network to another, and it is desirable to minimize
   transition delays.  For general purpose devices, RFC 4429 remains
   optional at this time.

   [RFC7527] discusses enhanced DAD and describes an algorithm to
   automate the detection of looped-back IPv6 ND messages used by DAD.
   Nodes SHOULD implement this behavior where such detection is
   beneficial.

6.4.  Privacy Extensions for Address Configuration in IPv6 - RFC 4941

   A node using Stateless Address Autoconfiguration [RFC4862] to form a
   globally unique IPv6 address that uses its MAC address to generate
   the IID will see that the IID remains the same on any visited
   network, even though the network prefix part changes.  Thus, it is
   possible for a third-party device to track the activities of the node
   they communicate with, as that node moves around the network.
   Privacy Extensions for Stateless Address Autoconfiguration [RFC4941]
   address this concern by allowing nodes to configure an additional
   temporary address where the IID is effectively randomly generated.
   Privacy addresses are then used as source addresses for new
   communications initiated by the node.

   General issues regarding privacy issues for IPv6 addressing are
   discussed in [RFC7721].

   RFC 4941 SHOULD be supported.  In some scenarios, such as dedicated
   servers in a data center, it provides limited or no benefit, or it
   may complicate network management.  Thus, devices implementing this
   specification MUST provide a way for the end user to explicitly
   enable or disable the use of such temporary addresses.

   Note that RFC 4941 can be used independently of traditional SLAAC or
   independently of SLAAC that is based on RFC 7217.

   Implementers of RFC 4941 should be aware that certain addresses are
   reserved and should not be chosen for use as temporary addresses.
   Consult "Reserved IPv6 Interface Identifiers" [RFC5453] for more
   details.

6.5.  Stateful Address Autoconfiguration (DHCPv6) - RFC 3315

   DHCPv6 [RFC3315] can be used to obtain and configure addresses.  In
   general, a network may provide for the configuration of addresses
   through SLAAC, DHCPv6, or both.  There will be a wide range of IPv6
   deployment models and differences in address assignment requirements,
   some of which may require DHCPv6 for stateful address assignment.
   Consequently, all hosts SHOULD implement address configuration via
   DHCPv6.

   In the absence of observed Router Advertisement messages, IPv6 nodes
   MAY initiate DHCP to obtain IPv6 addresses and other configuration
   information, as described in Section 5.5.2 of [RFC4862].

   Where devices are likely to be carried by users and attached to
   multiple visited networks, DHCPv6 client anonymity profiles SHOULD be
   supported as described in [RFC7844] to minimize the disclosure of
   identifying information.  Section 5 of RFC 7844 describes operational
   considerations on the use of such anonymity profiles.

6.6.  Default Address Selection for IPv6 - RFC 6724

   IPv6 nodes will invariably have multiple addresses configured
   simultaneously and thus will need to choose which addresses to use
   for which communications.  The rules specified in the Default Address
   Selection for IPv6 document [RFC6724] MUST be implemented.  [RFC8028]
   updates Rule 5.5 from [RFC6724]; implementations SHOULD implement
   this rule.

7.  DNS

   DNS is described in [RFC1034], [RFC1035], [RFC3363], and [RFC3596].
   Not all nodes will need to resolve names; those that will never need
   to resolve DNS names do not need to implement resolver functionality.
   However, the ability to resolve names is a basic infrastructure
   capability on which applications rely, and most nodes will need to
   provide support.  All nodes SHOULD implement stub-resolver [RFC1034]
   functionality, as in Section 5.3.1 of [RFC1034], with support for:

   -  AAAA type Resource Records [RFC3596];

   -  reverse addressing in ip6.arpa using PTR records [RFC3596]; and

   -  Extension Mechanisms for DNS (EDNS(0)) [RFC6891] to allow for DNS
      packet sizes larger than 512 octets.

   Those nodes are RECOMMENDED to support DNS security extensions
   [RFC4033] [RFC4034] [RFC4035].

   A6 Resource Records [RFC2874] are classified as Historic per
   [RFC6563].  These were defined with Experimental status in [RFC3363].

8.  Configuring Non-address Information

8.1.  DHCP for Other Configuration Information

   DHCP [RFC3315] specifies a mechanism for IPv6 nodes to obtain address
   configuration information (see Section 6.5) and to obtain additional
   (non-address) configuration.  If a host implementation supports
   applications or other protocols that require configuration that is
   only available via DHCP, hosts SHOULD implement DHCP.  For
   specialized devices on which no such configuration need is present,
   DHCP may not be necessary.

   An IPv6 node can use the subset of DHCP (described in [RFC3736]) to
   obtain other configuration information.

   If an IPv6 node implements DHCP, it MUST implement the DNS options
   [RFC3646] as most deployments will expect that these options are
   available.

8.2.  Router Advertisements and Default Gateway

   There is no defined DHCPv6 Gateway option.

   Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
   are thus expected to determine their default router information and
   on-link prefix information from received Router Advertisements.

8.3.  IPv6 Router Advertisement Options for DNS Configuration - RFC 8106

   Router Advertisement options have historically been limited to those
   that are critical to basic IPv6 functionality.  Originally, DNS
   configuration was not included as an RA option, and DHCP was the
   recommended way to obtain DNS configuration information.  Over time,
   the thinking surrounding such an option has evolved.  It is now
   generally recognized that few nodes can function adequately without
   having access to a working DNS resolver; thus, a Standards Track
   document has been published to provide this capability [RFC8106].

   Implementations MUST include support for the DNS RA option [RFC8106].

8.4.  DHCP Options versus Router Advertisement Options for Host
      Configuration

   In IPv6, there are two main protocol mechanisms for propagating
   configuration information to hosts: RAs and DHCP.  RA options have
   been restricted to those deemed essential for basic network
   functioning and for which all nodes are configured with exactly the
   same information.  Examples include the Prefix Information Options,
   the MTU option, etc.  On the other hand, DHCP has generally been
   preferred for configuration of more general parameters and for
   parameters that may be client specific.  Generally speaking, however,
   there has been a desire to define only one mechanism for configuring
   a given option, rather than defining multiple (different) ways of
   configuring the same information.

   One issue with having multiple ways to configure the same information
   is that interoperability suffers if a host chooses one mechanism but
   the network operator chooses a different mechanism.  For "closed"
   environments, where the network operator has significant influence
   over what devices connect to the network and thus what configuration
   mechanisms they support, the operator may be able to ensure that a
   particular mechanism is supported by all connected hosts.  In more
   open environments, however, where arbitrary devices may connect
   (e.g., a Wi-Fi hotspot), problems can arise.  To maximize
   interoperability in such environments, hosts would need to implement
   multiple configuration mechanisms to ensure interoperability.

9.  Service Discovery Protocols

   Multicast DNS (mDNS) and DNS-based Service Discovery (DNS-SD) are
   described in [RFC6762] and [RFC6763], respectively.  These protocols,
   often collectively referred to as the 'Bonjour' protocols after their
   naming by Apple, provide the means for devices to discover services
   within a local link and, in the absence of a unicast DNS service, to
   exchange naming information.

   Where devices are to be deployed in networks where service discovery
   would be beneficial, e.g., for users seeking to discover printers or
   display devices, mDNS and DNS-SD SHOULD be supported.

10.  IPv4 Support and Transition

   IPv6 nodes MAY support IPv4.

10.1.  Transition Mechanisms

10.1.1.  Basic Transition Mechanisms for IPv6 Hosts and Routers -
         RFC 4213

   If an IPv6 node implements dual stack and tunneling, then [RFC4213]
   MUST be supported.

11.  Application Support

11.1.  Textual Representation of IPv6 Addresses - RFC 5952

   Software that allows users and operators to input IPv6 addresses in
   text form SHOULD support "A Recommendation for IPv6 Address Text
   Representation" [RFC5952].

11.2.  Application Programming Interfaces (APIs)

   There are a number of IPv6-related APIs.  This document does not
   mandate the use of any, because the choice of API does not directly
   relate to on-the-wire behavior of protocols.  Implementers, however,
   would be advised to consider providing a common API or reviewing
   existing APIs for the type of functionality they provide to
   applications.

   "Basic Socket Interface Extensions for IPv6" [RFC3493] provides IPv6
   functionality used by typical applications.  Implementers should note
   that RFC 3493 has been picked up and further standardized by the
   Portable Operating System Interface (POSIX) [POSIX].

   "Advanced Sockets Application Program Interface (API) for IPv6"
   [RFC3542] provides access to advanced IPv6 features needed by
   diagnostic and other more specialized applications.

   "IPv6 Socket API for Source Address Selection" [RFC5014] provides
   facilities that allow an application to override the default Source
   Address Selection rules of [RFC6724].

   "Socket Interface Extensions for Multicast Source Filters" [RFC3678]
   provides support for expressing source filters on multicast group
   memberships.

   "Extension to Sockets API for Mobile IPv6" [RFC4584] provides
   application support for accessing and enabling Mobile IPv6 [RFC6275]
   features.

12.  Mobility

   Mobile IPv6 [RFC6275] and associated specifications [RFC3776]
   [RFC4877] allow a node to change its point of attachment within the
   Internet, while maintaining (and using) a permanent address.  All
   communication using the permanent address continues to proceed as
   expected even as the node moves around.  The definition of Mobile IP
   includes requirements for the following types of nodes:

      - mobile nodes

      - correspondent nodes with support for route optimization

      - home agents

      - all IPv6 routers

   At the present time, Mobile IP has seen only limited implementation
   and no significant deployment, partly because it originally assumed
   an IPv6-only environment rather than a mixed IPv4/IPv6 Internet.
   Additional work has been done to support mobility in mixed-mode IPv4
   and IPv6 networks [RFC5555].

   More usage and deployment experience is needed with mobility before
   any specific approach can be recommended for broad implementation in
   all hosts and routers.  Consequently, Mobility Support in IPv6
   [RFC6275], Mobile IPv6 Support for Dual Stack Hosts and Routers
   [RFC5555], and associated standards (such as Mobile IPv6 with IKEv2
   and IPsec [RFC4877]) are considered a MAY at this time.

   IPv6 for 3GPP [RFC7066] lists a snapshot of required IPv6
   functionalities at the time the document was published that would
   need to be implemented, going above and beyond the recommendations in
   this document.  Additionally, a 3GPP IPv6 Host MAY implement
   [RFC7278] to deliver IPv6 prefixes on the LAN link.

13.  Security

   This section describes the security specification for IPv6 nodes.

   Achieving security in practice is a complex undertaking.  Operational
   procedures, protocols, key distribution mechanisms, certificate
   management approaches, etc., are all components that impact the level
   of security actually achieved in practice.  More importantly,
   deficiencies or a poor fit in any one individual component can
   significantly reduce the overall effectiveness of a particular
   security approach.

   IPsec can provide either end-to-end security between nodes or channel
   security (for example, via a site-to-site IPsec VPN), making it
   possible to provide secure communication for all (or a subset of)
   communication flows at the IP layer between pairs of Internet nodes.
   IPsec has two standard operating modes: Tunnel-mode and Transport-
   mode.  In Tunnel-mode, IPsec provides network-layer security and
   protects an entire IP packet by encapsulating the original IP packet
   and then prepending a new IP header.  In Transport-mode, IPsec
   provides security for the transport layer (and above) by
   encapsulating only the transport-layer (and above) portion of the IP
   packet (i.e., without adding a second IP header).

   Although IPsec can be used with manual keying in some cases, such
   usage has limited applicability and is not recommended.

   A range of security technologies and approaches proliferate today
   (e.g., IPsec, Transport Layer Security (TLS), Secure SHell (SSH), TLS
   VPNS, etc.).  No single approach has emerged as an ideal technology
   for all needs and environments.  Moreover, IPsec is not viewed as the
   ideal security technology in all cases and is unlikely to displace
   the others.

   Previously, IPv6 mandated implementation of IPsec and recommended the
   key-management approach of IKE.  RFC 6434 updated that recommendation
   by making support of the IPsec architecture [RFC4301] a SHOULD for
   all IPv6 nodes, and this document retains that recommendation.  Note
   that the IPsec Architecture requires the implementation of both
   manual and automatic key management (e.g., Section 4.5 of RFC 4301).
   Currently, the recommended automated key-management protocol to
   implement is IKEv2 [RFC7296].

   This document recognizes that there exists a range of device types
   and environments where approaches to security other than IPsec can be
   justified.  For example, special-purpose devices may support only a
   very limited number or type of applications, and an application-
   specific security approach may be sufficient for limited management
   or configuration capabilities.  Alternatively, some devices may run
   on extremely constrained hardware (e.g., sensors) where the full
   IPsec Architecture is not justified.

   Because most common platforms now support IPv6 and have it enabled by
   default, IPv6 security is an issue for networks that are ostensibly
   IPv4 only; see [RFC7123] for guidance on this area.

13.1.  Requirements

   "Security Architecture for the Internet Protocol" [RFC4301] SHOULD be
   supported by all IPv6 nodes.  Note that the IPsec Architecture
   requires the implementation of both manual and automatic key
   management (e.g., Section 4.5 of [RFC4301]).  Currently, the default
   automated key-management protocol to implement is IKEv2.  As required
   in [RFC4301], IPv6 nodes implementing the IPsec Architecture MUST
   implement ESP [RFC4303] and MAY implement AH [RFC4302].

13.2.  Transforms and Algorithms

   The current set of mandatory-to-implement algorithms for the IPsec
   Architecture are defined in Cryptographic Algorithm Implementation
   Requirements for ESP and AH [RFC8221].  IPv6 nodes implementing the
   IPsec Architecture MUST conform to the requirements in [RFC8221].
   Preferred cryptographic algorithms often change more frequently than
   security protocols.  Therefore, implementations MUST allow for
   migration to new algorithms, as RFC 8221 is replaced or updated in
   the future.

   The current set of mandatory-to-implement algorithms for IKEv2 are
   defined in Cryptographic Algorithm Implementation Requirements for
   ESP and AH [RFC8247].  IPv6 nodes implementing IKEv2 MUST conform to
   the requirements in [RFC8247] and/or any future updates or
   replacements to [RFC8247].

14.  Router-Specific Functionality

   This section defines general host considerations for IPv6 nodes that
   act as routers.  Currently, this section does not discuss detailed
   routing-specific requirements.  For the case of typical home routers,
   [RFC7084] defines basic requirements for customer edge routers.

14.1.  IPv6 Router Alert Option - RFC 2711

   The IPv6 Router Alert option [RFC2711] is an optional IPv6 Hop-by-Hop
   Header that is used in conjunction with some protocols (e.g., RSVP
   [RFC2205] or Multicast Listener Discovery (MLDv2) [RFC3810]).  The
   Router Alert option will need to be implemented whenever such
   protocols that mandate its use are implemented.  See Section 5.11.

14.2.  Neighbor Discovery for IPv6 - RFC 4861

   Sending Router Advertisements and processing Router Solicitations
   MUST be supported.

   Section 7 of [RFC6275] includes some mobility-specific extensions to
   Neighbor Discovery.  Routers SHOULD implement Sections 7.3 and 7.5,
   even if they do not implement home agent functionality.

14.3.  Stateful Address Autoconfiguration (DHCPv6) - RFC 3315

   A single DHCP server ([RFC3315] or [RFC4862]) can provide
   configuration information to devices directly attached to a shared
   link, as well as to devices located elsewhere within a site.
   Communication between a client and a DHCP server located on different
   links requires the use of DHCP relay agents on routers.

   In simple deployments, consisting of a single router and either a
   single LAN or multiple LANs attached to the single router, together
   with a WAN connection, a DHCP server embedded within the router is
   one common deployment scenario (e.g., [RFC7084]).  There is no need
   for relay agents in such scenarios.

   In more complex deployment scenarios, such as within enterprise or
   service provider networks, the use of DHCP requires some level of
   configuration, in order to configure relay agents, DHCP servers, etc.
   In such environments, the DHCP server might even be run on a
   traditional server, rather than as part of a router.

   Because of the wide range of deployment scenarios, support for DHCP
   server functionality on routers is optional.  However, routers
   targeted for deployment within more complex scenarios (as described
   above) SHOULD support relay agent functionality.  Note that "Basic
   Requirements for IPv6 Customer Edge Routers" [RFC7084] requires
   implementation of a DHCPv6 server function in IPv6 Customer Edge (CE)
   routers.

14.4.  IPv6 Prefix Length Recommendation for Forwarding - BCP 198

   Forwarding nodes MUST conform to BCP 198 [RFC7608]; thus, IPv6
   implementations of nodes that may forward packets MUST conform to the
   rules specified in Section 5.1 of [RFC4632].

15.  Constrained Devices

   The focus of this document is general IPv6 nodes.  In this section,
   we briefly discuss considerations for constrained devices.

   In the case of constrained nodes, with limited CPU, memory, bandwidth
   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 are made, the interoperability of devices should be
   strongly considered, particularly where this may impact other nodes
   on the same link, e.g., only supporting MLDv1 will affect other
   nodes.

   The IETF 6LowPAN (IPv6 over Low-Power Wireless Personal Area Network)
   WG produced six RFCs, including a general overview and problem
   statement [RFC4919] (the means by which IPv6 packets are transmitted
   over IEEE 802.15.4 networks [RFC4944] and ND optimizations for that
   medium [RFC6775]).

   IPv6 nodes that are battery powered SHOULD implement the
   recommendations in [RFC7772].

16.  IPv6 Node Management

   Network management MAY be supported by IPv6 nodes.  However, for IPv6
   nodes that are embedded devices, network management may be the only
   possible way of controlling these nodes.

   Existing network management protocols include SNMP [RFC3411], NETCONF
   [RFC6241], and RESTCONF [RFC8040].

16.1.  Management Information Base (MIB) Modules

   The obsoleted status of various IPv6-specific MIB modules is
   clarified in [RFC8096].

   The following two MIB modules SHOULD be supported by nodes that
   support an SNMP agent.

16.1.1.  IP Forwarding Table MIB

   The IP Forwarding Table MIB [RFC4292] SHOULD be supported by nodes
   that support an SNMP agent.

16.1.2.  Management Information Base for the Internet Protocol (IP)

   The IP MIB [RFC4293] SHOULD be supported by nodes that support an
   SNMP agent.

16.1.3.  Interface MIB

   The Interface MIB [RFC2863] SHOULD be supported by nodes that support
   an SNMP agent.

16.2.  YANG Data Models

   The following YANG data models SHOULD be supported by nodes that
   support a NETCONF or RESTCONF agent.

16.2.1.  IP Management YANG Model

   The IP Management YANG Model [RFC8344] SHOULD be supported by nodes
   that support NETCONF or RESTCONF.

16.2.2.  Interface Management YANG Model

   The Interface Management YANG Model [RFC8343] SHOULD be supported by
   nodes that support NETCONF or RESTCONF.

17.  Security Considerations

   This document does not directly affect the security of the Internet,
   beyond the security considerations associated with the individual
   protocols.

   Security is also discussed in Section 13 above.

18.  IANA Considerations

   This document has no IANA actions.