RFC 7422

Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments

📅 published December 2014, from ietf

Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments 🎀

Okay bestie, so this is RFC 7422 💖, and it's an Independent Submission (meaning it came in through the independent stream, not from an IETF working group). Its category is Informational, so it's not a Standards Track spec, and it was published in December 2014 under ISSN 2070-1721 ✨. Five people wrote it: C. Donley, V. Sarawat, K. Sundaresan and O. Vautrin, who are all from CableLabs (Donley, Sarawat and Sundaresan) or Juniper Networks (Vautrin), plus C. Grundemann from the Internet Society 🧚. Also, its title block doesn't list anything it obsoletes or updates, so it's not replacing or patching any other RFC 🌸.

Abstract ✨

Okay so this is the main idea 💅. Sometimes Service Providers (SPs) have a legal logging requirement to map a subscriber's inside address to the address they use on the public Internet, like for abuse response 🚨. The problem is that a lot of logging solutions for Carrier-Grade NATs (CGNs) need active logging of every dynamic translation 😩. CGN port assignments are often per connection, but they could optionally use port ranges instead 🦋. Research shows per-connection logging doesn't scale well in lots of residential broadband services 💀.

So this doc suggests a way to manage CGN translations that significantly reduces how much logging you need, while still giving you traceability for abuse response 🔥. IPv6 is, of course, the preferred solution 👑. But while deployment is still in progress, SPs are forced by business imperatives to keep supporting IPv4 🙈. This note is all about the IPv4 part of the network when a CGN solution is in use 🍓.

Status of This Memo 📜

This document is not an Internet Standards Track specification. It's published for informational purposes, so no pressure 🌈.

It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741 💜.

You can find info about the current status of this document, any errata, and how to give feedback at http://www.rfc-editor.org/info/rfc7422 ✨.

Copyright Notice ©️

Copyright (c) 2014 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 (http://trustee.ietf.org/license-info) as they were in effect on the date of publication. Please actually read these carefully, because they describe your rights and restrictions for this document 🫶.

Table of Contents 🗂️

   1. Introduction ....................................................2
      1.1. Requirements Language ......................................4
   2. Deterministic Port Ranges .......................................4
      2.1. IPv4 Port Utilization Efficiency ...........................7
      2.2. Planning and Dimensioning ..................................7
      2.3. Deterministic CGN Example ..................................8
   3. Additional Logging Considerations ...............................9
      3.1. Failover Considerations ...................................10
   4. Impact on the IPv6 Transition ..................................10
   5. Privacy Considerations .........................................11
   6. Security Considerations ........................................11
   7. References .....................................................11
      7.1. Normative References ......................................11
      7.2. Informative References ....................................12
   Acknowledgements ..................................................13
   Authors' Addresses ................................................14

1. Introduction ✨

Okay, so it's getting harder and harder to snag new IPv4 address assignments from Regional/Local Internet Registries 😭. The unallocated IPv4 address space is running low, and new subscribers, devices and service types keep showing up and wanting connectivity 📱. So some operators are literally going to be forced to share one public IPv4 address among multiple subscribers, using stuff like Carrier-Grade NAT (CGN) [RFC6264] (for example NAT444 [NAT444], Dual-Stack Lite (DS-Lite) [RFC6333], NAT64 [RFC6146], and so on) 🧚.

But here's the tea ☕: address sharing creates extra problems for operators when they're handling service entitlement, public safety requests, or attack/abuse/fraud reports [RFC6269] 🚨. To identify a specific user tied to an IP address for one of these requests or for service entitlement, an operator needs to map a subscriber's internal source IP address and source port to the global public IP address and source port that the CGN gave them, for every connection the user starts 😩💅.

CGN connection logging does cover the need to identify attackers and respond to abuse and public safety requests, but it creates some big operational challenges for operators 💀. In lab testing, we observed CGN log messages at about 150 bytes long for NAT444 [NAT444] and 175 bytes for DS-Lite [RFC6333] (individual log messages vary a little in size) 🔍. We aren't aware of definitive studies on connection rates per subscriber, but reports from several operators in the US put the average at about 33,000 connections per household per day 🌸. If each connection gets logged individually, that works out to roughly 5 MB per subscriber per day, or about 150 MB per subscriber per month. Specific data volumes can vary across operators based on a bunch of different factors, though 🌈. Based on the available data, a 1-million-subscriber SP will generate about 150 terabytes of log data per month, or 1.8 petabytes per year 😱. Also, many SPs compress their log data after collecting it, and compression factors of 2:1 or 3:1 are common 🗜️.

Log volume is a problem for both operators and the public safety community 🫠. On the operator side, implementing CGN takes a huge infrastructure investment. It also requires updated operational practices to keep the logging infrastructure running, and it needs about 23 Mbps of bandwidth between the CGN devices and the logging infrastructure per 50,000 users 📉. On the public safety side, it makes it take longer for an operator to search the logs when there's an abuse report, and that could delay investigations ⏳. So an international group of operators and public safety officials came to the authors asking for a way to reduce this impact while improving abuse response 🙌.

Logging volume for CGN can be reduced by assigning port ranges instead of individual ports 🎀. With this method, only the assignment of a new port range gets logged, which may massively reduce logging volume 🔥. How much the logs shrink depends on the length of the assigned port range, whether the port range is static or dynamic, and so on 🦋. This has already been acknowledged in [RFC6269], which recommends logging source ports at the server and/or destination logging at the CGN, and in [NAT-LOGGING], which describes the information to be logged at a NAT 📚.

Still, the existing solutions have an impact on operators and public safety officials when it comes to logging and searching 😮‍💨. So instead, CGNs could be designed and/or configured to deterministically map internal addresses to {external address + port range} in a way that lets you algorithmically calculate the mapping 🧮. Then only the inputs and configuration of the algorithm need to be logged 🧠. This approach reduces both logging volume and subscriber identification times ⚡. In some cases, when full deterministic allocation is used, this approach can eliminate the need for translation logging altogether 👑.

This document describes a method for that kind of CGN address mapping, combined with block port reservations. It significantly reduces the burden on operators while still letting you map a subscriber's inside IP address to an outside address and external port number observed on the Internet 💖.

Also, activating the proposed port range allocation scheme is compliant with BEHAVE requirements, such as support for Application-specific functions (APP) 🧚‍♀️.

1.1. Requirements Language 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🫶.

2. Deterministic Port Ranges 🎀

okay so bestie, subscribers do thousands of connections a day, but at any given moment most of them are only using a tiny slice of resources 💅. When the compression ratio is low (see Appendix B of RFC 6269 [RFC6269]), like the ratio of subscribers to public IPv4 addresses on a CGN being closer to 10:1 than 1000:1, each subscriber can expect to reach thousands of TCP/UDP ports at any moment ✨. So instead of logging every single connection, CGNs can deterministically map customer private addresses (received on the customer-facing interface of the CGN, a.k.a. the internal side) to public addresses extended with port ranges (used on the Internet-facing interface of the CGN, a.k.a. the external side) 🦋. The lowkey genius part is that an operator can figure out a subscriber's internal IP address just from the public side IP and port number, no digging through CGN translation logs needed 🙈. That means the operator never has to haul around and store massive piles of session data and then crunch it just to find out who a subscriber is 😭.

The algorithmic mapping can be expressed as:

(External IP Address, Port Range) = function 1 (Internal IP Address)

Internal IP Address = function 2 (External IP Address, Port Number)

The CGN SHOULD provide a method for administrators to test both mapping functions (e.g., enter an External IP Address + Port Number and receive the corresponding Internal IP Address) 🧚.

Deterministic Port Range allocation needs the following variables configured 👑:

  • Inside IPv4/IPv6 address range (I);
  • Outside IPv4 address range (O);
  • Compression ratio (e.g., inside IP addresses I / outside IP addresses O) (C);
  • Dynamic address pool factor (D), to be added to the compression ratio in order to create an overflow address pool;
  • Maximum ports per user (M);
  • Address assignment algorithm (A) (see below); and
  • Reserved TCP/UDP port list (R)

Note: The inside address range (I) will be an IPv4 range in NAT444 operation (NAT444 [NAT444]) and an IPv6 range in DS-Lite operation (DS-Lite [RFC6333]) 🍓.

A subscriber is identified by an internal IPv4 address (e.g., NAT44) or an IPv6 prefix (e.g., DS-Lite or NAT64) 💜.

The algorithm may be generalized to L2-aware NAT [L2NAT], but this requires configuring the Internal interface identifiers (e.g., Media Access Control (MAC) addresses) 🌸.

The algorithm is not designed to retrieve an internal host among those sharing the same internal IP address. For example, in a DS-Lite context, only an IPv6 address/prefix can be retrieved using the algorithm, while the internal IPv4 address used for the encapsulated IPv4 datagram is lost 🙈.

Several address-assignment algorithms are possible. Using predefined algorithms, like the ones that follow, simplifies the process of reversing the algorithm when needed 🔥. However, the CGN MAY support additional algorithms. Also, the CGN is not required to support all of the algorithms described below. Subscribers could be restricted to ports from a single IPv4 address or could be allocated ports across all addresses in a pool, for example 🌈. The following algorithms and corresponding values of A are as follows:

  • 0: Sequential (e.g., the first block goes to address 1, the second block to address 2, etc.).
  • 1: Staggered (e.g., for every n between 0 and ((65536-R)/(C+D))-1, address 1 receives ports n*C+R, address 2 receives ports (1+n)*C+R, etc.).
  • 2: Round robin (e.g., the subscriber receives the same port number across a pool of external IP addresses. If the subscriber is to be assigned more ports than there are in the external IP pool, the subscriber receives the next highest port across the IP pool, and so on. Thus, if there are 10 IP addresses in a pool and a subscriber is assigned 1000 ports, the subscriber would receive a range such as ports 2000-2099 across all 10 external IP addresses).
  • 3: Interlaced horizontally (e.g., each address receives every Cth port spread across a pool of external IP addresses).
  • 4: Cryptographically random port assignment (Section 2.2 of RFC6431 [RFC6431]). If this algorithm is used, the SP needs to retain the keying material and specific cryptographic function to support reversibility 🔐.
  • 5: Vendor-specific. Other vendor-specific algorithms may also be supported 💅.

The assigned range of ports MAY also be used when translating ICMP requests (when rewriting the Identifier field) ✨.

The CGN then reserves ports as follows:

  1. The CGN removes reserved ports (R) from the port candidate list (e.g., 0-1023 for TCP and UDP). At a minimum, the CGN SHOULD remove system ports [RFC6335] from the port candidate list reserved for deterministic assignment 🛡️.
  2. The CGN calculates the total compression ratio (C+D), and allocates 1/(C+D) of the available ports to each internal IP address. Specific port allocation is determined by the algorithm (A) configured on the CGN. Any remaining ports are allocated to the dynamic pool.

Note: Setting D to 0 disables the dynamic pool. This option eliminates the need for per-subscriber logging at the expense of limiting the number of concurrent connections that 'power users' can initiate 🙃.

  1. When a subscriber initiates a connection, the CGN creates a translation mapping between the subscriber's inside local IP address/port and the CGN outside global IP address/port. The CGN MUST use one of the ports allocated in step 2 for the translation as long as such ports are available. The CGN SHOULD allocate ports randomly within the port range assigned by the deterministic algorithm. This is to increase subscriber privacy 🥹. The CGN MUST use the pre-allocated port range from step 2 for Port Control Protocol (PCP, [RFC6887]) reservations as long as such ports are available. While the CGN maintains its mapping table, it need not generate a log entry for translation mappings created in this step 📝.
  2. If D>0, the CGN will have a pool of ports left for dynamic assignment. If a subscriber uses more than the range of ports allocated in step 2 (but fewer than the configured maximum ports M), the CGN assigns a block of ports from the dynamic assignment range for such a connection or for PCP reservations. The CGN MUST log dynamically assigned port blocks to facilitate subscriber-to-address mapping. The CGN SHOULD manage dynamic ports as described in [LOG-REDUCTION] 🔍.
  3. Configuration of reserved ports (e.g., system ports) is left to operator configuration ⚙️.

Thus, the CGN will maintain translation mapping information for all connections within its internal translation tables. However, it only needs to externally log translations for dynamically assigned ports 🫶.

2.1. IPv4 Port Utilization Efficiency 📊

For SPs requiring an aggressive address-sharing ratio, the use of the algorithmic mapping may impact the efficiency of the address sharing. In those cases, a dynamic port range allocation assignment is more suitable 💖.

2.2. Planning and Dimensioning 🧮

Unlike dynamic approaches, the use of the algorithmic mapping requires more effort from operational teams to tweak the algorithm (e.g., size of the port range, address sharing ratio, etc.). Dedicated alarms SHOULD be configured when some port utilization thresholds are fired so that the configuration can be refined 🚨.

The use of algorithmic mapping also affects geolocation. Changes to the inside and outside address ranges (e.g., due to growth, address allocation planning, etc.) would require external geolocation providers to recalibrate their mappings 🌍.

2.3. Deterministic CGN Example ✨

okay bestie, let's walk through a real example 💅 The operator sets an inside address range (I) of 198.51.100.0/28 [RFC6598] and an outside address (O) of 192.0.2.1. The dynamic address pool factor (D) is set to 2, so the total compression ratio is 1:(14+2) = 1:16 🧮. Only the system ports (e.g., ports < 1024) are reserved (R) 🔒. This setup makes the CGN pre-allocate ((65536-1024)/16 =) 4032 TCP and 4032 UDP ports per inside IPv4 address 🎀. For this example, let's assume they get handed out in order, so 198.51.100.1 maps to 192.0.2.1 ports 1024-5055, 198.51.100.2 maps to 192.0.2.1 ports 5056-9087, and so on 🦋. The dynamic port range ends up as 57472-65535, and the table below shows the whole layout. Last but not least, the maximum ports/subscriber is set to 5040 💖.

+-----------------------+------------------------+
| Inside Address / Pool | Outside Address & Port |
+-----------------------+------------------------+
| Reserved              | 192.0.2.1:0-1023       |
| 198.51.100.1          | 192.0.2.1:1024-5055    |
| 198.51.100.2          | 192.0.2.1:5056-9087    |
| 198.51.100.3          | 192.0.2.1:9088-13119   |
| 198.51.100.4          | 192.0.2.1:13120-17151  |
| 198.51.100.5          | 192.0.2.1:17152-21183  |
| 198.51.100.6          | 192.0.2.1:21184-25215  |
| 198.51.100.7          | 192.0.2.1:25216-29247  |
| 198.51.100.8          | 192.0.2.1:29248-33279  |
| 198.51.100.9          | 192.0.2.1:33280-37311  |
| 198.51.100.10         | 192.0.2.1:37312-41343  |
| 198.51.100.11         | 192.0.2.1:41344-45375  |
| 198.51.100.12         | 192.0.2.1:45376-49407  |
| 198.51.100.13         | 192.0.2.1:49408-53439  |
| 198.51.100.14         | 192.0.2.1:53440-57471  |
| Dynamic               | 192.0.2.1:57472-65535  |
+-----------------------+------------------------+

So subscriber 1 on 198.51.100.1 opens a low volume of connections (e.g., < 4032 concurrent connections) 🌸. The CGN maps the outgoing source address/port into that pre-allocated range, and these translation mappings are not logged 🙈.

Now subscriber 2 is the busy one 💀. They're concurrently using more than the allocated 4032 ports (e.g., for peer-to-peer, mapping, video streaming, or other connection-intensive traffic types), so the CGN gives them up to an additional 1008 ports through bulk port reservations 🔥. In this example, subscriber 2 uses outside ports 5056-9087, and then 100-port blocks between 58000-58999. Connections on ports 5056-9087 are not logged, but 10 log entries get created for ports 58000-58099, 58100-58199, 58200-58299, ..., 58900-58999 📝.

Here's why this matters 👑. To figure out which subscriber is behind a CGN (no matter which port allocation method was used), public safety agencies need to collect source address and port information from content provider log files. So content providers are advised to log source address, source port, and timestamp for all log entries, per [RFC6302] 🫶. Say a public safety agency grabs that info and reports abuse from 192.0.2.1, port 2001. The operator can reverse the mapping algorithm and see that the internal IP address of subscriber 1 generated the traffic, without even checking CGN logs, by matching the internal IP address against DHCP/PPP lease connection records 🕵️‍♀️. If a second abuse report comes in for 192.0.2.1, port 58204, the operator will notice that port 58204 sits inside the dynamic pool range, dig into the log file, match it with connection records, and conclude that subscriber 2 generated the traffic. This assumes the public safety timestamp matches the operator timestamp. As noted in RFC 6292 [RFC6292], accurate timekeeping (e.g., use of NTP or Simple NTP) is vital ⏰ and honestly, it's non-negotiable.

In this example, the majority of subscribers only use pre-allocated ports, so there are no log entries for them ✨. Only the few subscribers who go past their pre-allocated ports and grab extra bulk assignments from the dynamic pool need any logging at all, and that logging includes the inside address, outside address, outside port range, and timestamp 💜.

One more thing 🍓: in a production environment, operators are encouraged to consider [RFC6598] for assigning inside addresses.

3. Additional Logging Considerations 📚

To identify a subscriber from an observed external IPv4 address, port, and timestamp, an operator needs to know how the CGN was configured at any given time 🧠. That means knowing the internal and external IP addresses, dynamic address pool factor, maximum ports per user, and reserved port range. So the CGN MUST generate a record any time these variables change 🚨. The CGN SHOULD generate a log message any time these variables change too 🌈. The CGN MAY keep such a record as a router configuration file 🗂️. If the CGN doesn't generate a log message, it's up to the operator to keep version control of router config changes. Also, the CGN SHOULD generate such a log message once per day, so the relevant configuration is quick to find when an abuse notification shows up 🌸.

Such a log message MUST, at minimum, include the timestamp, inside prefix I, inside mask, outside prefix O, outside mask, D, M, A, and reserved port list R. For example:

[Wed Oct 11 14:32:52
2000]:198.51.100.0:28:192.0.2.0:32:2:5040:0:1-1023,5004,5060.

3.1. Failover Considerations 🔁

Because algorithmically assigned translations are deterministic, no extra logging is needed during failover, as long as inside address ranges are unique within a given failover domain 🦋. Even if traffic gets directed to a different CGN server, translations inside the deterministic port range (on either the primary or the secondary server) can be reversed algorithmically, as long as the algorithm is known 🧚. So if 198.51.100.1 port 3456 maps to 192.0.2.1 port 1000 on CGN 1, and to 198.51.100.1 port 1000 on Failover CGN 2, an operator can still identify the subscriber from the outside source address and port info 💅.

Similarly, assignments made from the dynamic overflow pool need to be logged as described above, whether the translations happen on the primary or the failover CGN 📝.

4. Impact on the IPv6 Transition 🌍

The solution in this document works for CGN transition technologies (e.g., NAT444, DS-Lite, and NAT64) 💖. As discussed in [RFC7021], the authors admit that native IPv6 will give subscribers a better experience than CGN 🫶. But plenty of Customer Premises Equipment (CPE) devices only support IPv4, and as of October 2014, only approximately 5.2% of the top 1 million websites were available over IPv6 😭. So Deterministic CGN should in no way be understood as making CGN a replacement for IPv6 service ✨. Until IPv6 content and devices are widely available, though, Deterministic CGN gives operators a way to respond quickly to public safety requests without needing excessive infrastructure, operations, and bandwidth for per-connection logging 🎀.

5. Privacy Considerations 🫣

The algorithm described above makes it easier for SPs and public safety officials to identify a subscriber's IP address through a CGN system 🕵️‍♀️. That's the same level of privacy users could expect if they were assigned a public IP address and their traffic wasn't translated. However, other actors on the Internet could use this algorithm to map multiple transactions to a single subscriber, especially if ports are distributed sequentially 👀. Traceability still holds, but subscriber privacy can go up by using one of the other values of the Address Assignment Algorithm (A). That way, interested parties would need to know more about the Service Provider's CGN configuration to tie multiple connections to a particular subscriber 🔐.

6. Security Considerations 🛡️

The security considerations for NAT operation across various protocols, as documented in, for example, RFC 4787 [RFC4787] and RFC 5382 [RFC5382], also apply to this document 💀.

Note that, except possibly for cryptographically based port allocations, attackers could reverse-engineer algorithmically derived port allocations. They could use that to target a specific subscriber, or to spoof traffic so it looks like a specific subscriber generated it 😱. But this is exactly the same level of security the subscriber would get without CGN. CGN is not intended to provide extra security by obscurity 🙅‍♀️.

7. References 📖

7.1. Normative References 💜

7.2. Informative References 📚

okay so this is the "good to know" pile, and it's still full of gems 🧚

  • [L2NAT] Miles, D. and M. Townsley, "Layer2-Aware NAT", Work in Progress, draft-miles-behave-l2nat-00, March 2009.
  • [LOG-REDUCTION] Tsou, T., Li, W., Taylor, T., and J. Huang, "Port Management To Reduce Logging In Large-Scale NATs", Work in Progress, draft-tsou-behave-natx4-log-reduction-04, July 2013.
  • [NAT-LOGGING] Sivakumar, S. and R. Penno, "IPFIX Information Elements for logging NAT Events", Work in Progress, draft-ietf-behave-ipfix-nat-logging-04, July 2014.
  • [NAT444] Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., and H. Ashida, "NAT444", Work in Progress, draft-shirasaki-nat444-06, July 2012.
  • [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>.
  • [RFC6292] Hoffman, P., "Requirements for a Working Group Charter Tool", RFC 6292, June 2011, <http://www.rfc-editor.org/info/rfc6292>.
  • [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011, <http://www.rfc-editor.org/info/rfc6302>.
  • [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011, <http://www.rfc-editor.org/info/rfc6333>.
  • [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.
  • [RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and T. Tsou, "Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP)", RFC 6431, November 2011, <http://www.rfc-editor.org/info/rfc6431>.
  • [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012, <http://www.rfc-editor.org/info/rfc6598>.
  • [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013, <http://www.rfc-editor.org/info/rfc6887>.
  • [RFC7021] Donley, C., Howard, L., Kuarsingh, V., Berg, J., and J. Doshi, "Assessing the Impact of Carrier-Grade NAT on Network Applications", RFC 7021, September 2013, <http://www.rfc-editor.org/info/rfc7021>.

Acknowledgements 🫶

huge thank-yous 💖 to the people who gave the authors suggestions and feedback: Bobby Flaim, Lee Howard, Wes George, Jean-Francois Tremblay, Mohammed Boucadair, Alain Durand, David Miles, Andy Anchev, Victor Kuarsingh, Miguel Cros Cecilia, Fred Baker, Brian Carpenter, and Reinaldo Penno. you all are literally the best 🌸

Authors' Addresses 🦋

Chris Donley
CableLabs
858 Coal Creek Cir
Louisville, CO  80027
United States

EMail: c.donley@cablelabs.com


Chris Grundemann
Internet Society
Denver, CO
United States

EMail: cgrundemann@gmail.com


Vikas Sarawat
CableLabs
858 Coal Creek Cir
Louisville, CO  80027
United States

EMail: v.sarawat@cablelabs.com


Karthik Sundaresan
CableLabs
858 Coal Creek Cir
Louisville, CO  80027
United States

EMail: k.sundaresan@cablelabs.com


Olivier Vautrin
Juniper Networks
1194 N Mathilda Avenue
Sunnyvale, CA  94089
United States

EMail: olivier@juniper.net
📦 where this page comes from