]> Cloud Software Group Holdings, Inc.

United States of America danwing@gmail.com

Nokia

India kondtir@gmail.com

Cloud Software Group Holdings, Inc.

United States of America sridharan.girish@gmail.com

Verizon Inc

United States of America gyan.s.mishra@verizon.com

Deutsche Telekom

Germany markus.amend@telekom.de

Telefonica

Spain luismiguel.contrerasmurillo@telefonica.com

wit scone collaborative networking adaptive application This document specifies mechanims for hosts to dynamically discover Network Rate-Limit Policies (NRLPs). This information is then passed to applications that might adjust their behaviors accordingly. Networks already support mechanisms to advertize a set of network properties to hosts (e.g., link MTU (RFC 4861) and PREFIX64 (RFC 8781)). This document complements these tools and specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate NRLPs to hosts. For address family parity, a new DHCP option is also defined. The document also discusses how Provisioning Domains (PvD) can be used to notify hosts with NRLPs.

Introduction To optimally deliver connectivity services via a network attachment, networks advertize a set of network properties to connected hosts such as:

Link Maximum Transmission Unit (MTU):

For example, the 3GPP specifies that "the link MTU size for IPv4 is sent to the UE by including it in the PCO (see TS 24.501). The link MTU size for IPv6 is sent to the UE by including it in the IPv6 Router Advertisement message (see RFC 4861)".

indicates that a cellular host should honor the MTU option in the Router Advertisement () given that the 3GPP system architecture uses extensive tunneling in its packet core network below the 3GPP link, and this may lead to packet fragmentation issues.

MTU is cited as an example of path properties in .

Prefixes of Network Address and Protocol Translation from IPv6 clients to IPv4 servers (NAT64) :

This option is useful to enable local DNSSEC validation, support networks with no DNS64, support IPv4 address literals on an IPv6-only host, etc.

NAT is cited as an example of path properties (see "Service Function" bullet in ).

Traffic exchanged over a network may be subject to rate-limit policies for various operational reasons. specifies a generic object (called, Throughput Advice) that can be used by mechanims for hosts to dynamically discover these network rate-limit policies. This information can then passed to applications that might adjust their behaviors accordingly. Given that all IPv6 hosts and networks are required to support Neighbor Discovery , this document specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate rate-limit policies to hosts (). The main motivations for the use of ND for such a discovery are listed in :

• Fate sharing
• Atomic configuration
• Updatability: change the policy at any time
• Deployability

For address family parity, a DHCP option is also defined for IPv4 in . describes a discovery approach using Provisioning Domains (PvDs) . These options are called: Network Rate-Limit Policy (NRLP). Whether host-to-network, network-to-host, or both policies are returned in an NRLP is deployment specific. All these combinations are supported in this document. Also, the design supports returning one more NRLP instances for a given traffic direction. Applications will have access to all available NRLPs and will, thus, adjust their behavior as a function of scope and traffic category indicated in a policy. Likewise, a host with multiple network attachments may use the discovered NRLPs to decide how to distribute its flows over these network attachments (prefer a network attachment to place an application session, migrate connection, etc.). That's said, this document does not make any recommendation about how a receiving host uses the discovered policies. Networks that advertize NLRPs are likely to maintain the policing in place within the network because of the trust model (hosts are not considered as trusted devices). Per-subscriber rate-limit policies are generally recommended to protect nodes against Denial of Service (DoS) attacks (e.g., ). Discussion about conditions under which such a trust model can be relaxed is out of scope of this document. To enhance flexibility in applying rate-limiting policies and better accommodate diverse endpoint performance requirements, mechanisms such as solicited Router Advertisements (RAs) and endpoint-specific DHCP responses can be used. These unicast responses enable granular signaling of rate-limit policies to individual endpoints, facilitating differentiated rate-limit configurations. However, this document does not prescribe how resources should be partitioned within local networks, as such considerations fall outside its scope. This document does not assume nor preclude that other mechanisms, e.g., Low Latency, Low Loss, and Scalable Throughput (L4S) , are enabled in a bottleneck link. The reader may refer to I-D.brw-scone-manageability for a list of relevant mechanisms. Refer to for configuration examples to use NRLP.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here. This document uses the terms defined in .

Common NLRP Parameters The following common fields are present in all NRLP options:

Instance Flags (IF) The format of this 8-bit flags is shown in . This field is used to express some generic properties of the advice.

Flow flags Field

See for the meaning of the R/D/S flags. U are unassigned bits. These bits MUST be set to zero by senders and MUST be ignored by receivers.

Traffic Category (TC) & Throughput Parameters The following parameters are used:

TC:

See .

Committed Information Rate (CIR) (Mbps):

See .

This is a mandatory parameter.

Committed Burst Size (CBS) (bytes):

See .

This is a mandatory parameter.

IPv6 RA NRLP Option

Option Format The format of the IPv6 RA NRLP option, with only mandatory fields included, is illustrated in .

NRLP Option Format

The fields of the option shown in are as follows:

Type:

8-bit identifier of the NRLP option as assigned by IANA (TBD1) (see ).

Length:

8-bit unsigned integer. The length of the option (including the Type and Length fields) is in units of 8 octets.

Refer to for the meaning of the other parameters.

IPv6 Host Behavior The procedure for rate-limit configuration is the same as it is with any other Neighbor Discovery option . The host MUST be prepared to receive multiple NRLP options in RAs; each with distinct scope and/or application group. If the host receives multiple NRLP options with overlapping scope/TC, the host MUST silently discard all these options. If the receiving host has LAN capabilities (e.g., mobile CE or mobile handset with tethering), the following behavior applies:

• If an RA NRLP is advertised from the network, and absent local rate-limit policies, the device should send RAs to the downstream attached LAN devices with the same NRLP values received from the network.
• If local rate-limit policies are provided to the device, the device may change the scope or values received from the network to accommodate these policies. The device may decide to not relay received RAs to internal nodes if local policies were already advertized using RAs and those policies are consistent with the network policies.

Applications running over a host can learn the bitrates associated with a network attachment by invoking a dedicated API. The exact details of the API is OS-specific and, thus, out of scope of this document.

DHCP NRLP Option

• Note that the base DHCP can only signal a rate policy change when the client first joins the network or renews its lease, whereas IPv6 ND can update the rate policy at the network's discretion. specifies an approach for forcing reconfiguration of individual hosts without suffering from the limitations of the FORCERENEW design in .

Option Format The format of the DHCP NRLP option is illustrated in .

NRLP DHCP Option Format

The fields of the option shown in are as follows:

Code:

OPTION_V4_NRLP (TBD2). (see ).

Length:

Indicates the length of the enclosed data in octets.

NRLP Instance Data:

Includes a network rate-limit policy. The format of this field with only mandatory parameters is shown in .

When several NRLPs are to be included, the "NRLP Instance Data" field is repeated.

NRLP Instance Data Format with Mandatory Fields

The fields shown in are as follows:

NRLP Instance Data Length:

Length of all following data in octets. This field is set to '8' when only the nominal bitrate is provided for an NLRP instance.

Refer to for the meaning of the other parameters. OPTION_V4_NRLP is a concatenation-requiring option. As such, the mechanism specified in MUST be used if OPTION_V4_NRLP exceeds the maximum DHCP option size of 255 octets. OPTION_V4_NRLP is permitted to be included in the RADIUS DHCPv4-Options Attribute .

DHCPv4 Client Behavior To discover a network rate-limit policy, the DHCP client includes OPTION_V4_NRLP in a Parameter Request List option . The DHCP client MUST be prepared to receive multiple "NRLP Instance Data" field entries in the OPTION_V4_NRLP option; each instance is to be treated as a separate network rate-limit policy.

Provisioning Domains PvD may also be used as a mechanism to discover NRLP. Typically, the network will configured to set the H-flag so clients can request PvD Additional Information (). provides an example of the returned "application/pvd+json" to indicate a network-to-host NRLP for all subscriber traffic. The NRLP list may include multiple instances if distinct policies are to be returned for distinct traffic categories.

NRLP Example with PvD

Security Considerations The techniques discussed in the document offer the following security benefit: An OS can identify the type of application (background, foreground, streaming, real-time, etc.) and enforce appropriate network policies, even if a misbehaving application tries to evade the rate-limit policies. If an application attempts to bypass rate-limiting by changing its 5-tuple or creating multiple flows, the OS can detect this and manage the application's traffic accordingly.

ND As discussed in , because RAs are required in all IPv6 configuration scenarios, RAs must already be secured, e.g., by deploying an RA-Guard . Providing all configuration in RAs reduces the attack surface to be targeted by malicious attackers trying to provide hosts with invalid configuration, as compared to distributing the configuration through multiple different mechanisms that need to be secured independently. RAs are already used in mobile networks to advertize the link MTU. The same security considerations for MTU discovery apply for the NRLP discover. An attacker who has access to the RAs exchanged over an AC may:

Decrease the bitrate:

This may lower the perceived QoS if the host aggressively lowers its transmission rate.

Increase the bitrate value:

The AC will be overloaded, but still the rate-limit at the network will discard excess traffic.

Drop RAs:

This is similar to the current operations, where no NRLP RA is shared.

Inject fake RAs:

The implications are similar to the impacts of tweaking the values of a legitimate RA.

DHCP An attacker who has access to the DHCP exchanged over an AC may do a lot of harm (e.g., prevent access to the network). The following mechanisms may be considered to mitigate spoofed or modified DHCP responses:

DHCPv6-Shield :

The network access node (e.g., a border router, a CPE, an Access Point (AP)) discards DHCP response messages received from any local endpoint.

Source Address Validation Improvement (SAVI) solution for DHCP :

The network access node filters packets with forged source IP addresses.

The above mechanisms would ensure that the endpoint receives the correct NRLP information, but these mechanisms cannot provide any information about the DHCP server or the entity hosting the DHCP server.

IANA Considerations

Neighbor Discovery Option This document requests IANA to assign the following new IPv6 Neighbor Discovery Option type in the "IPv6 Neighbor Discovery Option Formats" sub-registry under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry maintained at . Neighbor Discovery NRLP Option

Type	Description	Reference
TBD1	NRLP Option	This-Document

• Note to the RFC Editor: Please replace all "TBD1" occurrences with the assigned value.

DHCP Option This document requests IANA to assign the following new DHCP Option Code in the "BOOTP Vendor Extensions and DHCP Options" registry maintained at . DHCP NRLP Option

Tag	Name	Data Length	Meaning	Reference
TBD2	OPTION_V4_NRLP	N	NRLP Option	This-Document

• Note to the RFC Editor: Please replace all "TBD2" occurrences with the assigned value.

DHCP Options Permitted in the RADIUS DHCPv4-Options Attribute This document requests IANA to add the following DHCP Option Code to the "DHCP Options Permitted in the RADIUS DHCPv4-Options Attribute" registry maintained at . New DHCP Option Permitted in the RADIUS DHCPv4-Options Attribute Registry

Tag	Name	Reference
TBD2	OPTION_V4_NRLP	This-Document

Provisioning Domains Split DNS Additional Information IANA is requested to add the following entry to the "Additional Information PvD Keys" registry under the "Provisioning Domains (PvDs)" registry group :

JSON key:

"nrlp"

Description:

"Network Rate-Limit Policies (NRLPs)"

Type:

Array of Objects

Example:

Reference:

This-Document

New PvD Network Rate-Limit Policies (NRLPs) Registry IANA is requested to create a new registry "PvD Rate-Limit Policies (NRLPs)" registry, within the "Provisioning Domains (PvDs)" registry group. The initial contents of this registry are provided in . Initial PvD Network Rate-Limit Policies (NRLPs) Registry Content

JSON key	Description	Type	Example	Reference
scope	Specifies whether the policy is per host (when set to "1") or per subscriber (when set to "0)	Boolean	1	This-Document
direction	Indicates the traffic direction to which a policy applies	integer	1	This-Document
reliability	Specifies whether the policy is for both reliable and unreliable traffic (when set to "0"), for reliable (when set to "1"), or for unreliable traffic (when set to "2")	integer	1	This-Document
tc	Specifies a traffic category to which this policy applies	Integer	0	This-Document
cir	Committed Information Rate (CIR)	Integer	50	This-Document
cbs	Committed Burst Size (CBS)	Integer	10000	This-Document

Assignments must not be added directly to the "PvD Network Rate-Limit Policies (NRLPs)" registry. When a new attribute is added to the "SCONE Rate-Limit Policy Objects" Registry Group created by , a new JSON key is mirrored in the "PvD Network Rate-Limit Policies (NRLPs)" registry.

References Normative References This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK] Orange Cloud Software Group Holdings, Inc. Nokia Cloud Software Group Holdings, Inc. Telefonica Traffic exchanged over a network may be subject to rate-limit policies for various operational reasons. This document specifies a generic object (called, Throughput Advice) that can be used by mechanisms for hosts to dynamically discover these network rate-limit policies. This information is then passed to applications that might adjust their behaviors accordingly. The design of the throughput advice object is independent of the discovery channel (protocol, API, etc.). This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRACK] Provisioning Domains (PvDs) are defined as consistent sets of network configuration information. PvDs allows hosts to manage connections to multiple networks and interfaces simultaneously, such as when a home router provides connectivity through both a broadband and cellular network provider. This document defines a mechanism for explicitly identifying PvDs through a Router Advertisement (RA) option. This RA option announces a PvD identifier, which hosts can compare to differentiate between PvDs. The option can directly carry some information about a PvD and can optionally point to PvD Additional Information that can be retrieved using HTTP over TLS. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies two new Remote Authentication Dial-In User Service (RADIUS) attributes that carry DHCP options. The specification is generic and can be applicable to any service that relies upon DHCP. Both DHCPv4- and DHCPv6-configured services are covered. Also, this document updates RFC 4014 by relaxing a constraint on permitted RADIUS attributes in the RADIUS Attributes DHCP suboption. Informative References IANA IANA IANA 3GPP Path properties express information about paths across a network and the services provided via such paths. In a path-aware network, path properties may be fully or partially available to entities such as endpoints. This document defines and categorizes path properties. Furthermore, the document identifies several path properties that might be useful to endpoints or other entities, e.g., for selecting between paths or for invoking some of the provided services. This document is a product of the Path Aware Networking Research Group (PANRG). As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations have made the Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost, and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), or Evolved Packet System (EPS) networks (hereafter collectively referred to as Third Generation Partnership Project (3GPP) networks). This document also lists specific IPv6 functionalities that need to be implemented in addition to what is already prescribed in the IPv6 Node Requirements document (RFC 6434). It also discusses some issues related to the use of these components when operating in these networks. This document obsoletes RFC 3316. This document specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate prefixes of Network Address and Protocol Translation from IPv6 clients to IPv4 servers (NAT64) to hosts. This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. A Transport Converter may provide conversion service for one or more TCP extensions. The conversion service is provided by means of the 0-RTT TCP Convert Protocol (Convert). This protocol provides 0-RTT (Zero Round-Trip Time) conversion service since no extra delay is induced by the protocol compared to connections that are not proxied. Also, the Convert Protocol does not require any encapsulation (no tunnels whatsoever). This specification assumes an explicit model, where the Transport Converter is explicitly configured on hosts. As a sample applicability use case, this document specifies how the Convert Protocol applies for Multipath TCP. This document outlines an approach utilizing existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of using a unique IPv6 prefix over a unique service-provider IPv6 address include improved host isolation and enhanced subscriber management on shared network segments. This document describes the L4S architecture, which enables Internet applications to achieve low queuing latency, low congestion loss, and scalable throughput control. L4S is based on the insight that the root cause of queuing delay is in the capacity-seeking congestion controllers of senders, not in the queue itself. With the L4S architecture, all Internet applications could (but do not have to) transition away from congestion control algorithms that cause substantial queuing delay and instead adopt a new class of congestion controls that can seek capacity with very little queuing. These are aided by a modified form of Explicit Congestion Notification (ECN) from the network. With this new architecture, applications can have both low latency and high throughput. The architecture primarily concerns incremental deployment. It defines mechanisms that allow the new class of L4S congestion controls to coexist with 'Classic' congestion controls in a shared network. The aim is for L4S latency and throughput to be usually much better (and rarely worse) while typically not impacting Classic performance. Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the reconfiguration of a single host by forcing the DHCP client into a Renew state on a trigger from the DHCP server. In the Forcerenew Nonce Authentication protocol, the server sends a nonce to the client in the initial DHCP ACK that is used for subsequent validation of a FORCERENEW message. This document updates RFC 3203. [STANDARDS-TRACK] This document defines extensions to DHCP (Dynamic Host Configuration Protocol) to allow dynamic reconfiguration of a single host triggered by the DHCP server (e.g., a new IP address and/or local configuration parameters). [STANDARDS-TRACK] Routed protocols are often susceptible to spoof attacks. The canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that is non-trivial to deploy. This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status. This document is not an Internet Standards Track specification; it is published for informational purposes. This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. It is based on DHCPv6 packet filtering at the layer 2 device at which the packets are received. A similar mechanism has been widely deployed in IPv4 networks ('DHCP snooping'); hence, it is desirable that similar functionality be provided for IPv6 networks. This document specifies a Best Current Practice for the implementation of DHCPv6-Shield. This document specifies the procedure for creating a binding between a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source Address Validation Improvement (SAVI) device. The bindings set up by this procedure are used to filter packets with forged source IP addresses. This mechanism complements BCP 38 (RFC 2827) ingress filtering, providing finer-grained source IP address validation. This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]

Example of Authentication, Authorization, and Accounting (AAA) provides an example of the exchanges that might occur between a DHCP server and an Authentication, Authorization, and Accounting (AAA) server to retrieve the per-subscriber NRLPs. This example assumes that the Network Access Server (NAS) embeds both Remote Authentication Dial-In User Service (RADIUS) client and DHCP server capabilities.

An Example of RADIUS NRLP Exchanges | | | o----Access-Request ---->| | | | | |<----Access-Accept------o | | DHCPv4-Options | |<-----DHCPOFFER----------o (OPTION_V4_NRLP) | | (OPTION_V4_NRLP) | | | | | o-----DHCPREQUEST-------->| | | (OPTION_V4_NRLP) | | | | | |<-------DHCPACK----------o | | (OPTION_V4_NRLP) | | | | | DHCP RADIUS ]]>

Acknowledgments Thanks to Tommy Pauly for the comment on PvD.