Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8504

IPv6 Node Requirements

Pages: 42
Best Current Practice: 220
Obsoletes:  6434
Part 2 of 4 – Pages 13 to 25
First   Prev   Next

Top   ToC   RFC8504 - Page 13   prevText

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.
Top   ToC   RFC8504 - Page 14
   [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].
Top   ToC   RFC8504 - Page 15
   "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.
Top   ToC   RFC8504 - Page 16

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].
Top   ToC   RFC8504 - Page 17
   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].
Top   ToC   RFC8504 - Page 18

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

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

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

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.
Top   ToC   RFC8504 - Page 23
   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
Top   ToC   RFC8504 - Page 24
   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.
Top   ToC   RFC8504 - Page 25

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.


(page 25 continued on part 3)

Next Section