sconepro M. Boucadair Internet-Draft Orange Intended status: Standards Track D. Wing Expires: 4 January 2025 Cloud Software Group T. Reddy Nokia S. Rajagopalan Cloud Software Group G. Mishra Verizon Inc M. Amend Deutsche Telekom L. Contreras Telefonica 3 July 2024 Discovery of Network Rate-Limit Policies (NRLPs) draft-brw-sconepro-rate-policy-discovery-02 Abstract 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. Plenty operational challenges are to be yet evaluated and more experiments conducted to assess the actual benefits (including, identifying under which conditions). The document discusses these considerations. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/boucadair/draft-xxx-ac-rate-policy-discovery. Boucadair, et al. Expires 4 January 2025 [Page 1] Internet-Draft Rate-Limit Policies Discovery July 2024 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 January 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Networks Are Already Sharing Network Properties with Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. What's In? . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. What's Out? . . . . . . . . . . . . . . . . . . . . . . . 7 1.5. Running Experiments . . . . . . . . . . . . . . . . . . . 8 1.6. Design Motivation & Rationale . . . . . . . . . . . . . . 8 1.7. Sample Deployment Cases . . . . . . . . . . . . . . . . . 10 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 11 3. NRLP Blob . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. IPv6 RA NRLP Option . . . . . . . . . . . . . . . . . . . . . 14 4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 14 4.2. IPv6 Host Behavior . . . . . . . . . . . . . . . . . . . 16 5. DHCP NRLP Option . . . . . . . . . . . . . . . . . . . . . . 17 Boucadair, et al. Expires 4 January 2025 [Page 2] Internet-Draft Rate-Limit Policies Discovery July 2024 5.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 17 5.2. DHCPv4 Client Behavior . . . . . . . . . . . . . . . . . 19 6. Operational Considerations . . . . . . . . . . . . . . . . . 20 6.1. NRLP Is Complementary Not Replacement Solution . . . . . 20 6.2. Provisionning Policies . . . . . . . . . . . . . . . . . 20 6.3. Redundant vs. Useful Signal . . . . . . . . . . . . . . . 20 6.4. Fairness . . . . . . . . . . . . . . . . . . . . . . . . 20 6.5. Architectural Considerations Matter . . . . . . . . . . . 21 6.6. Service Considerations: Application Diversity & Realistic Assessment . . . . . . . . . . . . . . . . . . . . . . . 21 6.7. Operational Guidance for Signal Enforcement . . . . . . . 22 6.8. Signal Estimation . . . . . . . . . . . . . . . . . . . . 22 6.9. Signal "Interference" . . . . . . . . . . . . . . . . . . 22 7. Deployment Incentives . . . . . . . . . . . . . . . . . . . . 23 7.1. Networks . . . . . . . . . . . . . . . . . . . . . . . . 23 7.2. Applications . . . . . . . . . . . . . . . . . . . . . . 23 7.3. Host OS . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8.1. ND . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9.1. Rate-Limit Policy Objects Registry Group . . . . . . . . 26 9.2. Optional Parameter Flags Registry . . . . . . . . . . . . 26 9.3. Flow flags Registry . . . . . . . . . . . . . . . . . . . 26 9.4. Neighbor Discovery Option . . . . . . . . . . . . . . . . 27 9.5. DHCP Option . . . . . . . . . . . . . . . . . . . . . . . 27 9.6. DHCP Options Permitted in the RADIUS DHCPv4-Options Attribute . . . . . . . . . . . . . . . . . . . . . . . . 28 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.1. Normative References . . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . 29 Appendix A. Provisioning Domains . . . . . . . . . . . . . . . . 34 Appendix B. Example of Authentication, Authorization, and Accounting (AAA) . . . . . . . . . . . . . . . . . . . . 34 Appendix C. Alternative/Complementary Mechanisms . . . . . . . . 35 C.1. L4S . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 C.2. Network Slicing . . . . . . . . . . . . . . . . . . . . . 36 C.3. 3GPP UE Route Selection Policy . . . . . . . . . . . . . 36 C.4. Network APIs . . . . . . . . . . . . . . . . . . . . . . 37 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction Boucadair, et al. Expires 4 January 2025 [Page 3] Internet-Draft Rate-Limit Policies Discovery July 2024 1.1. 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 ([RFC4026], [RFC4664], [RFC4364], etc.). Figure 1 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). Hosts O O O \|/ .------. .--------------------. .------. | +------+ | +---AC----+ | | UE#1 | | | +---AC----+ CE#2 | '------' +---AC----+ | '------' | Network | .------. .---AC----+ | | | | | | .------. | CE#1 +------' | +---AC----+ CE#3 | '------' | | '------' /|\ '--------------------' /|\ O O O O O O Hosts Hosts Boucadair, et al. Expires 4 January 2025 [Page 4] Internet-Draft Rate-Limit Policies Discovery July 2024 Figure 1: 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 [I-D.ietf-opsawg-ntw-attachment-circuit]. 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 [RFC9291] or Layer 3 VPN [RFC9182]). 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 Figure 2. It is out of the scope of this document to describe all involved components. Readers may refer to [TS-23.501] for more details. Appendix B provides another example of how existing tools can be leveraged for AAA purposes. .-----. .-----. .-----. .-----. .-----. .-----. |NSSF | | NEF | | NRF | | PCF | | UDM | | AF | '--+--' '--+--' '--+--' '--+--' '--+--' '--+--' Nnssf| Nnef| Nnrf| Npcf| Nudm| |Naf ---+--------+--+-----+--+-------+---+----+--------+--- Nausf| Namf| Nsmf| .--+--. .--+--. .--+------. │AUSR │ │ AMF │ │ SMF │ '-----' '--+--' '----+----' ╱ | | ╲ Control Plane N1 ╱ |N2 |N4 ╲N4 ════════════════════════════════════════════════════════════ User Plane ╱ | │ ╲ .---. .-------. N3 .--+--. N9 .--+--. N6 .--. |UE +--+ (R)AN +-----+ UPF +----+ UPF +-----( DN ) '---' '-------' '-----' '-----' '--' |-------AC----------| Figure 2: 5GS Architecture The "AC" mention in Figure 2 is not present in [TS-23.501]. It is added to the figure for the readers' convenience to position an attachment circuit. Boucadair, et al. Expires 4 January 2025 [Page 5] Internet-Draft Rate-Limit Policies Discovery July 2024 1.2. Networks Are Already Sharing Network Properties with Hosts To optimally deliver connectivity services, networks also advertize a set of network properties [RFC9473] to connected hosts such as: Link Maximum Transmission Unit (MTU): For example, the 3GPP [TS-23.501] 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)". Section 2.10 of [RFC7066] indicates that a cellular host should honor the MTU option in the Router Advertisement (Section 4.6.4 of [RFC4861]) 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 Section 4 of [RFC9473]. Prefixes of Network Address and Protocol Translation from IPv6 clients to IPv4 servers (NAT64) [RFC8781]: 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 Section 4 of [RFC9473]). Encrypted DNS option [RFC9463]: This option is used to discover encrypted DNS resolvers of a network. 1.3. What's In? [I-D.rwbr-tsvwg-signaling-use-cases] 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 [RFC4861]*, 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 [RFC2132] is also defined for IPv4. These options are called: Network Rate-Limit Policy (NRLP). This document uses the host/network metadata specified in Section 5.1 of [I-D.rwbr-sconepro-flow-metadata]. Boucadair, et al. Expires 4 January 2025 [Page 6] Internet-Draft Rate-Limit Policies Discovery July 2024 In order to ensure consistent design for both IPv4 and IPv6 ACs, Section 3 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) [TS-24.008] 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. Appendix A describes a candidate discovery approach using Provisioning Domains (PvDs) [RFC8801]. That approach requires more discussion as PvD is not currently deployed in mobile networks. 1.4. 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 [I-D.rwbr-tsvwg-signaling-use-cases] for some examples. Boucadair, et al. Expires 4 January 2025 [Page 7] Internet-Draft Rate-Limit Policies Discovery July 2024 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., Section 9.3 of [RFC8803] or Section 8 of [I-D.ietf-masque-quic-proxy]). 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) [RFC9330], are enabled in a bottleneck link. The reader may refer to Appendix C for a list of relevant mechanisms. Whether these mechanism as alternative or complementary to explicit host/network signals is to be further assessed. 1.5. Running Experiments The benefits of enabling explicit signals are yet to be backed up with more evidence. Running experiments is thus key to assess the benefits under various setups. 1.6. Design Motivation & Rationale The main motivations for the use of ND for such a discovery are listed in Section 3 of [RFC8781]: * 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 [I-D.ietf-opsawg-ntw-attachment-circuit]. That same structure is also used in the context of service activation such as Network Slicing [RFC9543]; see the example depicted in Appendix B.5 of [I-D.ietf-teas-ietf-network-slice-nbi-yang]. The solution defined in this document: * *Does not require any data plane change*. * *Applicable to any transport protocol*. Boucadair, et al. Expires 4 January 2025 [Page 8] Internet-Draft Rate-Limit Policies Discovery July 2024 * *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 Figure 3). 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*. .------. .--------------------. | Host +---+ .---. | | | #1 | | | | | | '------' +-----+ C | | | nrlp#2 | P +--------+ Network | .------. .-----+ E | nrlp#1 | | | Host | | | | | | | #2 +---' '---' | | '------' nrlp#3 | | '--------------------' Figure 3: Example of Cascaded NRLPs Compared to a proxy or an encapsulation-based proposal (e.g., [I-D.ihlar-masque-sconepro-mediabitrate]), 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 [I-D.ietf-masque-quic-proxy]. * *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. Boucadair, et al. Expires 4 January 2025 [Page 9] Internet-Draft Rate-Limit Policies Discovery July 2024 * *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 [I-D.ietf-masque-quic-proxy] 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 [RFC6269]*. 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 [RFC4861]. For IPv4, configure DHCP servers to include a new DHCP option. 1.7. 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 [RFC9066]. * 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. Boucadair, et al. Expires 4 January 2025 [Page 10] Internet-Draft Rate-Limit Policies Discovery July 2024 Operational considerations are discussed in Section 6, while deployment incentives are described in Section 7. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the terms defined in Section 2 of [I-D.ietf-opsawg-ntw-attachment-circuit] and [RFC9473]. 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. 3. 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. Boucadair, et al. Expires 4 January 2025 [Page 11] Internet-Draft Rate-Limit Policies Discovery July 2024 U: Unassigned bits. See Section 9.2. 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 Section 9.3. 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. Boucadair, et al. Expires 4 January 2025 [Page 12] Internet-Draft Rate-Limit Policies Discovery July 2024 * "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 Section 5.1 of [I-D.rwbr-sconepro-flow-metadata]. 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 Section 5.1 of [I-D.rwbr-sconepro-flow-metadata]. 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 Boucadair, et al. Expires 4 January 2025 [Page 13] Internet-Draft Rate-Limit Policies Discovery July 2024 is set to '1'. Traffic that exceeds the CIR and the CBS is metered to the PIR. See Section 5.1 of [I-D.rwbr-sconepro-flow-metadata]. 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 [RFC2697], [RFC2698], and [RFC4115] for examples of how various combinations of CIR/CBS/EIR/EBS/PIR/PBS are used for policing. Typically: * A Single-Rate, Three-Color Marker [RFC2697] uses CIR, CBS, and EBS. * A Dual-Rate, Three-Color Marker [RFC2698] uses CIR, CBS, PIR, and PBS. 4. IPv6 RA NRLP Option 4.1. Option Format The format of the IPv6 RA NRLP option, with only mandatory fields included, is illustrated in Figure 4. MSB LSB 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | OPF | FF | TC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Committed Information Rate (CIR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Committed Burst Size (CBS) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: NRLP Option Format with Mandatory Fields The format of the IPv6 RA NRLP option, with optional fields included, is illustrated in Figure 4. Boucadair, et al. Expires 4 January 2025 [Page 14] Internet-Draft Rate-Limit Policies Discovery July 2024 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | OPF | FF | TC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Committed Information Rate (CIR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Committed Burst Size (CBS) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Excess Information Rate (EIR) (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Excess Burst Size (EBS) (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Information Rate (PIR) (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Burst Size (PBS) (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: NRLP Option Format with Optional Fields The fields of the option shown in Figure 5 are as follows: Type: 8-bit identifier of the NRLP option as assigned by IANA (TBD1) (see Section 9.4). 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 Section 3 for the structure of this field. See Table 1 for current assigned flags. FF (Flow flags): 6-bit flags used to express some generic properties of the flow. See Section 3 for the structure of this field. See Table 2 for current assigned flags. TC: See Section 3. Committed Information Rate (CIR) (Mbps): See Section 3. Committed Burst Size (CBS) (bytes): See Section 3. Boucadair, et al. Expires 4 January 2025 [Page 15] Internet-Draft Rate-Limit Policies Discovery July 2024 Excess Information Rate (EIR) (Mbps): See Section 3. This is an optional field. Excess Burst Size (EBS) (bytes): See Section 3. This is an optional field. Peak Information Rate (PIR) (Mbps): See Section 3. This is an optional field. Peak Burst Size (PBS) (bytes): See Section 3. This is an optional field. 4.2. IPv6 Host Behavior The procedure for rate-limit configuration is the same as it is with any other Neighbor Discovery option [RFC4861]. 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. Boucadair, et al. Expires 4 January 2025 [Page 16] Internet-Draft Rate-Limit Policies Discovery July 2024 5. 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. [RFC6704] specifies an approach for forcing reconfiguration of individual hosts without suffering from the limitations of the FORCERENEW design in [RFC3203]. 5.1. Option Format The format of the DHCP NRLP option is illustrated in Figure 6. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_V4_NRLP| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ NRLP Instance Data #1 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- . ... . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ optional ~ NRLP Instance Data #n ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- Figure 6: NRLP DHCP Option Format The fields of the option shown in Figure 6 are as follows: Code: OPTION_V4_NRLP (TBD2). (see Section 9.5). 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 Figure 7. When several NRLPs are to be included, the "NRLP Instance Data" field is repeated. Boucadair, et al. Expires 4 January 2025 [Page 17] Internet-Draft Rate-Limit Policies Discovery July 2024 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NRLP Instance Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPF | FF | TC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Committed Information Rate | | (CIR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Committed Burst Size (CBS) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: NRLP Instance Data Format with Mandatory Fields The format of this field, with optional parameters included, is shown in Figure 7. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NRLP Instance Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPF | FF | TC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Committed Information Rate | | (CIR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Committed Burst Size (CBS) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | Excess Information Rate | | | (EIR) | O +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P | Excess Burst Size (CBS) | T | | I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ O | Peak Information Rate | N | (PIR) | A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L | Peak Burst Size (PBS) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- Figure 8: NRLP Instance Data Format with Optional Fields Included The fields shown in Figure 8 are as follows: Boucadair, et al. Expires 4 January 2025 [Page 18] Internet-Draft Rate-Limit Policies Discovery July 2024 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 Section 3 for the structure of this field. See Table 1 for current assigned flags. FF (Flow flags): 6-bit flags used to express some generic properties of the flow. See Section 3 for the structure of this field. See Table 2 for current assigned flags. TC: See Section 3. Committed Information Rate (CIR) (Mbps): See Section 3. Committed Burst Size (CBS) (bytes): See Section 3. Excess Information Rate (EIR) (Mbps): See Section 3. This is an optional field. Excess Burst Size (EBS) (bytes): See Section 3. This is an optional field. Peak Information Rate (PIR) (Mbps): See Section 3. This is an optional field. Peak Burst Size (PBS) (bytes): See Section 3. This is an optional field. OPTION_V4_NRLP is a concatenation-requiring option. As such, the mechanism specified in [RFC3396] 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 [RFC9445]. 5.2. DHCPv4 Client Behavior To discover a network rate-limit policy, the DHCP client includes OPTION_V4_NRLP in a Parameter Request List option [RFC2132]. Boucadair, et al. Expires 4 January 2025 [Page 19] Internet-Draft Rate-Limit Policies Discovery July 2024 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. 6. Operational Considerations 6.1. NRLP Is Complementary Not Replacement Solution 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. 6.2. Provisionning Policies 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 [I-D.ietf-opsawg-ntw-attachment-circuit]. 6.3. Redundant vs. Useful Signal 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. 6.4. Fairness Rate-limit policies enforced at the network are assumed to be consistent with the local jurisdictions. For example, [BEREC] says the following: Boucadair, et al. Expires 4 January 2025 [Page 20] Internet-Draft Rate-Limit Policies Discovery July 2024 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. 6.5. Architectural Considerations Matter Approaches based on middleboxes are generally not recommended due to their inherent limitations, in terms of performance, scalability, redundancy, etc. Specifically, if the management and operation of such middleboxes remain unclear, that motivate operational issues and responsibilities. Furthermore, it is important to note that any middlebox could not necessarily cover an entire service end-to-end, thus *producing only partial observations which could not be sufficiently good at the time of generating appropriate signals*. The NRLP solution does not require such middleboxes but the consideration about partial observability applies. That concern can be softened by cascaded NLRP design. However, network integration of such appraoch is to be further elaborated. 6.6. Service Considerations: Application Diversity & Realistic Assessment Signals could be generated for multiple services and/or applications. For instance, services providing short video content might require signals different to those based on long videos. This implies the need of defining a generic method suitable for any kind of service and application, avoiding the multiplicity of solutions and the dominance of some applications over others. It should be also noted that more experimentation is needed in order to fully understand the implications of the signals in the overall performance of the network. On one hand, the co-existence of multiple flows, some of them using the signals for improving the experience, some others not. For this, more experimentation and datasets are required, so then can be clear that no flows are negatively impacted at all. On the other hand, if the experience of the flows improves and depending on the nature of the signals themselves, this might motivate a more intense usage of the network, then requiring to accommodate larger number of flows, and in consequence, reducing the available resources per application. This kind of paradox can be *assessed with more experimental results under realistic conditions (i.e., multiple users and multiple services in the network)*. Boucadair, et al. Expires 4 January 2025 [Page 21] Internet-Draft Rate-Limit Policies Discovery July 2024 6.7. Operational Guidance for Signal Enforcement Signals are conceived as indications from the network towards applications. It is not clear the way of enforcing the application to follow the indication, especially in a context where different applications from a user, or multiple users, simultaneously access the network. This can motivate a wastage of resources for generating signals with the risk of not being effective. Furthermore, it might lead to a continuous loop of signal generation because the initial signals being ignored. It is then necessary to define mechanisms to avoid permanent signal generation when ignored. Finally, signals could not be required at every moment, but only in situations that can benefit the service. Such situations could be due, for instance, to given levels of congestion, or based on previous information shared by the application (e.g., SLO thresholds) so that signals can be triggered according to service conditions. *Elaborating more operational guidance on intended signal enforcment policy is key*. 6.8. Signal Estimation The validity of the estimation produced by a network might be questioned by the application. Trust is required in a way that applications can safely follow guidance from a network. Furthermore, whatever estimation should be timely produced, avoiding the generation of aged estimations that could not correspond to the actual service circumstances. Finally, some common guidance is necessary to define a standard way of generating signals, for instance, per-flow or per group of flows. An open point is how to deal with adaptive applications, in the sense that signals could not be of value because the self-adaptation nature of these applications. 6.9. Signal "Interference" The network is built on multiple layers. In some cases, different solutions targeting similar objectives (e.g., congestion control or bottleneck mitigation) can be in place. It is then necessary to *assess the simultaneous coexistence of these solutions to avoid contradictory effects or "interferences"*. Boucadair, et al. Expires 4 January 2025 [Page 22] Internet-Draft Rate-Limit Policies Discovery July 2024 7. Deployment Incentives 7.1. 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). 7.2. Applications Some applications support some forms of bandwidth measurements (e.g., [app-measurement]) 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. Boucadair, et al. Expires 4 January 2025 [Page 23] Internet-Draft Rate-Limit Policies Discovery July 2024 * The complexity balance between performing the measurements vs. consuming the signal. * Whether the measurements ("assessed property" per [RFC9473]) 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. 7.3. Host OS API to facilitate Application Development: An OS can provide more accurate available bandwidth to applications through the API (as mentioned in Section 7.2), 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 Section 7.2) can provide the above listed benefits at per application level. 8. Security Considerations Boucadair, et al. Expires 4 January 2025 [Page 24] Internet-Draft Rate-Limit Policies Discovery July 2024 8.1. ND As discussed in [RFC8781], because RAs are required in all IPv6 configuration scenarios, RAs must already be secured, e.g., by deploying an RA-Guard [RFC6105]. 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. 8.2. 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 [RFC7610]: 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 [RFC7513]: 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. Boucadair, et al. Expires 4 January 2025 [Page 25] Internet-Draft Rate-Limit Policies Discovery July 2024 9. IANA Considerations 9.1. Rate-Limit Policy Objects Registry Group This document requests IANA to create a new registry group entitled "Rate-Limit Policy Objects". 9.2. 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 (Section 9.1). The initial values of this registry is provided in Table 1. +==============+=============+===============+ | Bit Position | Description | Reference | +==============+=============+===============+ | 1 | E-flag | This-Document | +--------------+-------------+---------------+ | 2 | P-flag | This-Document | +--------------+-------------+---------------+ | 3 | Unassigned | | +--------------+-------------+---------------+ | 4 | Unassigned | | +--------------+-------------+---------------+ Table 1: Optional Parameter Flags The allocation policy of this new registry is "IETF Review" (Section 4.8 of [RFC8126]). 9.3. Flow flags Registry This document requests IANA to create a new registry entitled "Flow flags" under the "Rate-Limit Policy Objects" registry group (Section 9.1). The initial values of this registry is provided in Table 2. Boucadair, et al. Expires 4 January 2025 [Page 26] Internet-Draft Rate-Limit Policies Discovery July 2024 +==============+=======================+===============+ | 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 | | +--------------+-----------------------+---------------+ Table 2: Flow flags The allocation policy of this new registry is "IETF Review" (Section 4.8 of [RFC8126]). 9.4. 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 [IANA-ND]. +======+=============+===============+ | Type | Description | Reference | +======+=============+===============+ | TBD1 | NRLP Option | This-Document | +------+-------------+---------------+ Table 3: Neighbor Discovery NRLP Option Note to the RFC Editor: Please replace all "TBD1" occurrences with the assigned value. 9.5. 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 [IANA-BOOTP]. Boucadair, et al. Expires 4 January 2025 [Page 27] Internet-Draft Rate-Limit Policies Discovery July 2024 +======+================+=============+=============+===============+ | Tag | Name | Data Length | Meaning | Reference | +======+================+=============+=============+===============+ | TBD2 | OPTION_V4_NRLP | N | NRLP | This-Document | | | | | Option | | +------+----------------+-------------+-------------+---------------+ Table 4: DHCP NRLP Option Note to the RFC Editor: Please replace all "TBD2" occurrences with the assigned value. 9.6. 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 [IANA-BOOTP]. +======+================+===============+===========+ | Tag | Name | | Reference | +======+================+===============+===========+ | TBD2 | OPTION_V4_NRLP | This-Document | | +------+----------------+---------------+-----------+ Table 5: New DHCP Option Permitted in the RADIUS DHCPv4-Options Attribute Registry 10. References 10.1. Normative References [I-D.rwbr-sconepro-flow-metadata] Rajagopalan, S., Wing, D., Boucadair, M., Reddy.K, T., and L. M. Contreras, "Flow Metadata for Collaborative Host/ Network Signaling", Work in Progress, Internet-Draft, draft-rwbr-sconepro-flow-metadata-02, 26 June 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, . Boucadair, et al. Expires 4 January 2025 [Page 28] Internet-Draft Rate-Limit Policies Discovery July 2024 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, DOI 10.17487/RFC3396, November 2002, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9445] Boucadair, M., Reddy.K, T., and A. DeKok, "RADIUS Extensions for DHCP-Configured Services", RFC 9445, DOI 10.17487/RFC9445, August 2023, . 10.2. Informative References [app-measurement] Gurel, Z. and A. C. Begen, "Bandwidth measurement for QUIC", 2024, . [BEREC] BEREC, "All you need to know about Net Neutrality rules in the EU", . [I-D.ietf-masque-quic-proxy] Pauly, T., Rosenberg, E., and D. Schinazi, "QUIC-Aware Proxying Using HTTP", Work in Progress, Internet-Draft, draft-ietf-masque-quic-proxy-02, 21 May 2024, . Boucadair, et al. Expires 4 January 2025 [Page 29] Internet-Draft Rate-Limit Policies Discovery July 2024 [I-D.ietf-opsawg-ntw-attachment-circuit] Boucadair, M., Roberts, R., de Dios, O. G., Barguil, S., and B. Wu, "A Network YANG Data Model for Attachment Circuits", Work in Progress, Internet-Draft, draft-ietf- opsawg-ntw-attachment-circuit-11, 15 May 2024, . [I-D.ietf-teas-5g-ns-ip-mpls] Szarkowicz, K. G., Roberts, R., Lucek, J., Boucadair, M., and L. M. Contreras, "A Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies", Work in Progress, Internet-Draft, draft-ietf-teas-5g-ns-ip-mpls- 08, 1 June 2024, . [I-D.ietf-teas-ietf-network-slice-nbi-yang] Wu, B., Dhody, D., Rokui, R., Saad, T., and J. Mullooly, "A YANG Data Model for the RFC 9543 Network Slice Service", Work in Progress, Internet-Draft, draft-ietf- teas-ietf-network-slice-nbi-yang-13, 9 May 2024, . [I-D.ihlar-masque-sconepro-mediabitrate] Ihlar, M. and M. Kühlewind, "MASQUE extension for signaling media bitrate", Work in Progress, Internet- Draft, draft-ihlar-masque-sconepro-mediabitrate-00, 9 February 2024, . [I-D.rwbr-tsvwg-signaling-use-cases] Rajagopalan, S., Wing, D., Boucadair, M., and T. Reddy.K, "Host to Network Signaling Use Cases for Collaborative Traffic Differentiation", Work in Progress, Internet- Draft, draft-rwbr-tsvwg-signaling-use-cases-02, 17 March 2024, . [IANA-BOOTP] IANA, "BOOTP Vendor Extensions and DHCP Options", . [IANA-ND] IANA, "IPv6 Neighbor Discovery Option Formats", . Boucadair, et al. Expires 4 January 2025 [Page 30] Internet-Draft Rate-Limit Policies Discovery July 2024 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999, . [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, . [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, . [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP reconfigure extension", RFC 3203, DOI 10.17487/RFC3203, December 2001, . [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, . [RFC4115] Aboul-Magd, O. and S. Rabie, "A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic", RFC 4115, DOI 10.17487/RFC4115, July 2005, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 10.17487/RFC4664, September 2006, . [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 10.17487/RFC6105, February 2011, . [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, . Boucadair, et al. Expires 4 January 2025 [Page 31] Internet-Draft Rate-Limit Policies Discovery July 2024 [RFC6704] Miles, D., Dec, W., Bristow, J., and R. Maglione, "Forcerenew Nonce Authentication", RFC 6704, DOI 10.17487/RFC6704, August 2012, . [RFC7066] Korhonen, J., Ed., Arkko, J., Ed., Savolainen, T., and S. Krishnan, "IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts", RFC 7066, DOI 10.17487/RFC7066, November 2013, . [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address Validation Improvement (SAVI) Solution for DHCP", RFC 7513, DOI 10.17487/RFC7513, May 2015, . [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers", BCP 199, RFC 7610, DOI 10.17487/RFC7610, August 2015, . [RFC8781] Colitti, L. and J. Linkova, "Discovering PREF64 in Router Advertisements", RFC 8781, DOI 10.17487/RFC8781, April 2020, . [RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W. Shao, "Discovering Provisioning Domain Names and Data", RFC 8801, DOI 10.17487/RFC8801, July 2020, . [RFC8803] Bonaventure, O., Ed., Boucadair, M., Ed., Gundavelli, S., Seo, S., and B. Hesmans, "0-RTT TCP Convert Protocol", RFC 8803, DOI 10.17487/RFC8803, July 2020, . [RFC9066] Reddy.K, T., Boucadair, M., Ed., and J. Shallow, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home", RFC 9066, DOI 10.17487/RFC9066, December 2021, . [RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182, February 2022, . Boucadair, et al. Expires 4 January 2025 [Page 32] Internet-Draft Rate-Limit Policies Discovery July 2024 [RFC9291] Boucadair, M., Ed., Gonzalez de Dios, O., Ed., Barguil, S., and L. Munoz, "A YANG Network Data Model for Layer 2 VPNs", RFC 9291, DOI 10.17487/RFC9291, September 2022, . [RFC9330] Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G. White, "Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture", RFC 9330, DOI 10.17487/RFC9330, January 2023, . [RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N., and T. Jensen, "DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)", RFC 9463, DOI 10.17487/RFC9463, November 2023, . [RFC9473] Enghardt, R. and C. Krähenbühl, "A Vocabulary of Path Properties", RFC 9473, DOI 10.17487/RFC9473, September 2023, . [RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Tantsura, "A Framework for Network Slices in Networks Built from IETF Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024, . [TR-470] BBF, "5G Wireless Wireline Convergence Architecture - Issue 2", . [TS-23.501] 3GPP, "TS 23.501: System architecture for the 5G System (5GS)", 2024, . [TS-23.503] 3GPP, "TS 23.503: Policy and charging control framework for the 5G System (5GS)", 2024, . [TS-24.008] 3GPP, "Technical Specification Group Core Network and Terminals; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 18)", 2024, . Boucadair, et al. Expires 4 January 2025 [Page 33] Internet-Draft Rate-Limit Policies Discovery July 2024 [TS-29.522] 3GPP, "TS 29.522: 5G System; Network Exposure Function Northbound APIs", 2024, . Appendix A. 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 (Section 4.1 of [RFC8801]). Figure 9 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":[ { "direction":1, "scope":1, "tc":0, "cir":50, "cbs":10000, "ebs":20000 } ] } Figure 9: 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 [TS-23.501][RFC9543], etc.). Appendix B. Example of Authentication, Authorization, and Accounting (AAA) Figure 10 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) [RFC2865] client and DHCP server capabilities. Boucadair, et al. Expires 4 January 2025 [Page 34] Internet-Draft Rate-Limit Policies Discovery July 2024 .-------------. .-------------. .-------. | Host | | NAS | | AAA | | DHCP Client | | DHCP Server | |Server | | | |RADIUS Client| | | '------+------' '------+------' '---+---' | | | o------DHCPDISCOVER------>| | | 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 Figure 10: An Example of RADIUS NRLP Exchanges Appendix C. Alternative/Complementary Mechanisms In the event of bottlenecks in a network, there are other mechanisms that provide information or help to reserve resources. These can be used within the bottleneck network or, in some cases, across network boundaries. The following sections give examples of such mechanisms and provide background information. C.1. L4S Low Latency, Low Loss, and Scalable Throughput (L4S) is an architecture defined in [RFC9330] to avoid queuing at bottlenecks by capacity-seeking congestion controllers of senders. L4S support addresses the investigated use case of this document, which considers rate limiting, which typically involves queuing discipline at the rate limiting bottleneck. If all involved elements (UE, network, and service) support L4S, the use of Explicit Congestion Notification (ECN) provides the measure used to inform the network protocol and/or service endpoints in use of impending congestion. Congestion detection and reaction may require a few RTTs to adjust to the network forwarding conditions. Boucadair, et al. Expires 4 January 2025 [Page 35] Internet-Draft Rate-Limit Policies Discovery July 2024 As of 3GPP Rel. 18 (5G Advanced, [TS-23.501]), L4S is also defined for the 5G system (5GS) and can be used by UE and its services, and for external parties of the 5GS by exposure of congestion information. C.2. Network Slicing One measure for guaranteeing resources in networks is network slicing. This is achieved by configuring certain resources like adequate QoS setup for communication streams, which are taken into account in packet schedulers along the transport path. e.g., the RAN air interface. Network slicing is considered by 3GPP for 5G [TS-23.501] (an equivalent can be achieved in 4G by configuring QFI values), by IETF [RFC9543] for transport networks, and by BBF [TR-470] for wireline access. A realization model in transport networks is detailed in [I-D.ietf-teas-5g-ns-ip-mpls]. L4S Appendix C.1 can be used for the realization of a network slice. Network slices properties (e.g., throughput) can be retrieved from an operator network or configured by third parties via a network API Appendix C.4 (e.g., 3GPP NEF). C.3. 3GPP UE Route Selection Policy UE Route Selection Policy (URSP) is a feature specified in 3GPP to match and forward traffic based upon a selection descriptor and a route descriptor as further detailed in [TS-23.503]. Specified traffic descriptors may be: * Application * IP * Domain * Non-IP * DNN * Connection Capabilities * Connectivity Group ID Specified route selection descriptors: must contain PDU Session Type Selection (e.g., IPv4v6 or IPv6) and may contain the following: Boucadair, et al. Expires 4 January 2025 [Page 36] Internet-Draft Rate-Limit Policies Discovery July 2024 * SSC Mode * Network Slice * DNN * Non-Seamless Offload indication * Access Type preference URSP rules that contain both descriptors can be announced from the provider network to a UE or preconfigured in the UE, possibly subscription-based. These rules can be used to identify services in the UE and to provide routes with explicit characteristics. URSP rules might also be triggered by the usage of network APIs Appendix C.4 and combined with network slicing Appendix C.2, for example. C.4. Network APIs Network APIs are the interface between the operator network and third-party providers. With 4G, the first methods were introduced to make network capabilities available, which has been greatly improved with the introduction of 5G. To this end, the new Network Exposure Function (NEF) is responsible for 5G, which is specified in [TS-29.522], which defines a huge list of network capabilites for monitoring and configuration for external consumption. For integration into external services, initiatives such as the CAMARA Alliance and GSMA Open Gateway provide abstractions of these exposed network capabilities into service APIs for easy integration by developers. The CAMARA API "Network Slice Booking", which is currently under development, would be a way for a service provider to configure the necessary resources in the operator network. In the background, 5G features such as network slicing Appendix C.2 , URSP Appendix C.3 and, if necessary, L4S Appendix C.1 could then ensure implementation in the operator network. Acknowledgments TODO acknowledge. Authors' Addresses Mohamed Boucadair Orange Boucadair, et al. Expires 4 January 2025 [Page 37] Internet-Draft Rate-Limit Policies Discovery July 2024 Email: mohamed.boucadair@orange.com Dan Wing Cloud Software Group Holdings, Inc. United States of America Email: danwing@gmail.com Tirumaleswar Reddy Nokia India Email: kondtir@gmail.com Sridharan Rajagopalan Cloud Software Group Holdings, Inc. United States of America Email: sridharan.girish@gmail.com Gyan Mishra Verizon Inc United States of America Email: gyan.s.mishra@verizon.com Markus Amend Deutsche Telekom Germany Email: markus.amend@telekom.de Luis M. Contreras Telefonica Spain Email: luismiguel.contrerasmurillo@telefonica.com Boucadair, et al. Expires 4 January 2025 [Page 38]