DISPATCH G. A. Scalone Internet-Draft Vodafone Intended status: Informational 31 August 2026 Expires: 4 March 2027 Customer-Facing Relay (CFR): Enhancing Source Privacy in Encrypted Transport and CDN Scenarios draft-scalone-cfr-source-privacy-02 Abstract Encrypted ClientHello (ECH) protects sensitive TLS ClientHello fields, including the Server Name Indication (SNI), from on-path observers. ECH does not, however, attempt to hide the client's network-layer source identity from the ECH client-facing server (CFS). In split-mode deployments, the CFS decrypts the ClientHelloInner in order to route the connection to the appropriate backend while also receiving the connection from the client's visible source address. This creates a distinct source-privacy problem. Where ECH service and content front-door infrastructure are concentrated, a relatively small number of providers can obtain a privileged vantage point from which a stable source address can be correlated with many encrypted destinations and with other service telemetry. Measurements over a corpus of approximately one million domains, together with an active- ECH validation subset, show substantial front-door concentration and motivate treating source privacy as a complement to destination privacy. This document describes the Customer-Facing Relay (CFR), a network- layer, access-side source-aliasing function. A CFR forwards encrypted TCP or UDP traffic without terminating TLS or QUIC and replaces the subscriber-visible source address with a shared or short-lived source alias. The document also examines the different privacy properties of IPv4 NAT/CGN and IPv6 source addressing and identifies requirements for privacy-preserving source mapping. 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/. Scalone Expires 4 March 2027 [Page 1] Internet-Draft CFR Source Privacy August 2026 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 March 2027. Copyright Notice Copyright (c) 2026 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Source Privacy and the ECH Trust Boundary . . . . . . . . . . 5 3.1. Destination privacy is not source privacy . . . . . . . . 5 3.2. General and privileged linkability . . . . . . . . . . . 6 3.3. Profiling and identity joins . . . . . . . . . . . . . . 6 4. Measurement of Front-Door Concentration . . . . . . . . . . . 6 4.1. General one-million-domain scan . . . . . . . . . . . . . 7 4.2. Exploratory linkability classification . . . . . . . . . 7 4.3. Active-ECH validation subset . . . . . . . . . . . . . . 8 4.4. Interpretation and limitations . . . . . . . . . . . . . 8 5. Customer-Facing Relay Concept . . . . . . . . . . . . . . . . 8 5.1. Basic topology . . . . . . . . . . . . . . . . . . . . . 8 5.2. Visibility split . . . . . . . . . . . . . . . . . . . . 9 5.3. CFR characteristics . . . . . . . . . . . . . . . . . . . 10 6. IPv4 NAT, CGN, and Source Privacy . . . . . . . . . . . . . . 10 6.1. Address sharing is useful but not sufficient . . . . . . 11 6.2. CGN and profiling . . . . . . . . . . . . . . . . . . . . 11 6.3. Desired IPv4 mapping properties . . . . . . . . . . . . . 12 7. IPv6 Addressing, Prefixes, and Source Privacy . . . . . . . . 12 7.1. Temporary addresses do not hide the network prefix . . . 12 7.2. NPTv6 is not an unlinkability mechanism . . . . . . . . . 13 7.3. CFR options for IPv6 . . . . . . . . . . . . . . . . . . 13 7.4. Desired IPv6 mapping properties . . . . . . . . . . . . . 13 8. CFR Privacy Requirements . . . . . . . . . . . . . . . . . . 14 Scalone Expires 4 March 2027 [Page 2] Internet-Draft CFR Source Privacy August 2026 9. Discovery and Bootstrapping . . . . . . . . . . . . . . . . . 15 10. Performance and Transport Considerations . . . . . . . . . . 15 11. Abuse Prevention and Accountability . . . . . . . . . . . . . 16 12. Relationship to Existing Work . . . . . . . . . . . . . . . . 16 12.1. Encrypted ClientHello . . . . . . . . . . . . . . . . . 16 12.2. Encrypted DNS . . . . . . . . . . . . . . . . . . . . . 17 12.3. IPv4 NAT and CGN . . . . . . . . . . . . . . . . . . . . 17 12.4. IPv6 privacy addressing . . . . . . . . . . . . . . . . 17 12.5. ECH deployment considerations . . . . . . . . . . . . . 17 12.6. Proxy and relay systems . . . . . . . . . . . . . . . . 17 13. Security and Privacy Considerations . . . . . . . . . . . . . 17 13.1. Collusion . . . . . . . . . . . . . . . . . . . . . . . 17 13.2. Timing correlation . . . . . . . . . . . . . . . . . . . 18 13.3. Small anonymity sets . . . . . . . . . . . . . . . . . . 18 13.4. Stable alias assignment . . . . . . . . . . . . . . . . 18 13.5. State exhaustion and denial of service . . . . . . . . . 18 13.6. Open-relay abuse . . . . . . . . . . . . . . . . . . . . 18 13.7. Identity joins outside the network layer . . . . . . . . 19 13.8. Operational drift . . . . . . . . . . . . . . . . . . . 19 14. IETF Standardization Questions . . . . . . . . . . . . . . . 19 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 16. Informative References . . . . . . . . . . . . . . . . . . . 20 Appendix A. Changes from -01 to -02 . . . . . . . . . . . . . . 21 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction TLS 1.3 and Encrypted ClientHello (ECH) [RFC9849] substantially reduce the amount of destination information available to passive on- path observers. ECH encrypts the ClientHelloInner, including the true server name and other potentially sensitive handshake fields. The ECH configuration can be bootstrapped through SVCB or HTTPS DNS records as specified in [RFC9848]. ECH deliberately has a different trust boundary from the problem considered in this document. In split mode, the client-facing server is the ECH service provider. It receives the connection from the client, decrypts the ClientHelloInner, and forwards the resulting ClientHelloInner to the appropriate backend server. ECH therefore protects the inner destination from parties outside that trust boundary; it does not attempt to make the client anonymous to the client-facing server. This distinction becomes increasingly relevant when a small number of infrastructure providers front a large fraction of Internet services. An observer at such a front door can have a stronger correlation capability than a generic on-path observer because it can combine: Scalone Expires 4 March 2027 [Page 3] Internet-Draft CFR Source Privacy August 2026 * a stable or recurring network-layer source identifier; * the destination information needed to process the ECH connection; * connection timing and recurrence; * transport and anti-abuse telemetry; and * in some deployments, identity-adjacent signals such as login, bot management, analytics, or account-security events. This document calls this capability _privileged linkability_. It is not a failure of ECH. Rather, it is a separate privacy problem that becomes more important as destination privacy improves and front-door infrastructure becomes more concentrated. The Customer-Facing Relay (CFR) is proposed as one possible network- native mechanism to address this problem. A CFR is positioned in or near the access network and changes the source address and, where applicable, source port seen by the upstream CFS. It does not terminate TLS or QUIC and does not require access to the ClientHelloInner. The objective is to split visibility so that the access side can identify the subscriber but not the ECH-protected inner destination, while the CFS can identify the inner destination but sees only a CFR-provided source alias rather than a durable subscriber source identifier. The initial scope of CFR is client-initiated encrypted traffic. Unsolicited inbound connectivity and general-purpose server hosting are out of scope. 2. Terminology *CFR (Customer-Facing Relay):* A network function positioned in or near an access network that forwards encrypted traffic while replacing the client-visible source address with a source alias. A CFR does not terminate TLS or QUIC. *CFS (Client-Facing Server):* The ECH service provider defined by [RFC9849]. In split mode it decrypts the ClientHelloInner and forwards it to the appropriate backend server. *Backend Server:* The server that terminates the end-to-end TLS connection in an ECH split-mode deployment. *Front Door:* An infrastructure service that receives a large set of client connections on behalf of multiple origins. A CFS operated by a CDN or hosting provider is a typical example. Scalone Expires 4 March 2027 [Page 4] Internet-Draft CFR Source Privacy August 2026 *Inner Destination:* Destination-identifying information contained in the ECH-protected ClientHelloInner, most notably the true server name. *Source Alias:* The network-layer source address, and where applicable transport source port, presented by the CFR to the upstream front door in place of the subscriber's original source information. *Privacy Epoch:* An implementation-defined interval or policy boundary across which a CFR may change the source alias used for new flows. A privacy epoch does not imply that the mapping of an existing transport flow changes. *General Linkability:* The ability of a generic observer to correlate a user, host, or household across connections using network and protocol metadata. *Privileged Linkability:* The ability of a front-door observer to correlate connections while also having access to information or telemetry that is not available to a generic on-path observer, including the destination information processed by the CFS. 3. Source Privacy and the ECH Trust Boundary 3.1. Destination privacy is not source privacy ECH aims to make connections to server names within an anonymity set indistinguishable to attackers outside the ECH service boundary [RFC9849]. Its use therefore removes important destination information from the ordinary network path. However, the network source address remains outside TLS and is necessarily visible to the server receiving the transport connection. In a conventional ECH deployment without a source-privacy mechanism, the CFS can therefore observe both: 1. the source address from which the connection arrived; and 2. the ClientHelloInner that it successfully decrypts and processes. This creates a direct source-to-destination correlation point at the CFS. CFR changes the first item without changing the second. The CFS continues to perform its ECH role, but the source visible to it is an alias belonging to a shared CFR pool rather than the subscriber's durable access-network source identifier. Scalone Expires 4 March 2027 [Page 5] Internet-Draft CFR Source Privacy August 2026 3.2. General and privileged linkability It is useful to distinguish two related but different privacy questions. General linkability asks whether an observer can correlate traffic using addresses, timing, DNS information, TLS metadata, recurrence, and other signals available from an ordinary network vantage point. Privileged linkability asks what can be inferred by an entity that is itself part of the service path and therefore legitimately receives additional information needed to operate the service. A CFS is such an entity. As ECH deployment increases, general destination visibility can decrease while the relative value of the CFS vantage point increases. This is a redistribution of visibility, not an argument against ECH. 3.3. Profiling and identity joins A stable source address does not need to identify a natural person in order to be privacy-relevant. It can first act as a pseudonymous correlation key. A front-door provider may observe repeated connections from the same source or small source set and combine them with timing, destination clusters, transport characteristics, anti-abuse signals, or service- specific telemetry. The resulting profile can be useful even before the subscriber's civil identity is known. The privacy risk increases if the same provider family also operates services that can create an identity join. Examples include account login, federated identity, CAPTCHA or bot-management workflows, fraud checks, analytics, or other authenticated interactions. A later identity event can potentially enrich a previously pseudonymous history. This document does not assume that front-door providers perform such profiling. The point is architectural: the combination of source continuity, destination visibility, concentration, and identity- adjacent telemetry creates the capability. 4. Measurement of Front-Door Concentration This section reports measurements performed by the author during 2026. The measurements are motivating evidence rather than protocol requirements. They represent a snapshot and should be reproduced longitudinally and from multiple network vantage points. Scalone Expires 4 March 2027 [Page 6] Internet-Draft CFR Source Privacy August 2026 4.1. General one-million-domain scan A scan processed 1,000,131 domains. The resulting mappings contained 646,843 unique IP addresses and 17,060 unique ASNs associated with the resolved addresses. Observed concentration included: * the largest ASN covered 32.7% of domains; * the ten largest ASNs covered 53.5% of domains; * the largest individual IP address covered 4.2% of domains; and * the ten largest individual IP addresses covered 36.4% of domains. AS13335 alone accounted for 326,804 domains in this dataset. These values are not themselves a proof of profiling. They show that a limited set of infrastructure vantage points can receive connections for a large number of otherwise unrelated domains, which amplifies the privacy effect of any stable source identifier visible at those vantage points. 4.2. Exploratory linkability classification An exploratory linkability classification used during the measurement campaign placed 58.6% of the full-domain corpus in high or very-high linkability buckets, with 33.5% in the very-high bucket. For domains without observed ECH deployment, 65.8% were classified as high or very-high and 41.2% as very-high. Domains with ECH present showed lower generic linkability in this metric (27.0% high or very- high), while exhibiting substantially stronger provider concentration. This difference is important. A generic linkability metric is not sufficient to describe the privacy properties of an ECH front door. Provider concentration and CFS privilege form a separate dimension. The scoring methodology is not standardized by this document and the classification results should therefore be treated as exploratory. Scalone Expires 4 March 2027 [Page 7] Internet-Draft CFR Source Privacy August 2026 4.3. Active-ECH validation subset A separate active-ECH validation run tested 186,999 domains. Of these, 185,957 completed a confirmed ECH handshake, corresponding to 99.44% of all tested domains and 99.89% of the domains for which ECH was advertised in the tested set. In an enrichment of the active-ECH subset: * 99.27% of domains mapped to a single ASN, AS13335; and * the most common individual IP address covered 21.4% of active-ECH domains. The ASN result is the more conservative concentration signal. A domain can advertise multiple IP addresses, so naive IP-based percentages can double-count a domain and should not be interpreted as mutually exclusive market-share values. 4.4. Interpretation and limitations The measurements support three limited conclusions. First, ECH is operationally deployable at significant scale. Second, active ECH deployment in the measured snapshot was highly concentrated in front-door infrastructure. Third, the privacy question cannot be reduced to whether ECH hides the server name from the ordinary path. It is also necessary to consider what a concentrated CFS can correlate using the source identifier that remains visible to it. The results do not establish user-level tracking, do not measure provider intent, and do not establish a universal deployment distribution. Further work should repeat the measurements over time, across geographies and resolvers, and with explicit grouping of infrastructure belonging to the same provider family. 5. Customer-Facing Relay Concept 5.1. Basic topology The conceptual path is: Client -> Access Network / CFR -> ECH CFS -> Backend Scalone Expires 4 March 2027 [Page 8] Internet-Draft CFR Source Privacy August 2026 The CFR is not the ECH CFS and does not possess the ECH private key. It forwards the encrypted transport flow toward the CFS while replacing the subscriber-visible source information with a source alias. For TCP, the CFR may use NAT/NAPT-like state or an equivalent relay mechanism. For UDP and QUIC, the CFR maintains sufficient state to preserve the mapping for the lifetime of the flow while leaving QUIC packets opaque. The mechanism may be integrated into an existing access gateway or deployed as a dedicated network function. The defining property is the privacy boundary, not a particular implementation. 5.2. Visibility split A more precise privacy model distinguishes the front-door network destination from the ECH-protected inner destination. +=========+============+=============+==============+=============+ | Entity | Subscriber | Front-door | Inner | Application | | | identity/ | destination | destination | content | | | source | | | | +=========+============+=============+==============+=============+ | Client | yes | yes | yes | yes | +---------+------------+-------------+--------------+-------------+ | Access/ | yes | yes | no, assuming | no | | CFR | | | ECH and | | | | | | protected | | | | | | DNS | | +---------+------------+-------------+--------------+-------------+ | CFS/ | no, if CFR | yes | yes | no in ECH | | front | is | | | split mode | | door | effective | | | | +---------+------------+-------------+--------------+-------------+ | Backend | no direct | via CFS | yes | yes after | | | subscriber | | | TLS | | | source in | | | termination | | | the CFR | | | | | | split | | | | +---------+------------+-------------+--------------+-------------+ Table 1 Scalone Expires 4 March 2027 [Page 9] Internet-Draft CFR Source Privacy August 2026 The access/CFR must know where to forward packets and therefore cannot be said to know no destination at all. Its privacy advantage is that the ECH-protected inner server name is not required for forwarding. Conversely, the CFS knows the inner destination as part of its ECH role but, with a properly operated CFR, does not receive the subscriber's durable source identifier. No single entity in this simplified model obtains both subscriber identity and inner destination unless there is collusion, compromise, side-channel correlation, or an additional information source. 5.3. CFR characteristics A CFR is intended to have the following characteristics: * transport preserving: it supports encrypted TCP and UDP traffic; * no TLS or QUIC termination; * no ClientHelloInner inspection; * no application-content inspection; * source aliasing using a shared address and/or prefix pool; * mapping stability for the lifetime of an existing flow; * alias change across new flows or privacy epochs where operationally safe; * IPv4 and IPv6 support; * restricted use by authorized access-network customers; and * incremental deployability. A CFR is not intended to be a filtering, categorization, traffic- shaping, or lawful-intercept function. 6. IPv4 NAT, CGN, and Source Privacy Scalone Expires 4 March 2027 [Page 10] Internet-Draft CFR Source Privacy August 2026 6.1. Address sharing is useful but not sufficient IPv4 NAT44 and carrier-grade NAT (CGN) already create a form of source aggregation. Multiple subscribers can share one external IPv4 address, which can increase the size of the anonymity set visible to an upstream service. However, existing NAT behavior is not designed to provide cross- service unlinkability. NAT behavioral requirements such as [RFC4787], [RFC5382], [RFC6888], and [RFC7857] primarily address interoperability, robustness, security, and predictable application behavior. For example, endpoint-independent mapping and paired address pooling can produce useful operational stability. That same stability can also allow an external address to function as a recurring pseudonymous identifier. Similarly, port obfuscation recommendations in [RFC6056] and [RFC7857] are primarily intended to make transport instance identifiers harder for an off-path attacker to guess. Port randomization does not by itself prevent a front-door observer from grouping connections that repeatedly arrive from the same external IP address. 6.2. CGN and profiling CGN can make one external address represent many subscribers, but the privacy benefit depends on implementation details including: * pool size and concurrent population; * duration of subscriber-to-address affinity; * whether address selection is stable across destinations; * port-set allocation behavior; * mapping lifetime; * traffic timing and recurrence; and * auxiliary signals visible at the upstream service. Consequently, "behind CGN" should not be treated as equivalent to "unlinkable". Scalone Expires 4 March 2027 [Page 11] Internet-Draft CFR Source Privacy August 2026 A CFR-specific IPv4 profile should avoid using a stable external address as a long-lived subscriber pseudonym. It should also avoid changing the mapping of an established transport flow merely to obtain more frequent rotation. 6.3. Desired IPv4 mapping properties A future CFR specification should define measurable privacy properties for IPv4 source mapping. Candidate properties include: 1. *Flow stability:* the external address/port mapping remains stable for the lifetime required by the transport flow. 2. *Cross-flow rotation:* new flows can be assigned different external aliases across time or privacy epochs. 3. *Shared pools:* aliases are drawn from pools used concurrently by multiple subscribers. 4. *No durable one-to-one assignment:* the external address should not become a long-lived deterministic identifier for one subscriber. 5. *Port obfuscation:* when source ports are translated, the translation should not introduce trivially predictable per- subscriber structure. 6. *Destination independence of privacy policy:* an implementation should not create a stable alias solely because many destinations happen to be served by the same front-door provider. The exact trade-off among stability, entropy, port exhaustion, logging, and application compatibility is left for future work. 7. IPv6 Addressing, Prefixes, and Source Privacy 7.1. Temporary addresses do not hide the network prefix IPv6 commonly avoids address translation. Host-side privacy mechanisms such as temporary addresses [RFC8981] improve privacy by changing randomized interface identifiers over time. This is valuable but addresses a different layer of the problem. An external observer may still see a stable or slowly changing network prefix associated with a household, access line, or subscriber delegation. Multiple temporary interface identifiers under the same visible prefix can therefore remain groupable. Scalone Expires 4 March 2027 [Page 12] Internet-Draft CFR Source Privacy August 2026 The broader privacy properties of IPv6 address-generation mechanisms are discussed in [RFC7721]. 7.2. NPTv6 is not an unlinkability mechanism IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296] provides a stateless, transport-agnostic 1:1 translation between inside and outside prefixes. It is useful for address independence while preserving network layer reachability. A stable 1:1 prefix translation does not, by itself, provide the source unlinkability sought by CFR. If the same internal prefix is persistently mapped to the same external prefix, an upstream observer can still use that external prefix as a durable pseudonymous identifier. CFR therefore does not equate IPv6 source privacy with simply deploying NPTv6. 7.3. CFR options for IPv6 An IPv6 CFR could be implemented using one or more mechanisms, including: * stateful IPv6 source aliasing using a shared egress address pool; * short-lived selection from multiple egress prefixes; * tunneling to a CFR egress that assigns a source alias; or * another mechanism that produces equivalent source-unlinkability properties without exposing the subscriber's delegated prefix. This document does not select a single IPv6 translation architecture. Whatever mechanism is used, the privacy objective is that the address or prefix visible to the CFS is not a durable one-to-one representation of the subscriber's access prefix. 7.4. Desired IPv6 mapping properties A future CFR specification should consider at least: 1. *Prefix unlinkability:* the CFS-visible prefix should not directly encode or persistently mirror the subscriber's delegated prefix. Scalone Expires 4 March 2027 [Page 13] Internet-Draft CFR Source Privacy August 2026 2. *Address-pool sharing:* multiple subscribers should use the same CFR egress address or prefix space over time. 3. *Flow stability:* an established TCP or QUIC flow should not have its source changed merely because a privacy epoch expires. 4. *Rotation for new flows:* new connections may receive a different source alias when compatible with transport and application behavior. 5. *No IID-only assumption:* changing only the interface identifier is not sufficient when the stable prefix remains a correlation key. 6. *Equivalent IPv4/IPv6 privacy goals:* dual-stack clients should not obtain substantially weaker source privacy merely because one address family is selected. 8. CFR Privacy Requirements The following requirements describe the intended design space. They are not a normative protocol specification. *R1 - Preserve destination confidentiality.* CFR operation must not require ECH disablement or access to the ClientHelloInner. *R2 - Preserve end-to-end encryption.* The CFR must not terminate the TLS or QUIC security association between client and server. *R3 - Reduce durable source linkability.* The source alias visible to the CFS should not become a long-lived subscriber identifier. *R4 - Preserve transport flow continuity.* Address and port changes should occur at safe flow boundaries unless the transport explicitly supports and validates migration. *R5 - Provide IPv4/IPv6 parity.* The privacy objective should be expressible for both address families even when the implementation mechanisms differ. *R6 - Create a meaningful anonymity set.* A source alias or egress pool should be shared among enough users and flows to make trivial one-to-one mapping difficult. *R7 - Minimize new visibility.* A CFR should not introduce application-layer inspection or destination classification as a prerequisite for source privacy. Scalone Expires 4 March 2027 [Page 14] Internet-Draft CFR Source Privacy August 2026 *R8 - Avoid becoming an open relay.* CFR use must be restricted to authorized users or access-network attachment. *R9 - Support operational accountability without universal profiling.* Operators may need mechanisms for abuse response, but such mechanisms should not require the upstream CFS to receive a stable subscriber identifier. 9. Discovery and Bootstrapping A CFR integrated into an access network may not need explicit end- host discovery if routing policy directs eligible traffic through it. Other deployments may require clients to learn that a CFR service is available or to select among CFR instances. Discovery of Designated Resolvers (DDR) [RFC9462] and Discovery of Network-designated Resolvers (DNR) [RFC9463] demonstrate mechanisms by which network-provided encrypted services can be discovered. They are DNS resolver discovery mechanisms and cannot be directly reused as a generic CFR discovery protocol without new specification work. Future work could consider DHCP, Router Advertisement, DNS, configuration profiles, or application-independent service-binding mechanisms. Any discovery mechanism must include a way to authenticate the CFR service and avoid redirection to an attacker- controlled relay. 10. Performance and Transport Considerations A CFR adds forwarding and source-mapping state and can therefore affect latency, state scale, and failure handling. Important questions include: * stateful versus stateless operation; * load balancing across CFR instances; * failover without exposing a stable fallback source; * TCP state lifetime; * UDP mapping lifetime; * QUIC connection migration and path validation; * multipath transports; Scalone Expires 4 March 2027 [Page 15] Internet-Draft CFR Source Privacy August 2026 * fragmentation and Path MTU Discovery; * ICMP and ICMPv6 handling; * asymmetric routing; * address and port pool exhaustion; and * interaction with access-network anti-spoofing controls. For QUIC in particular, a CFR should normally keep the source alias stable for an existing path. Rotating an alias in the middle of a connection can be interpreted as path migration and may trigger validation or anti-abuse logic. 11. Abuse Prevention and Accountability A CFR must not become a general-purpose unauthenticated relay. An access-provider deployment can restrict CFR use through the subscriber's existing network attachment. Other deployment models may require explicit authorization. CFR operation may complicate abuse response because the CFS no longer sees the subscriber's access address. This is an intentional privacy property and creates a design tension with attribution. Possible operational approaches include short-lived mapping records, rate-limiting at the CFR, aggregate abuse signaling, or privacy- preserving authorization mechanisms. The appropriate retention and legal policies are deployment-specific and outside the scope of this document. Any accountability mechanism should be evaluated against the risk of reconstructing a universal source-to-destination history. 12. Relationship to Existing Work 12.1. Encrypted ClientHello ECH [RFC9849] protects the ClientHelloInner from on-path observers and defines the client-facing server trust boundary. CFR does not modify ECH and does not attempt to hide information from the backend origin. It addresses the network source identifier visible at the ECH front door. Bootstrapping of ECH through DNS SVCB and HTTPS records is specified in [RFC9848]. Scalone Expires 4 March 2027 [Page 16] Internet-Draft CFR Source Privacy August 2026 12.2. Encrypted DNS Encrypted DNS can prevent local-path observers from learning the queried domain name. This strengthens the intended CFR visibility split because the access-side relay does not need to learn the inner destination in order to forward packets. CFR is not a DNS privacy mechanism and does not replace DoH, DoT, DoQ, DDR, or DNR. 12.3. IPv4 NAT and CGN NAT and CGN already provide address translation and, sometimes, address sharing. CFR builds on similar data-plane techniques but has a different objective: reducing durable source correlation at a concentrated upstream front door. 12.4. IPv6 privacy addressing IPv6 temporary addresses [RFC8981] reduce host-level address correlation. CFR additionally targets correlation through a stable network prefix or stable upstream source mapping. 12.5. ECH deployment considerations Operational deployment considerations for ECH are discussed in [I-D.campling-ech-deployment-considerations]. CFR addresses a different but complementary question: the source identifier visible to the ECH front door. 12.6. Proxy and relay systems Application or transport proxy systems can also hide a client's source address from the final destination. CFR explores a narrower access-network function that does not require application-layer proxy semantics and does not terminate the encrypted application session. 13. Security and Privacy Considerations CFR changes the distribution of metadata visibility and therefore introduces its own security and privacy risks. 13.1. Collusion If the CFR operator and the CFS exchange sufficiently detailed per- flow records, the intended visibility split can be reconstructed. Scalone Expires 4 March 2027 [Page 17] Internet-Draft CFR Source Privacy August 2026 CFR therefore does not provide protection against collusion between all parties in the path. 13.2. Timing correlation Even when source aliases change, a sufficiently capable observer may correlate flows using timing, packet sizes, recurrence, or other traffic-analysis signals. CFR is intended to reduce a strong explicit identifier. It is not a complete traffic-analysis defense. 13.3. Small anonymity sets A source alias used by only one subscriber, or by very few subscribers, can provide little privacy benefit. Implementations should measure effective pool occupancy and should not assume that translation alone creates anonymity. 13.4. Stable alias assignment A deterministic long-lived subscriber-to-alias mapping defeats a central CFR privacy objective even if the alias differs from the subscriber's real address. This risk applies to both IPv4 external-address affinity and IPv6 stable prefix translation. 13.5. State exhaustion and denial of service Stateful CFRs can be attacked through connection or mapping exhaustion. Existing NAT and relay operational experience is relevant, but privacy-driven rotation can increase state-management complexity. 13.6. Open-relay abuse An improperly authenticated CFR could be used to conceal attack sources or amplify traffic. Deployments must restrict who can originate traffic through the CFR and should apply ordinary anti- spoofing and abuse controls. Scalone Expires 4 March 2027 [Page 18] Internet-Draft CFR Source Privacy August 2026 13.7. Identity joins outside the network layer CFR cannot prevent a user from directly identifying themselves to an application, identity provider, analytics system, or other service. It can reduce the ability to use the network source address as a universal join key, but application-level identifiers remain outside its scope. 13.8. Operational drift A CFR is intentionally narrow. Adding TLS termination, content inspection, classification, or persistent cross-destination subscriber identifiers would change the privacy model and should be treated as a different architecture. 14. IETF Standardization Questions Further work is required before CFR can be specified as an interoperable protocol or behavior. Open questions include: * how to define measurable source-unlinkability targets; * how large a shared egress pool must be to provide useful privacy; * how to define privacy epochs without breaking applications; * whether IPv4 and IPv6 require separate mapping profiles; * how to discover and authenticate optional CFR services; * how to support QUIC migration and multipath transports; * how to handle abuse response without restoring a globally visible subscriber identifier; * how to measure the privacy impact of existing CGN behavior; * how to model CFS provider-family concentration rather than ASN concentration alone; and * how to test whether source aliases remain linkable through auxiliary signals. DISPATCH, PEARG, MASQUE, INTAREA, and transport-related working groups may contain expertise relevant to different parts of this problem. This document does not assume a particular final venue. Scalone Expires 4 March 2027 [Page 19] Internet-Draft CFR Source Privacy August 2026 15. IANA Considerations This document makes no IANA requests. 16. Informative References [I-D.campling-ech-deployment-considerations] Campling, A., Vixie, P. A., Wright, D., Taddei, A., and S. Edwards, "Encrypted Client Hello Deployment Considerations", Work in Progress, Internet-Draft, draft- campling-ech-deployment-considerations-12, 6 July 2026, . [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, . [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, DOI 10.17487/RFC5382, October 2008, . [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, . [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, . [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, . [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, . [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, S., and K. Naito, "Updates to Network Address Translation (NAT) Behavioral Requirements", BCP 127, RFC 7857, DOI 10.17487/RFC7857, April 2016, . Scalone Expires 4 March 2027 [Page 20] Internet-Draft CFR Source Privacy August 2026 [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, . [RFC9462] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. Jensen, "Discovery of Designated Resolvers", RFC 9462, DOI 10.17487/RFC9462, November 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, . [RFC9848] Schwartz, B., Bishop, M., and E. Nygren, "Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings", RFC 9848, DOI 10.17487/RFC9848, March 2026, . [RFC9849] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849, March 2026, . Appendix A. Changes from -01 to -02 * Updated ECH references to RFC 9849 and ECH DNS bootstrapping to RFC 9848. * Reframed CFR around the ECH client-facing server trust boundary. * Added the distinction between general linkability and privileged CFS linkability. * Added 2026 one-million-domain and active-ECH concentration measurements. * Added a profiling and identity-join threat model. * Corrected the CFR privacy model to distinguish the front-door network destination from the ECH-protected inner destination. * Expanded IPv4 NAT/CGN analysis and explained why address sharing alone does not guarantee unlinkability. Scalone Expires 4 March 2027 [Page 21] Internet-Draft CFR Source Privacy August 2026 * Added IPv6 temporary-address, prefix-linkability, and NPTv6 analysis. * Added candidate source-mapping privacy requirements for IPv4 and IPv6. * Clarified that DDR and DNR are precedents for network service discovery, not directly reusable CFR discovery protocols. * Expanded transport, abuse, accountability, and security considerations. Acknowledgments The author acknowledges the helpful input and discussions from Andrew Campling, Arnaud Taddei, Kevin Smith, Lee Wilman, Tom Newton, colleagues within Vodafone Group, and participants in DINRG, PEARG, and DISPATCH. Author's Address Gianpaolo Angelo Scalone Vodafone Email: gianpaolo-angelo.scalone@vodafone.com Scalone Expires 4 March 2027 [Page 22]