]> Orange

mohamed.boucadair@orange.com

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

wit sconepro collaborative networking adaptive application Traffic exchanged over a network attachment may be subject to rate-limit policies. These policies may be intentional policies (e.g., enforced as part of the activation of the network attachment and typically agreed upon service subscription) or be reactive policies (e.g., enforced temporarily to manage an overload or during a DDoS attack mitigation). Networks already support mechanisms to advertize a set of network properties to hosts using Neighbor Discovery options. Examples of such properties are 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 these policies to hosts. For address family parity, a new DHCP option is also defined. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction

Context Connectivity services are provided by networks to customers via dedicated terminating points, such as customer edges (CEs) or User Equipment (UE). To facilitate data transfer via the provider network, it is assumed that appropriate setup is provisioned over the links that connect customer terminating points and a provider network (usually via a Provider Edge (PE)), successfully allowing data exchange over these links. The required setup is referred to in this document as network attachments, while the underlying link is referred to as "bearers". The bearer can be a physical or logical link that connects a customer device to a provider network. A bearer can be a wireless or wired link. The same or multiple bearer technologies can be used to establish the bearer (e.g., WLAN, cellular) to graft customer terminating points to a network.

• Network attachment is also known as "Attachment Circuit (AC)" which is an established concept in the industry and also in the IETF (, , , etc.).

shows an example of a network that connects CEs and hosts (UE, for example).These CEs are servicing other (internal) hosts. The identification of these hosts is hidden from the network. The policies enforced at the network for an AC are per-subscriber, not per-host. Typically, if a CE is provided with a /56 IPv6 prefix, policies are enforced on that /56 not the individual /64s that will be used by internal hosts. A customer terminating point may be serviced with one (e.g., UE#1, CE#1, and CE#3) or multiple ACs (e.g., CE#2).

Sample Network Attachments

Customer terminating points are provided with a set of information (e.g., IP address/prefix) to successfully be able to send and receive traffic over an AC. A comprehensive list of provisioning parameters that are available on the PE-side of an AC is documented in . The required set of parameters is a function of the service offering. For example, a very limited set of parameters is required for mass-market service offering while a more elaborated set is required for Enterprise services (e.g., Layer 2 VPN or Layer 3 VPN ). This document leverages access control, authorization, and authentication mechanisms that are already in place for the delivery of services over these ACs. An example of an AC provided over a 3GPP network is depicted in . It is out of the scope of this document to describe all involved components. Readers may refer to for more details. provides another example of how existing tools can be leveraged for AAA purposes.

5GS Architecture

• The "AC" mention in is not present in . It is added to the figure for the readers' convenience to position an attachment circuit.

Networks Are Already Sharing Network Properties with Hosts To optimally deliver connectivity services, networks also 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 ).

Encrypted DNS option :

This option is used to discover encrypted DNS resolvers of a network.

What's In? discusses some use cases where it is beneficial to share policies with the hosts. 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 these policies to hosts. For address family parity, a DHCP option is also defined for IPv4. These options are called: Network Rate-Limit Policy (NRLP). This document uses the host/network metadata specified in . In order to ensure consistent design for both IPv4 and IPv6 ACs, groups the set of NRLP parameters that are returned independent of the address family. This blob can be leveraged in networks where DHCP is not used and ease the mapping with specific protocols used in these networks. For example, a Protocol Configuration Option (PCO) NRLP Information Element can be defined in 3GPP. 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.

• describes a candidate discovery approach using Provisioning Domains (PvDs) . That approach requires more discussion as PvD is not currently deployed in mobile networks.

What's Out? This document does not make any assumption about the type of the network (fixed, cellular, etc.) that terminates an AC. Likewise, the document does not make any assumption about the services or applications that are delivered over an AC. Whether one or multiple services are bound to the same AC is deployment specific. Applications will have access to all these NRLPs and will, thus, adjust their behavior as a function of scope and traffic category indicated in a policy (all traffic, streaming, etc.). An application that couples multiple flow types will adjust each flow type to be consistent with the specific policy for the relevant traffic category. Likewise, a host with multiple ACs may use the discovered NRLPs AC to decide how to distribute its flows over these ACs (prefer an AC 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 policy. Readers should refer, e.g., to for some examples. 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., or ). Discussion about conditions under which such a trust model can be relaxed is out of scope of this document. 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.

Design Motivation & Rationale 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

The solution specified in the document is designed to ease integration with network management tools that are used to manage and expose policies. It does so by leveraging the policy structure defined in . That same structure is also used in the context of service activation such as Network Slicing ; see the example depicted in Appendix B.5 of . The solution defined in this document:

• Does not require any data plane change.
• Applicable to any transport protocol.
• Does not impact the connection setup delay.
• Does not require to reveal the identity of the target server or the application itself to consume the signal.
• Supports cascaded environments where multiple levels to enforce rate-limiting polices is required (e.g., WAN and LAN shown in ). NRLP signals can be coupled or decoupled as a function of the local policy.
• Supports signaling policies bound to one or both traffic directions.
• Is able to signal whether a policy applies to a specific host or all hosts of a given subscriber.

Example of Cascaded NRLPs

Compared to a proxy or an encapsulation-based proposal (e.g., ), the solution defined in this document:

• Does not impact the MTU tweaking: No packet overhead is required.
• Does not suffer from side effects of multi-layer encryption schemes on the packet processing and overall performance of involved network nodes. Such issues are encountered, e.g., with the tunneled mode or long header packets in the forwarded QUIC proxy mode .
• Does not suffer from nested congestion control for tunneled proxy mode.
• Does not incur multiple round-trips in the forwarding mode for the client to start sending Short Header packets.
• Does not incur the overhead of unauthenticated re-encryption of QUIC packets in the scramble transform of the forwarding mode.
• Does not impact the forwarding peformance of network nodes. For example, the proxy forwarded mode requires rewriting connection identifiers; that is, the performance degradation will be at least equivalent to NAT.
• Does not suffer from the complications of IP address sharing . Such issues are likely to be experienced for proxy-based solutions that multiplex internal connections using one or more external IP addresses.
• Does not suffer from penalizing the proxy which could serve both good and bad clients (e.g., launching Layer 7 DDoS attacks).
• Does not require manipulating extra steering policies on the host to decide which flows can be forwarded over or outside the proxy connection.
• Requires a minor change to the network: For IPv6, upgrade PE nodes to support a new ND option. Note that all IPv6 hosts and networks are required to support Neighbor Discovery . For IPv4, configure DHCP servers to include a new DHCP option.

Sample Deployment Cases Some deployment use cases for NRLP are provided below:

• A network may advertize an NRLP when it is overloaded, including when it is under attack. The rate-limit policy is basically a reactive policy that is meant to adjust the behavior of connected hosts to better control the load during these exceptional events (issue with RAN resources, for example). The mechanism can also be used to enrich the tools that are already available to better handle attack traffic close to the source .
• Discovery of intentional policy applied on ACs (peering links, CE-PE links, etc.) when such information is not made available during the service activation or when network upgrades are performed.
• A user may configure policies on the CPE such as securing some resources to a specific internal host used for gaming or video streaming. The CPE can use the NRLP option to share these rate-limit policies to connected hosts to adjust their forwarding behavior.

Operational considerations are discussed in , while deployment incentives are described in .

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 and . Also, this document makes use fo the following terms:

Reactive policy:

Treatment given to a flow when an exceptional event occurs, such as diminished throughput to the host caused by radio interference or weak radio signal, congestion on the network caused by other users or other applications on the same host.

Intentional policy:

Configured bandwidth, pps, or similar throughput constraints applied to a flow, application, host, or subscriber.

Rate-limit:

Used as a generic term to refer to a policy to restrict the maximum bitrate of a flow.

It can be used with or without any traffic classification.

NRLP Blob This section defines the set of attributes that are included in an NRLP blob:

Optional Parameter Flags (OPF):

These flags indicate the presence of some optional parameters. The following flags are defined (from MSB to LSB):

E:

When set to "1", this flag indicates the presence of Excess Information Rate (EIR).

When set to "0", this flag indicates that EIR is not present.

P:

When set to "1", this flag indicates the presence of Peak Information Rate (PIR).

When set to "0", this flag indicates that PIR is not present.

U:

Unassigned bits. See .

Unassigned bits MUST be set to zero by senders and MUST be ignored by receivers.

Flow flags (FF):

These flags are used to express some generic properties of the flow. The following flags are defined (from MSB to LSB):

S (Scope):

1-bit field which specifies whether the policy is per host (when set to "1") or per subscriber (when set to "0).

D (Direction):

1-bit flag which indicates the direction on which to apply the enclosed policy.

When set to "1", this flag indicates that this policy is for network-to-host direction.

When set to "0", this flag indicates that this policy is for host-to-network direction.

R (Reliablity):

2-bit flag which indicates the reliability type of traffic on which to apply the enclosed policy.

When set to "00b", this flag indicates that this policy is for unreliable traffic.

When set to "01b", this flag indicates that this policy is for reliable traffic.

When set to "10b", this flag indicates that this policy is for both reliable and unreliable traffic.

No meaning is associated with setting the field to "11b". Such value MUST be silently ignored by the receiver.

U:

Unassigned bits. See .

Unassigned bits MUST be set to zero by senders and MUST be ignored by receivers.

TC (Traffic Category):

6-bit field which specifies a traffic category to which this policy applies.

The following values are supported:

• "0": All traffic. This is the default value.
• "1": Streaming
• "2": Real-time
• "3": Bulk traffic
• 4-63: Unassigned values

Committed Information Rate (CIR) (Mbps):

Specifies the maximum number of bits that a network can receive or send during one second over an AC for a traffic category.

If set to 0, this indicates to the host that an alternate path (if any) should be preferred over this one.

See .

This parameter is mandatory.

Committed Burst Size (CBS) (bytes):

Specifies the maximum burst size that can be transmitted at CIR.

MUST be greater than zero.

This parameter is mandatory.

Excess Information Rate (EIR) (Mbps):

MUST be present only if the E flag is set to '1'.

Specifies the maximum number of bits that a network can receive or send during one second over an AC for a traffic category that is out of profile.

See .

This parameter is optional.

Excess Burst Size (EBS) (bytes):

MUST be present only if EIR is also present.

Indicates the maximum excess burst size that is allowed while not complying with the CIR.

MUST be greater than zero, if present.

This parameter is optional.

Peak Information Rate (PIR) (Mbps):

MUST be present only if P flag is set to '1'.

Traffic that exceeds the CIR and the CBS is metered to the PIR.

See .

This parameter is optional.

Peak Burst Size (PBS) (bytes):

MUST be present only if PIR is also present.

Specifies the maximum burst size that can be transmitted at PIR.

MUST be greater than zero, if present.

The reader should refer to , , and for examples of how various combinations of CIR/CBS/EIR/EBS/PIR/PBS are used for policing. Typically:

• A Single-Rate, Three-Color Marker uses CIR, CBS, and EBS.
• A Dual-Rate, Three-Color Marker uses CIR, CBS, PIR, and PBS.

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 with Mandatory Fields

The format of the IPv6 RA NRLP option, with optional fields included, is illustrated in .

NRLP Option Format with Optional Fields

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.

OPF (Optional Parameter Flags):

4-bit flags which indicates the presence of some optional inforamtion in the option.

See for the structure of this field.

See for current assigned flags.

FF (Flow flags):

6-bit flags used to express some generic properties of the flow.

See for the structure of this field.

See for current assigned flags.

TC:

See .

Committed Information Rate (CIR) (Mbps):

See .

Committed Burst Size (CBS) (bytes):

See .

Excess Information Rate (EIR) (Mbps):

See . This is an optional field.

Excess Burst Size (EBS) (bytes):

See . This is an optional field.

Peak Information Rate (PIR) (Mbps):

See . This is an optional field.

Peak Burst Size (PBS) (bytes):

See . This is an optional field.

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 format of this field, with optional parameters included, is shown in .

NRLP Instance Data Format with Optional Fields Included

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.

OPF (Optional Parameter Flags):

4-bit flags which indicates the presence of some optional inforamtion in the option.

See for the structure of this field.

See for current assigned flags.

FF (Flow flags):

6-bit flags used to express some generic properties of the flow.

See for the structure of this field.

See for current assigned flags.

TC:

See .

Committed Information Rate (CIR) (Mbps):

See .

Committed Burst Size (CBS) (bytes):

See .

Excess Information Rate (EIR) (Mbps):

See . This is an optional field.

Excess Burst Size (EBS) (bytes):

See . This is an optional field.

Peak Information Rate (PIR) (Mbps):

See . This is an optional field.

Peak Burst Size (PBS) (bytes):

See . This is an optional field.

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.

Operational Considerations Sharing NRLP signals are not intended to replace usual actions to soften bottlenck issues (e.g., adequate network dimensioning and upgrades). However, given that such actions may not be always immediately possible or economically justified, NRLP signals can be considered as complementary mitigations to soften these issues by introducing some collaboration between a host and its networks to adjust their behaviors. NRLP senders should be configured with instructions about the type of network rate-limit policies to be shared with requesting hosts. These types can be provided using mechanisms such as . In contexts where the bitrate policies are known during the establishment of the underlying bearer (e.g., GBR PDU Sessions), sending NRLP signals over the AC may be redundant and should thus be disabled. In contexts where the (average) bitrate policies provided during the establishment of a bearer cannot be refreshed to echo network-specific conditions (e.g., overload) using bearer-specific mechanisms, sending NRLP signals over the AC would allow control the load at the source. When both bearer-specific policies and NRLP signals are communicated to a host, the NRLP signals takes precedence. Rate-limit policies enforced at the network are assumed to be consistent with the local jurisdictions. For example, says the following:

• ISPs are prohibited from blocking or slowing down of Internet traffic, except where necessary. The exceptions are limited to: traffic management to comply with a legal order, to ensure network integrity and security, and to manage congestion, provided that equivalent categories of traffic are treated equally.

Deployment Incentives

Networks There are a set of tradeoffs for networks to deploy NRLP discovery:

• Cost vs. benefit
• Impact on operations vs incentive to deploy
• Enhanced experience vs. impacts on nominal mode

The procedure defined in the document provides a mechanism to assist networks managing the load at the source and, thus, contribute to better handle network overloads and optimize the use of resources under non nominal conditions. The mechanism also allows to enhance the quality of experience at the LAN by providing a simple tool to communicate local policies to hosts. A minimal change is required to that aim. With the OS support, the following benefits might be considered by networks:

Improved Network Performance:

The OS can schedule network requests more efficiently, preventing network congestion, and improving overall stability and network performance with NRLP signals.

Cost Efficiency:

By managing network usage based on known rate limits, the OS can help reduce network-related costs. However, this is difficult to assess.

Networks that throttle bandwidth for reasons that are not compliant with local jurisdictions, not communicated to customers, etc. are unlikely to share NRLP signals. If these signals are shared, it is unlikely that they will mirror the actual network configuration (e.g., application-specific policies).

Applications Some applications support some forms of bandwidth measurements (e.g., ) which feed how the content is accessed to using ABR. Complementing or replacing these measurements with explicit signals depends upon:

• The extra cost that is required to support both mechanisms at the application layer.
• The complexity balance between performing the measurements vs. consuming the signal.
• Whether the measurements ("assessed property" per ) reflect actual network conditions or severely diverge.
• The availability of the network signals at the first place: it is unlikely that all networks will support sending the signals. Deployment incentives at the network may vary.
• The host support may be variable.

Applications that don't support (embedded) bandwidth measurement schemes will be enriched with the NRLP signals as this will be exposed by an OS API.

Host OS

API to facilitate Application Development:

An OS can provide more accurate available bandwidth to applications through the API (as mentioned in ), making implementation easier for applications that don't requrie dedicated bandwidth measurement.

Prevent Abuse:

The OS can allocate network resources more fairly among different processes, with NRLP signals, ensuring that no single process monopolizes the network.

Better Resource Management:

OS can also optimize resource allocation, by deprioritizing background/inactive applications in the event of high network utilization.

Enhanced Security:

Awareness of NRLPs can help the OS detect and mitigate network-related security threats, such as denial-of-service (DoS) attacks.

Improved User Experience:

By avoiding network congestion and ensuring fair resource allocation, the OS can provide a smoother, more responsive user experience.

Improved Application Development Efficiency:

OS providing rate limits through an API (as mentioned in ) can provide the above listed benefits at per application level.

Security Considerations

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

Rate-Limit Policy Objects Registry Group This document requests IANA to create a new registry group entitled "Rate-Limit Policy Objects".

Optional Parameter Flags Registry This document requests IANA to create a new registry entitled "Optional Parameter Flags" under the "Rate-Limit Policy Objects" registry group (). The initial values of this registry is provided in . Optional Parameter Flags

Bit Position	Description	Reference
1	E-flag	This-Document
2	P-flag	This-Document
3	Unassigned
4	Unassigned

The allocation policy of this new registry is "IETF Review" ().

Flow flags Registry This document requests IANA to create a new registry entitled "Flow flags" under the "Rate-Limit Policy Objects" registry group (). The initial values of this registry is provided in . Flow flags

Bit Position	Description	Reference
1	Scope (S) Flag	This-Document
2	Direction (D) Flag	This-Document
3-4	Reliability (R) Flags	This-Document
5	Unassigned
6	Unassigned

The allocation policy of this new registry is "IETF Review" ().

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

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] 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] Cloud Software Group Holdings, Inc. Cloud Software Group Holdings, Inc. Orange Nokia This document defines per-flow and per-packet metadata for both network-to-host and host-to-network signaling in Concise Data Definition Language (CDDL) which expresses both CBOR and JSON. The common metadata definition allows interworking between signaling protocols with high fidelity. The metadata is also self- describing to improve interpretation by network elements and endpoints while reducing the need for version negotiation. 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. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References IANA IANA 3GPP 3GPP BEREC The widespread interest in provider-provisioned Virtual Private Network (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first Provider Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services. To a certain extent, more than one term covers the same concept, and sometimes the same term covers more than one concept. This document seeks to make the terminology in the area clearer and more intuitive. This memo provides information for the Internet community. This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs. This memo provides information for the Internet community. This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK] Orange Juniper Telefonica Nokia Huawei Technologies This document specifies a network model for attachment circuits. The model can be used for the provisioning of attachment circuits prior or during service provisioning (e.g., VPN, Network Slice Service). A companion service model is specified in I-D.ietf-opsawg-teas- attachment-circuit. The module augments the 'ietf-network' and the Service Attachment Point (SAP) models with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs). This document defines an L2VPN Network Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). The L2NM complements the L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types. As a complement to the Layer 3 Virtual Private Network Service Model (L3SM), which is used for communication between customers and service providers, this document defines an L3VPN Network Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (L3VPN) services within a service provider network. The model provides a network-centric view of L3VPN services. The L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate communication between a service orchestrator and a network controller/orchestrator. 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 new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS, and DNS over QUIC). Particularly, it allows a host to learn an Authentication Domain Name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers. Cloud Software Group Holdings, Inc. Cloud Software Group Holdings, Inc. Orange Nokia Host-to-network (and vice versa) signaling can improve the user experience by informing the network which flows are more important and which packets within a flow are more important without having to disclose the content of the packets being delivered. The differentiated service may be provided at the network (e.g., packet discard preference), the sender (e.g., adaptive transmission or session migration), or through cooperation of both the host and the network. This document lists use cases demonstrating the need for a mechanism to share metadata about flows between a receiving host and its networks to enable differentiated traffic treatment for packets sent to the host. Such a mechanism is typically implemented using a signaling protocol between the host and a set of network elements. 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. 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. Apple Inc. Apple Inc. Google LLC This document defines an extension to UDP Proxying over HTTP that adds specific optimizations for proxied QUIC connections. This extension allows a proxy to reuse UDP 4-tuples for multiple connections. It also defines a mode of proxying in which QUIC short header packets can be forwarded using an HTTP/3 proxy rather than being re-encapsulated and re-encrypted. 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. This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context. The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF Network Slice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security. This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices. Huawei Technologies Huawei Technologies Ciena Cisco Systems, Inc Cisco Systems, Inc This document defines a YANG data model for RFC 9543 Network Slice Service. The model can be used in the Network Slice Service interface between a customer and a provider that offers RFC 9543 Network Slice Services. Ericsson Ericsson This document specifies a new Capsule (RFC9297) that can be used with CONNECT-UDP (RFC9298), CONNECT-IP (RFC9484), or other future CONNECT extensions to signal the available bitrate for media traffic that is proxied through an HTTP server. This information can be used by a media application to regulate its media bitrate in accordance with a network policy, as an alternative to in-network traffic shaping. The completion of IPv4 address allocations from IANA and the Regional Internet Registries (RIRs) is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues, and this memo identifies those common to all such address sharing approaches. Such issues include application failures, additional service monitoring complexity, new security vulnerabilities, and so on. Solution-specific discussions are out of scope. Deploying IPv6 is the only perennial way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein. This document is not an Internet Standards Track specification; it is published for informational purposes. This document specifies the Denial-of-Service Open Threat Signaling (DOTS) signal channel Call Home, which enables a Call Home DOTS server to initiate a secure connection to a Call Home DOTS client and to receive attack traffic information from the Call Home DOTS client. The Call Home DOTS server in turn uses the attack traffic information to identify compromised devices launching outgoing DDoS attacks and take appropriate mitigation action(s). The DOTS signal channel Call Home is not specific to home networks; the solution targets any deployment in which it is required to block DDoS attack traffic closer to the source(s) of a DDoS attack. This document defines a Single Rate Three Color Marker (srTCM), which can be used as component in a Diffserv traffic conditioner. This memo provides information for the Internet community. This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner. This memo provides information for the Internet community. This document describes a two-rate, three-color marker that has been in use for data services including Frame Relay services. This marker can be used for metering per-flow traffic in the emerging IP and L2 VPN services. The marker defined here is different from previously defined markers in the handling of the in-profile traffic. Furthermore, this marker doesn't impose peak-rate shaping requirements on customer edge (CE) devices. This memo provides information for the Internet community. 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]

Provisioning Domains PvD may also be considered 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

PvD NRLP object can be extended by defining new attributes (e.g., supply an ADN and locators of a network entity to negotiate advanced features with the network, reachability information of a network API to invoke differentiated forwarding behaviors, a slice identifier , etc.).

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 TODO acknowledge.