RFC 6269
Issues with IP Address Sharing
RFC 6269: Issues with IP Address Sharing 💖
okay so bestie, this is RFC 6269 🎀. It's an Informational doc (so it's published for info, not as an Internet Standard 🦋), and it came out in June 2011 with ISSN 2070-1721. The editor is M. Ford, Ed. from the Internet Society, and the co-authors are M. Boucadair and P. Levis from France Telecom, A. Durand from Juniper Networks, and P. Roberts from the Internet Society again 🧚. Its title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨.
Abstract
okay so the whole premise is that IANA and the RIRs are running out of IPv4 addresses 😭. service providers everywhere are lowkey panicking about how they'll keep giving IPv4 connectivity to subscribers when there aren't enough addresses to hand each one their own 🙈. people are now coming up with solutions based on sharing IPv4 addresses, and this doc is the group chat for the issues that every one of those sharing approaches runs into 💅. we're talking app breakage, extra headaches for monitoring the service, new security holes, and more 💀. the specific fixes for each solution are out of scope, so we're not diving into those here 🌸.
the only forever-fix for pressure on the public IPv4 pool is deploying IPv6 🫶. that's the one way to ease things without needing the sharing mechanisms that cause all this drama ✨.
Status of This Memo
this doc is not an Internet Standards Track spec. it's just published for info 🍓.
it's a product of the IETF, so it does represent the consensus of the IETF community 👑. it got public review and the IESG approved it for publication 💜. but not every IESG-approved doc is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🧐.
for the current status, any errata, or how to send feedback, go to http://www.rfc-editor.org/info/rfc6269 🦋.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 💖
this doc 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 on the publication date 📜. read these carefully because they spell out your rights and restrictions for this doc 🫶. any code components pulled out of this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Simplified BSD License says 🔥.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Shared Addressing Solutions . . . . . . . . . . . . . . . . . 4
3. Analysis of Issues as They Relate to First and Third
Parties . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Content Provider Example . . . . . . . . . . . . . . . . . . . 8
5. Port Allocation . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Outgoing Ports . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Incoming Ports . . . . . . . . . . . . . . . . . . . . . . 10
5.2.1. Port Negotiation . . . . . . . . . . . . . . . . . . . 11
5.2.2. Connection to a Well-Known Port Number . . . . . . . . 12
5.2.3. Port Discovery Mechanisms . . . . . . . . . . . . . . 12
6. Impact on Applications . . . . . . . . . . . . . . . . . . . . 12
7. Geo-location and Geo-proximity . . . . . . . . . . . . . . . . 14
8. Tracking Service Usage . . . . . . . . . . . . . . . . . . . . 15
9. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 16
12. Traceability . . . . . . . . . . . . . . . . . . . . . . . . . 17
13. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Abuse Logging and Penalty Boxes . . . . . . . . . . . . . 18
13.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 19
13.3. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.4. Port Randomization . . . . . . . . . . . . . . . . . . . . 19
13.5. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.6. Policing Forwarding Behavior . . . . . . . . . . . . . . . 20
14. Transport Issues . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Parallel Connections . . . . . . . . . . . . . . . . . . . 20
14.2. Serial Connections . . . . . . . . . . . . . . . . . . . . 20
14.3. TCP Control Block Sharing . . . . . . . . . . . . . . . . 21
15. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 21
16. Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . 21
17. IPv6 Transition Issues . . . . . . . . . . . . . . . . . . . . 21
18. Introduction of Single Points of Failure . . . . . . . . . . . 22
19. State Maintenance Reduces Battery Life . . . . . . . . . . . . 22
20. Support of Multicast . . . . . . . . . . . . . . . . . . . . . 22
21. Support of Mobile-IP . . . . . . . . . . . . . . . . . . . . . 22
22. Security Considerations . . . . . . . . . . . . . . . . . . . 23
23. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
24. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
25. Informative References . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Classes of Address Sharing Solution . . . . . . . . . 27
Appendix B. Address Space Multiplicative Factor . . . . . . . . . 271. Introduction ✨
okay so IANA finished handing out IPv4 addresses on February 3, 2011 [IPv4_Pool] 😭. the RIRs are expected to finish around a year later, though the exact date depends on the registry 🦋. this is why service providers everywhere are starting to panic about how they'll keep giving IPv4 connectivity to their subscribers when there aren't enough addresses for one per subscriber 💀. a bunch of solutions are popping up that rely on sharing IPv4 addresses 🌸. these solutions bring a whole pile of issues, and this memo collects the ones that show up for all address sharing approaches into one doc 🎀.
bestie, IPv6 is still the only forever-fix for pressure on the public IPv4 pool, without needing the sharing mechanisms that cause all these issues 💜. short term though, keeping IPv4 services growing while IPv4 runs out is going to need address sharing 🫠. and address sharing is going to cause problems for end-users, service providers, and third parties like law enforcement agencies and content providers 🙈. this memo is here to highlight those problems and give a quick rundown of each one 💅.
lowkey, more IPv6 deployment should take some weight off whatever address sharing solution you're running and make it cheaper to operate 🧚. more IPv6 should also mean fewer concurrent IPv4 sessions per subscriber 🌈. if end-to-end IPv6 traffic grows enough that IPv4 traffic starts shrinking, then the number of IPv4 sessions goes down too 🍓. fewer concurrent IPv4 sessions per subscriber means more subscribers can share the same IPv4 public address, which means fewer public IPv4 addresses needed overall ⭐. but here's the catch: this only helps subscribers who have both an IPv6 access and a shared IPv4 access 👑. so that's why the idea is to systematically tie a shared IPv4 access to an IPv6 access 🔥. it's hard to predict how much growing IPv6 traffic will cut down concurrent IPv4 sessions, but either way, IPv6 deployment and use should take pressure off the available public IPv4 address pool 🫶.
2. Shared Addressing Solutions ✨
okay so picture this 🦋 in a LOT of networks right now, a subscriber gets ONE public IPv4 address for their home or small business. for fixed broadband, that public IPv4 address is assigned to each CPE (Customer Premises Equipment) 🎀. the CPE has a NAT function baked in, and its whole job is translating private IPv4 addresses (the [RFC1918] kind) that are assigned to hosts on the local network, over to the public IPv4 address the service provider gave it (and back again, vice versa 💅). so all the devices on the LAN share that one public address, and they're all tied to one subscriber account and one network operator. simple, cozy, iconic 🌸
a bunch of proposals the IETF is currently looking at rely on multiplexing multiple subscribers' connections over a smaller number of shared IPv4 addresses. ngl this is a BIG change 😭 the proposals include Carrier Grade NAT (CGN a.k.a. LSN for Large Scale NAT) [LSN-REQS], Dual-Stack Lite [DS-Lite], NAT64 [RFC6145] [RFC6146], Address+Port (A+P) proposals [A+P] [PORT-RANGE], and Stateless Address Mapping [SAM]. Appendix A and Appendix B classify these different types of solutions and talk through the design considerations you should keep in mind when deploying large-scale address sharing 🧚 and honestly? whether we're talking DS-Lite, A+P, NAT64, or CGN isn't that important 💀 it's the view from the outside that matters, and given that, most of the issues below apply no matter which address sharing scenario you're in 🫶
so in these new proposals, a single public IPv4 address would be shared by multiple homes or small businesses (aka multiple subscribers), which means the operational paradigm above would no longer apply 🙈 this document calls this new paradigm large-scale address sharing. all of these proposals extend the address space by adding port information, they just differ in how they manage the port value 🍓
security issues with NAT have been documented for ages (see [RFC2663] and [RFC2993]) 🥹 but sharing IPv4 addresses across multiple subscribers, whether you move the NAT functionality from the home gateway into the core of the service provider network or restrict the port choice in the subscriber's NAT, creates NEW issues for subscribers, content providers, and network operators. a lot of these issues already show up today thanks to public Wi-Fi hotspot deployments. as large-scale address sharing gets more widespread because of IPv4 address depletion, these issues become more severe AND more commonly felt 😭 NAT issues in the past usually only affected a single legal entity, but as large-scale address sharing gets more common, these issues will increasingly span multiple legal entities at once 💜
all large-scale address sharing proposals share technical and operational issues, and they're covered in the sections that follow ✨ these issues are common to any service-provider NAT, enterprise NAT, and also non-NAT solutions that share individual IPv4 addresses across multiple subscribers. this document is meant to bring all of these issues together in one place 🎀
3. Analysis of Issues as They Relate to First and Third Parties 🌈
okay so this section looks at whether each issue in the rest of the document applies to the organization deploying the shared addressing mechanism (and by extension, their subscribers), and/or whether it hits third parties (like content providers, law enforcement agencies, etc.) 🕵️♀️ here, issues that affect end-users are counted as affecting first parties, because end-users will totally complain to their service provider when stuff breaks 😤 and if an issue can be foreseen and handled by the party deploying the shared addressing solution, it's not attributed to anyone 💅
in Figure 1, the 'xx' marks issues that are NEWLY created on top of what you'd expect from just introducing a traditional NAT device 🔥 issues marked with a single 'x' already exist today with typical CPE NAT, but they can be expected to get more severe and widespread with large-scale address sharing 😭
+------------------------------------------------+--------+---------+
| Issue | 1st | 3rd |
| | party | parties |
+------------------------------------------------+--------+---------+
| Restricted allocations of outgoing | x | |
| ports will impact performance for end-users | | |
| | | |
| Incoming port negotiation mechanisms may fail | xx | |
| | | |
| Incoming connections to Assigned Ports will | x | |
| not work | | |
| | | |
| Port discovery mechanisms will not work | x | |
| | | |
| Some applications will fail to operate | x | x |
| | | |
| Assumptions about parallel/serial connections | x | x |
| may fail | | |
| | | |
+------------------------------------------------+--------+---------+
+------------------------------------------------+--------+---------+
| Issue | 1st | 3rd |
| | party | parties |
+------------------------------------------------+--------+---------+
| TCP control block sharing will be affected | x | x |
| | | |
| Reverse DNS will be affected | x | x |
| | | |
| Inbound ICMP will fail in many cases | x | x |
| | | |
| Amplification of security issues will occur | xx | xx |
| | | |
| Fragmentation will require special handling | x | |
| | | |
| Single points of failure and increased | x | |
| network instability may occur | | |
| | | |
| Port randomization will be affected | x | |
| | | |
| Service usage monitoring and abuse logging | xx | xx |
| will be impacted for all elements in the chain | | |
| between service provider and content provider | | |
| | | |
| Penalty boxes will no longer work | xx | xx |
| | | |
| Spam blacklisting will be affected | xx | xx |
| | | |
| Geo-location services will be impacted | xx | xx |
| | | |
| Geo-proximity mechanisms will be impacted | xx | xx |
| | | |
| Load balancing algorithms may be impacted | | xx |
| | | |
| Authentication mechanisms may be impacted | | x |
| | | |
| Traceability of network usage and abusage will | | xx |
| be affected | | |
| | | |
| IPv6 transition mechanisms will be affected | xx | |
| | | |
| Frequent keep-alives will reduce battery life | x | |
| | | |
+------------------------------------------------+--------+---------+Figure 1: Shared addressing issues for first and third parties 🎀
ok so the big takeaway from Figure 1 is that large-scale address sharing creates almost as many problems for third parties as it does for the service provider deploying it 😳 several of these issues are specific to large-scale address sharing too. all of them get discussed in more detail below 🫶
4. Content Provider Example 🍓
okay so let's take a content provider as our third party example 💅 and focus on the issues that are created specifically by large-scale address sharing. these are the ones that are of particular concern 😭
- Degraded geo-location for targeted advertising and licensed content restrictions (see Section 7). 🌍
- Additional latency due to indirect routing and degraded geo-proximity (see Section 7). 🐢
- Exposure to new amplification attacks (see Section 13). 🚨
- Service usage monitoring is made more complicated (see Section 8). 📉
- Incoming port negotiation mechanisms may fail (see Section 5.2.1). 🙃
- IP blocking for abuse/spam will cause collateral damage (see Section 13). 💀
- Load balancing algorithms may be impacted (see Section 16). ⚖️
- Traceability of network usage and abuse will be impacted (see Section 12). 🕵️♀️
5. Port Allocation ✨
okay bestie, ports are where things get spicy 🌸 when we talk about port numbers, we have to split outgoing connections from incoming ones. for outgoing connections the actual source port usually doesn't matter 🦋 (that's still true today, but in a port-range solution the source port has to sit inside the allocated range, so it's not totally free 🙈). incoming connections are a whole different vibe, though, because the specific ports given to each subscriber matter. they're part of external referrals, which is how third parties find the services subscribers run 💅
how many subscribers can share one IPv4 address depends on two guesses: the average number of ports each active subscriber needs, and the average number of subscribers active at the same time 🧮 and here's the tea 🍓 clients really don't like reusing ports while they're in the TIME-WAIT state, which usually lasts about 4 minutes after a connection wraps up. why? TIME-WAIT keeps old duplicate segments from causing chaos on "fast" or "long" connections, where clock-driven Initial Sequence Number selection can't stop the old and new sequence spaces from overlapping. that waiting period gives every old duplicate segment enough time to die out in the Internet before the connection reopens [RFC1337]. so ports in this state must be included in your port-usage math, no skipping 💜
most of the time the source port a client app picks gets translated (unless the client's stack has direct knowledge of a port-range restriction) 🎀 that can happen in a NAT inside the subscriber's device, a CPE NAT, or a CPE NAT plus a CGN 🌈
[RFC1700] defined the Assigned Ports (both System and User), and it was later replaced by an online database, as described in [RFC3232] ✨ IANA has also sorted the whole port space into three categories, per [IANA_Ports] 👑
- The Well-Known Ports are those from 0 through 1023.
- The Registered Ports are those from 1024 through 49151.
- The Dynamic and/or Private Ports are those from 49152 through 65535.
[RFC4787] points out that NATs don't all follow this classification the same way 🙃 some NATs only translate to dynamic ports, some also include registered ports, and some keep the port if it's in the well-known range. [RFC4787] also makes it clear that using the 1024-65535 port space is safe: "mapping a source port to a source port that is already registered is unlikely to have any bad effects". 🔥 so for every address sharing solution, there's no reason to limit outgoing source ports to just a subset of 1024-65535 💖
5.1. Outgoing Ports
okay so the measurements show the average number of outgoing ports used by an active subscriber is much, much smaller than the max a subscriber can grab at any moment 😭 but the distribution is heavy-tailed, which means there are usually a few subscribers using a ton of ports [CGN_Viability] 💀 the result? an algorithm that hands out outgoing ports dynamically from a central pool usually lets more subscribers share one IPv4 address than one that statically splits the resource by pre-assigning a fixed number of ports to each subscriber 🦋 it's also better at handling the subscribers who want a relatively high number of ports ✨
ngl, the dynamic approach makes the service provider's life a lot harder when it comes to keeping records of who got which ports (see Section 12) 🙈 with static allocation there's 1 record per subscriber, but with dynamic allocation you get a much larger number of records, equal to the total number of outgoing ports that subscriber used during the period when detailed logs have to be kept 📚
here's a sneaky problem 😈 with dynamic allocation: one of the subscriber devices behind a port-shared IPv4 address gets infected with a worm, which then rapidly opens tons of outbound connections to spread itself 🦠 that infection could quickly drain the shared resource (the single IPv4 address) for every connected subscriber 😱 so it's necessary to put limits on the total number of ports one subscriber can use, to keep the shared resource (the IPv4 address) available to everyone 🫶 but heads up: static schemes for port assignment may bring security issues [RFC6056] when small contiguous port ranges are statically assigned to subscribers 🔒 another mitigation is to kill off (randomly) established connections when the port space runs out. the catch is that a user with lots of connections is proportionally more likely to get hit 💅
session failure from NAT state overflow or timeout (when the NAT throws away session state because it's run out of resources) can happen when the configured quota per user is reached, or when the NAT itself is out of resources 🥀
5.2. Incoming Ports
it's really desirable for incoming ports to stay stable over time 🌷 this is tricky though, because the network doesn't know anything in particular about the applications it's supporting. it has no real idea how long an application or service session is still going and needs its port to stay stable 🤷♀️
early measurements [CGN_Viability] also seem to suggest that, on average, subscribers only use very few ports for incoming connections 🍓 but a majority of subscribers accept at least one inbound connection 👑
so it's not necessary to pre-allocate a large number of incoming ports to each subscriber 🎀 you can either pre-allocate a small number of ports for incoming connections, or do port allocation on demand when the application that wants to receive a connection starts up ✨ the bulk of incoming ports can be kept as a centralized resource shared by all subscribers using a given public IPv4 address 🫶
5.2.1. Port Negotiation
in current deployments, a really important and widely used feature of many CPE devices is the ability to open incoming ports (port forwarding), either by hand or with a protocol like the Universal Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD] 🧚 if there's a CGN in the mix, the port also has to be opened in the CGN too 😩 which makes subscribers depend on their service provider for this functionality 💀
CPE and CGN will need to cooperate for port forwarding to work 🤝 a UPnP or NAT-PMP proxy could be a solution if there's a direct link (or tunnel) between the CPE and the CGN 🦋 another option is a web interface to configure the incoming port mapping on the CGN 💻 and protocol development is underway in the IETF to provide a generalized, automated solution through the Port Control Protocol [PCP] 🌈
heads up bestie: a web interface like that effectively makes public what used to be a private management interface, and that raises security concerns that must be addressed 🚨
for port-range solutions, port forwarding might still be available at the CPE, with one limit: the open incoming port must be within the allocated port range 🙃 (for instance, you can't open port 5002 for incoming connections if port 5002 isn't in the allocated port range) 🙅♀️
5.2.1.1. Universal Plug and Play (UPnP)
with UPnP, the application asks "I want to use port number X, is that OK?" and the answer is yes or no 🙋♀️ if the answer is no, the application will usually try the next port in sequence until it either finds one that works or gives up after a limited number of attempts 🥲 UPnP IGD 1.0 has no way to redirect the application to a different port number 😤 but UPnP IGD 2.0 levels up the situation and allows allocation of any available port 🎉
5.2.1.2. NAT Port Mapping Protocol (NAT-PMP)
NAT-PMP lets the NAT redirect the requesting application to a port that the NAT state mapping table considers available for use 🧚♀️✨
5.2.2. Connection to a Well-Known Port Number
once an IPv4-address sharing mechanism is in place, inbound connections to well-known port numbers won't work in the general case 😭 any application that isn't port-agile can't be expected to work either 💔 some workaround (e.g., redirects to a port-specific URI) could be deployed given sufficient incentives 🤞 there are several proposals for "application service location" protocols that would give a way to address this problem, but historically these proposals haven't gained much deployment traction 📉
for example, DNS SRV records [RFC2782] are a potential solution for subscribers who want to host services with a shared-addressing scheme 💖 SRV records let you specify a port value related to a service, which makes services reachable on ports other than the well-known ones 🎀 but it's worth noting that this mechanism isn't applicable to HTTP and many other protocols 🙈
5.2.3. Port Discovery Mechanisms
port discovery, where a UDP port is used to discover a service on a corresponding TCP port (via broadcast, multicast, or unicast), is a commonly deployed mechanism 🛰️ but unsolicited inbound UDP gets dropped by address sharing mechanisms, since they have no live mapping to forward the packet to the right host 🚫 so address sharing breaks this service discovery technique 💔
6. Impact on Applications 💅
okay so address sharing is gonna hit different kinds of apps in different ways, and you need to know which ones 👀
- Applications that establish inbound communications - these apps have to make sure the ports they pick for incoming traffic are either inside the allocated range (for port-range solutions) or get forwarded properly by the CGN (for CGN-based solutions). See Section 5.2 for more discussion. 📬
- Applications that carry address and/or port information in their payload - when the address sharing solution translates port and/or address info at the IP and transport layers, an ALG will also be required to make sure the application-layer data gets modified correctly. ngl this one is a lot. ALGs are required in some cases, but in many other cases end-to-end protocol mechanisms have been developed to work around a lack of ALGs in address translators, to the point where it's preferable to avoid any support in the NAT. 🙈
- Applications that use fixed ports - see Section 5.2.2 for more discussion. 📌
- Applications that do not use any port (e.g., ICMP echo) - these apps will need special handling, so check out Section 9 for more discussion. 🧚
- Applications that assume the uniqueness of source addresses (e.g., IP address as identifier) - these will fail to work properly when there are multiple, discrete, simultaneous connections coming from the same source IP address. bestie, that's a whole vibe check 💀
- Applications that explicitly prohibit concurrent connections from the same address - these will fail when multiple subscribers sharing an IP address try to use them at the same time. not it 🙅♀️
- Applications that do not use TCP or UDP for transport - every IP address sharing mechanism proposed so far is limited to TCP, UDP, and ICMP, which means end-users can't fully use the Internet. That's giving a lot of missing protocols: SCTP, DCCP, RSVP, protocol 41 (IPv6-over-IPv4), and protocol 50 (IPsec ESP) 😭
Apps already come up with tricks to get around NATs (usually CPE NATs), and they're honestly iconic for it:
- Application Layer Gateways (ALGs): a lot of CPE devices today have ALGs built in so apps can behave correctly even with a NAT on the CPE. When the NAT belongs to the subscriber, the subscriber gets to tailor the device to what they need, which is so main character of them. For CGNs, subscribers will depend on whatever set of ALGs their service provider makes available. For port-range solutions, ALGs will need changes to deal with the port-range restriction, but otherwise they'll have the same capabilities as today. Again, ALGs are required in some cases, and in many other cases end-to-end protocol mechanisms have been developed to work around a lack of ALGs, to the point where it's preferable to avoid any support in the NAT. 🫶
- NAT Traversal Techniques: there are several commonly deployed mechanisms that let you run servers behind a NAT by forwarding specific TCP or UDP ports to specific internal hosts ([UPnP-IGD], [NAT-PMP], and manual configuration). All of these assume the NAT's WAN address is a publicly routable IP address, so they fail to work normally when that assumption is wrong. 🥲 Some people have tried to dodge that problem by automatically disabling the NAT function and bridging traffic instead as soon as a private IP address gets assigned to the WAN interface (which is required for [Windows-Logo] certification). But bridging (instead of NATting) has its own side effects, like DHCP requests being served by an upstream DHCP server, which can make in-home networking way more complicated. 🌀
7. Geo-location and Geo-proximity 📍
okay so IP addresses get used to guess where a host is physically located, and they can tell you that with some level of granularity and some level of confidence. Honestly it's a heuristic at best, and other stuff like tunnels already makes it kinda sus. 🫠 Content providers use geo-location to follow regional content licensing rules, to target ads at specific areas, or to serve customized content. Geo-location is also necessary for emergency services. ✨
Here's the catch: in some deployment contexts (e.g., centralized CGN), shared addressing will lower the confidence and the location granularity that IP-based geo-location can give you. From the content provider's side, a subscriber behind a CGN geo-locates to wherever the CGN's prefix appears to be, and very often that's in a totally different city from the subscriber. 🏙️💀
IP addresses are also used as input to geo-location services that resolve an IP address to a physical location using info from the network infrastructure. Current systems rely on stuff like RADIUS databases and DHCP lease tables. Address sharing will stop these systems from resolving a host's location based on IP address alone. Users of these systems will need to give more info (e.g., TCP or UDP port numbers), and the systems will need to use that info to query extra network resources (e.g., Network Address Translation - Protocol Translation (NAT-PT) binding tables). These new data elements tend to be more ephemeral than the ones used for geo-location today, so geo-location systems may need to cache them for some period of time. 🗂️
Other forms of geo-location will still work as usual. 🎉
A slightly different use of an IP address is to calculate how close a connecting host is to a particular service delivery point. This affects how efficiently content gets delivered to an end-user. If a CGN is introduced in communications and it's far away from the end-user connected to it, application performance may take a hit insofar as IP-based geo-proximity is a factor. 🐢
8. Tracking Service Usage 📊
as large-scale address sharing becomes more common, counting unique users of a service is gonna get way more complicated than just counting connections from unique IP addresses. Even though that's already kind of inexact today because of how widespread CPE NAT is, it'll become a much less useful approach once large-scale address sharing solutions are everywhere. 😩 In general, every element that monitors usage (or abusage) in the chain between a service provider that has deployed address sharing and a content provider will need an upgrade so it takes the port value into account, not just the IP addresses. 🔧
9. ICMP 🛰️
ICMP doesn't have a port field, so it's kinda problematic for address sharing mechanisms. Some ICMP message types include a fragment of the datagram that triggered the signal, and that fragment is assumed to include port numbers. For some ICMP message types, the Identifier field has to be used as a de-multiplexing token. Sourcing ICMP echo messages from hosts behind an address sharing solution is fine, but responses to outgoing ICMP echo messages will need special handling, like using the ICMP Identifier value to route the response to the right place. 🧠
For inbound ICMP there are two cases, and they're different vibes. 👯♀️
The first case is ICMP sourced from outside the network of the address sharing solution provider. When ICMP messages include a fragment of an outgoing packet with port numbers, it may be possible to forward the packet properly. But on top of these network signaling messages, several applications (e.g., peer-to-peer applications) use ICMP echo messages that have no hints that could be used to route the packet correctly. So measurements those apps derive in the presence of an address sharing solution will be erroneous or fail altogether. 😵💫
The second case is ICMP sourced from within the network of the address sharing solution provider (e.g., for network management, signaling, and diagnostic purposes). Here, ICMP can be routed normally for CGN-based solutions, because each CPE device has a locally unique private IP address. For port-range solutions, ICMP echo messages won't be routable without special handling, e.g., putting a port number in the ICMP Identifier field and having port-range routers make routing decisions based on that field. 🍓
Considerations related to ICMP message handling in NAT-based environments are specified in [RFC5508]. 📚
10. MTU 📦
okay so when end hosts use path MTU Discovery [RFC1191] to optimize the size of the packets they send for the underlying network MTU, shared addressing brings a bunch of stuff to think about. As covered in Section 9, ICMP "Packet Too Big" messages must be properly translated through the address sharing solution in both directions. But even when that's done right, MTU can still be a concern. 🙃
Lots of end hosts cache info they got via Path MTU Discovery (PMTUD) for a certain period of time. If the MTU behind the address sharing solution is inconsistent, the public end host might have the wrong MTU value cached. That can make it send packets that are too large, which get dropped if the DF (Don't Fragment) bit is set, or get fragmented by the network, which increases load and overhead. 💥 And since the host will eventually drop its MTU to the lowest common value for all hosts behind a given public address, it may also send packets that are below the optimal size for that specific connection, which means more overhead and lower throughput. 🐌
This also creates a potential attack vector. 🚨 A malevolent user could send an ICMP "Packet Too Big" (Type 3, Code 4) message indicating a Next-Hop MTU of anything down to 68 octets. That value would get cached by the off-net server for every subscriber sharing the address of the malevolent user. This could lead to a denial of service (DoS) against both the remote server and the large-scale NAT device itself, since they'd both have to handle a lot more packets per second. 🫣
11. Fragmentation 🧩
when a packet gets fragmented, the transport-layer port information (either UDP or TCP) is only in the first fragment. The subsequent fragments won't carry the port info, so they'll need special handling. 🙈 On top of that, the IP Identifier may no longer be unique, which the receiver needs in order to put the fragments of a datagram back together. it's giving chaos, periodt 💅
12. Traceability ✨
okay so, a lot of countries say service providers have to hand over a subscriber's identity to the authorities when they ask 📜. Those requests have usually come with the source IPv4 address and the date (and usually the time), and honestly that was plenty back when subscribers kept the same IPv4 address for ages 🕰️.
BUT when one public IPv4 address is shared by several subscribers, that address doesn't point to one person anymore 😬. There are two solutions:
- The first solution is for servers to also log the source port of incoming connections, and for the legal request to include the source port. The request should include
[Source IP address, Source Port, Timestamp](and possibly other information). Accurate time-keeping (e.g., use of NTP or Simple NTP) is vital because port assignments are dynamic ⏰. In a densely populated CGN, even very small clock skew between a third party's server and the CGN operator can make it ambiguous which customer was using a specific port at a given time 🙈. - The second solution considers it unrealistic to expect all servers to log the source port number of incoming connections 🙅♀️. To deal with this, service providers using IPv4 address sharing may need to log IP destination addresses.
destination logging is kinda messy 🫠. If multiple subscribers are hitting the same popular server at nearly the same time, it can be impossible to figure out which subscriber accessed the server, especially with protocols that involve several connections (e.g., HTTP). So logging the destination address on the NAT is inferior to logging the source port at the server 💅.
If neither solution is used (so the server isn't logging source port numbers and the NAT isn't logging destination IP addresses), the service provider can't trace a particular activity to a specific subscriber 💀. In that case, the service provider would need to disclose the identity of all subscribers who had active sessions on the NAT during the time period in question. That could be a huge number of people 😱.
Address sharing solutions must record and store all mappings (typically during 6-12 months, depending on the local jurisdiction) that they create 📚. If we count one mapping per session, a service provider should record and retain traces of all sessions created by all subscribers during one year (if the legal storage duration is one year). That can be a lot to handle, between the volume of data needing storage, the volume of data to keep transferring to the storage location, and the volume of data to search when a query comes in 🥵.
Address sharing solutions can ease some of this by pre-allocating groups of ports 🎀. Then only the allocation of the group needs to be recorded, not the creation of every session binding within that group. There are trade-offs to juggle between the sizes of these port groups, the ratio of public addresses to subscribers, whether or not these groups time out, and the impact on logging requirements and port randomization security [RFC6056] ⚖️.
13. Security 🔐
Before we get into some specific security issues caused by large-scale address sharing, it's worth noting that, in general, address sharing creates a vector for attack amplification in numerous ways 🚨. See Section 10 for one example.
13.1. Abuse Logging and Penalty Boxes
When abuse gets reported today, it's usually phrased like this: IPv4 address X has done something bad at time T0 🙃. That isn't enough info to uniquely identify the subscriber responsible when that IPv4 address is shared by more than one subscriber. Law enforcement may be especially affected by this 👮♀️. This particular issue can be fixed by logging port numbers, although that will increase logging data storage requirements.
A bunch of services on the network today log the IPv4 source addresses used in connection attempts to protect themselves from certain attacks 🛡️. For example, if a server sees too many requests from the same IPv4 address in a short period of time, it may decide to put that address in a penalty box for a certain time, during which requests are denied. Or it may require completion of a CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) for future requests 🤖. If an IPv4 address is shared by multiple subscribers, this has unintended consequences in a couple of ways. First, it may become the natural behavior to see lots of login attempts from the same address, because it's now shared across a potentially huge number of subscribers 😵💫. Second, and more likely, one user who fails a bunch of login attempts may block out other users who haven't made any previous attempts but who will now fail on their very first try 😭. With widespread large-scale address sharing, penalty box solutions to service abuse simply will not work 🚫.
Also, there are web tie-ins into different blacklists that web admins subscribe to, so they can redirect users with infected machines (e.g., detect the presence of a worm) to a URL that says "Hey, your machine is infected!" 🦠. With address sharing, someone else's worm can get in the way of other subscribers sharing that same IP address accessing the service 😩.
13.2. Authentication
Simple address-based identification mechanisms that are used to populate access control lists will fail when an IP address is no longer enough to identify a particular subscriber 🔑. Including port numbers in access control list definitions may be possible, at the cost of extra complexity. It may also require the service provider to make static port assignments, which conflicts with the requirement for dynamic assignments discussed in Section 5.1 🙅♀️.
Address or DNS-name-based signatures (e.g., some X.509 signatures) may also be affected by address sharing, since the address itself is now a shared token, and the name-to-address mapping may not be current 📛.
13.3. Spam
Another case of identifying abusers has to do with spam blacklisting 📧. When a spammer is behind a CGN or using a port-shared address, blacklisting their IP address will restrict all the other subscribers sharing that address, at least to some extent, in their ability to send SMTP packets 😤.
13.4. Port Randomization
A blind attack that can be run against TCP relies on the attacker's ability to guess the 5-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked 🎯. [RFC6056] describes a number of methods for randomly selecting the source port number, so that the attacker's chance of correctly guessing the 5-tuple goes down. With shared IPv4 addresses, the port selection space shrinks 📉. Preserving port randomization is important, and it may be more or less difficult depending on the address sharing solution and the size of the port space being manipulated. Allocating non-contiguous port ranges could help mitigate this issue 🧩.
It should be noted that guessing the port information may not be enough to carry out a successful blind attack 🤏. An in-window TCP Sequence Number (SN) should also be known or guessed. A TCP segment is processed only if all previous segments have been received, except for some Reset segment implementations that immediately process the Reset as long as it's within the Window. If SN is randomly chosen, it will be difficult to guess (SN is 32 bits long). Port randomization is one protection among others against blind attacks 🛡️. There's a more detailed discussion of improving TCP's robustness to Blind In-Window Attacks in [RFC5961] 📖.
13.5. IPsec
The impact of large-scale IP address sharing on IPsec operation should be evaluated and assessed 🔍. [RFC3947] proposes a solution to the issues documented in [RFC3715]. [RFC5996] specifies Internet Key Exchange (IKE) Protocol Version 2, which includes NAT traversal mechanisms that are now widely used to get IPsec working in the presence of NATs in many cases 🙌. Still, service providers may wish to make sure that CGN deployments don't inadvertently block NAT traversal for security protocols such as IKE (refer to [NAT-SEC] for more information) 🧐.
13.6. Policing Forwarding Behavior
[RFC2827] motivates and discusses a simple, effective, and straightforward method for using ingress traffic filtering to block DoS attacks that use forged IP addresses 🚧. Following this recommendation, service providers operating shared-addressing mechanisms should ensure that source addresses (or source ports, in the case of port-range schemes) are set correctly in outgoing packets from their subscribers, or they should drop the packets 🫡.
If some form of IPv6 ingress filtering is deployed in the broadband network, and DS-Lite service is restricted to those subscribers, then tunnels terminating at the CGN and coming from registered subscriber IPv6 addresses can't be spoofed 🙌. So a simple access control list on the tunnel transport source address is all that's required to accept traffic on the internal interface of a CGN 🎀.
14. Transport Issues 🚚
14.1. Parallel Connections
One issue is systems that assume that multiple simultaneous connections to a single IP address mean connectivity to a single host. Those systems may experience unexpected results 🤯.
14.2. Serial Connections
Another issue is systems that assume that returning to a given IP address means returning to the same physical host, as with stateful transactions 🔁. This may also affect cookie-based systems 🍪.
14.3. TCP Control Block Sharing
[RFC2140] defines a performance optimization for TCP based on sharing state between TCP control blocks that pertain to connections to the same host, instead of maintaining state for each discrete connection ⚡. This optimization assumes that an address says something about the properties of the path between two hosts. That's clearly not the case if the address is shared by multiple hosts at different physical network locations 🗺️. Today, CPE NAT already causes problems for sharing TCP control block state across multiple connections to a given IP address. Large-scale address sharing will make these issues more severe and more widespread 📈.
15. Reverse DNS 🔄
Many service providers populate forward and reverse DNS zones for the public IPv4 addresses they allocate to their subscribers 🗂️. When public addresses are shared across multiple subscribers, these strings are, by definition, no longer enough to identify an individual subscriber without additional information 🫤.
16. Load Balancing ⚖️
Algorithms used to balance traffic load for popular destinations may be affected by the introduction of address sharing 🏋️♀️. Where balancing is achieved by deterministically routing traffic from specific source IP addresses to specific servers, load imbalances may be experienced as address sharing gets enabled for some of those source IP addresses 📊. This will require re-evaluation of the algorithms used in the load-balancing design. In general, as the scale of address sharing grows, load-balancing designs will need to be re-evaluated, and any assumptions about average load per source IP address revisited 🔬💖.
17. IPv6 Transition Issues 🦋
okay so IPv4 address sharing can totally clash with the IPv4-to-IPv6 transition mechanisms 😭 and those were never designed with the IPv4 shortage in mind 💀. with port-range solutions, incoming 6to4 packets still need to get from a 6to4 relay to the right 6to4 CPE router, even though there's no direct port-range info to go on (the UDP/TCP initial source port didn't go through the CPE port range translation process) 🙈. one idea is for a 6to4 IPv6 address to embed both an IPv4 address and a port range value ✨.
subscribers who've been given private addresses can't use 6to4 [RFC3056] to get onto IPv6 🥺, but they might be able to use Teredo [RFC4380] 🧚.
some routers turn on 6to4 over their WAN link 🌸. 6to4 needs a publicly routable IPv4 address, so if 6to4 gets enabled while that "public" WAN address is actually sitting behind a NAT, you end up with a disconnected IPv6 island 🏝️. not the vibe 💔.
18. Introduction of Single Points of Failure 💥
so, like with every new piece of network functionality, bringing in new nodes or functions to juggle multiple subscribers across shared IPv4 addresses could create single points of failure 😬. any IP address sharing solution should think about adding redundancy features so the robustness of the IP connectivity service doesn't take a hit 🛡️. it should also consider whether it can allow hot swapping from one machine to another 🔄. this matters even more when the solution needs per-flow state in the network 👀.
19. State Maintenance Reduces Battery Life 🔋
okay this one hurts 😭. for hosts to keep network state alive behind a NAT, keep-alive messages have to go out at frequent intervals 📡. for battery-powered devices, sending those keep-alives can drain the battery way faster than it otherwise would 🪫 [Mobile_Energy_Consumption] 💀.
20. Support of Multicast 📣
[RFC5135] lays out requirements for a NAT that supports Any Source IP Multicast or Source-Specific IP Multicast 🎶. port-range routers that are part of port-range solutions will need to support similar requirements if multicast support is needed 🫶.
21. Support of Mobile-IP 🌍
IP address sharing in Mobile IP deployments (in the home network and/or the visited network) means Home Agents and/or Foreign Agents will need updates so they take the relevant port information into account 🛠️. there may also be issues when an extra layer of encapsulation is needed, which causes or increases the need for fragmentation and reassembly 🧩.
issues for Mobile-IP in the presence of NAT are discussed in [NAT64-MOBILITY] 📖.
22. Security Considerations 🔐
this memo doesn't define any protocol, so it doesn't create any new security issues 🙌. that said, Section 13 talks about some of the security and identity-related implications of IP address sharing, and you really should go read it 😤🚨.
23. Contributors 🎀
this document is based on sources co-authored by J.L. Grimault and A. Villefranque of France Telecom 💜.
24. Acknowledgments 🙏
this memo was partly inspired by conversations at Internet Society (ISOC) hosted roundtable events for operators and content providers deploying IPv6 🌈. the people in those discussions were John Brzozowski, Leslie Daigle, Tom Klieber, Yiu Lee, Kurtis Lindqvist, Wes George, Lorenzo Colliti, Erik Kline, Igor Gashinsky, Jason Fesler, Rick Reed, Adam Bechtel, Larry Campbell, Tom Coffeen, David Temkin, Pete Gelbman, Mark Winter, Will Charnock, Martin Levy, Greg Wood, and Christian Jacquenet 👑.
the authors are also so grateful to Christian Jacquenet, Iain Calder, Joel Halpern, Brian Carpenter, Gregory Lebovitz, Bob Briscoe, Marcelo Bagnulo, Dan Wing, and Wes George for their helpful comments and suggestions for improving the document 💖.
this memo was created using the xml2rfc tool 🍓.
25. Informative References 📚
[A+P] Bush, R., "The A+P Approach to the IPv4 Address Shortage",
Work in Progress, February 2011.
[CGN_Viability]
Alcock, S., "Research into the Viability of Service-
Provider NAT", 2008, <http://www.wand.net.nz/~salcock/
someisp/flow_counting/result_page.html>.
[DS-Lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", Work in Progress, May 2011.
[IANA_Ports]
IANA, "Port Numbers", <http://www.iana.org>.
[IPv4_Pool]
ICANN, "Available Pool of Unallocated IPv4 Internet
Addresses Now Completely Emptied", February 2011,
<http://icann.org/en/news/releases/
release-03feb11-en.pdf>.
[LSN-REQS] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common requirements for IP address sharing
schemes", Work in Progress, March 2011.
[Mobile_Energy_Consumption]
Haverinen, H., Siren, J., and P. Eronen, "Energy
Consumption of Always-On Applications in WCDMA Networks",
April 2007, <http://research.nokia.com/node/5597>.
[NAT-PMP] Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", Work
in Progress, April 2008.
[NAT-SEC] Gont, F. and P. Srisuresh, "Security implications of
Network Address Translators (NATs)", Work in Progress,
October 2009.
[NAT444] Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444", January 2011.
[NAT64-MOBILITY]
Haddad, W. and C. Perkins, "A Note on NAT64 Interaction
with Mobile IPv6", Work in Progress, March 2011.
[PCP] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
P. Selkirk, "Port Control Protocol (PCP)", Work
in Progress, May 2011.
[PORT-RANGE]
Boucadair, M., Levis, P., Bajko, G., and T. Savolainen,
"IPv4 Connectivity Access in the Context of IPv4 Address
Exhaustion: Port Range based IP Architecture", Work
in Progress, July 2009.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP",
RFC 1337, May 1992.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140,
April 1997.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a
Network Address Translator (NAT) and a Network Address
Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
Behavioral Requirements for ICMP", BCP 148, RFC 5508,
April 2009.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961,
August 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056,
January 2011.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[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.
[SAM] Despres, R., "Scalable Multihoming across IPv6 Local-
Address Routing Zones Global-Prefix/Local-Address
Stateless Address Mapping (SAM)", July 2009.
[UPnP-IGD] UPnP Forum, "Universal Plug and Play (UPnP) Internet
Gateway Device (IGD) V 2.0", December 2010,
<http://upnp.org/specs/gw/igd2/>.
[Windows-Logo]
Microsoft, "Windows Logo Program Requirements and
Policies", 2006, <http://www.microsoft.com/whdc/winlogo/
hwrequirements/default.mspx>.Appendix A. Classes of Address Sharing Solution ✨
okay so bestie, IP address sharing solutions fall into two classes 💅 Either the service provider runs a NAT function of its own and gives subscribers addresses from [RFC1918] space, or public IPv4 addresses get shared across multiple subscribers by limiting which ports each one can use 🦋 I'll break down both a bit more below.
- CGN-based solutions: These solutions add a NAPT function inside the service provider's network. It's called Carrier Grade NAT (CGN), Large Scale NAT (LSN) [LSN-REQS], or Provider NAT 🌸 The CGN is responsible for translating private addresses to publicly routable addresses. Subscribers get private addresses, the CGN gets a pool of public addresses, and the number of public addresses is smaller than the number of subscribers, so one public IPv4 address in the CGN pool is shared by several subscribers at the same time 🔥 Solutions that use a service provider-based NAT include [NAT444] (two layers of NAT) and [DS-Lite] (a single layer of NAT) 🧚
- Port-range solutions: These solutions skip the CGN entirely 🎀 A single public IPv4 address is assigned to several subscribers at the same time, and each subscriber also gets a restricted port range. Two subscribers with the same IPv4 address have two different port ranges that do not overlap ✨ These are called Address+Port [A+P], Port Range [PORT-RANGE], or Stateless Address Mapping [SAM] 💜
Appendix B. Address Space Multiplicative Factor 💖
so the whole point of sharing public IPv4 addresses is to increase the addressing space 🌈 The key parameter is the factor by which service providers want or need to multiply their public IPv4 address space. The consequence of that factor is the number of subscribers sharing the same public IPv4 address. This parameter is called the address space multiplicative factor, and its inverse is called the compression ratio 🍓
The multiplicative factor can only be applied to the subset of subscribers that are eligible for a shared address 🙈 A subscriber might not be able to have a shared address for these reasons:
- It would not be compatible with the service to which they are currently subscribed (for example, business subscriber).
- Subscriber CPE is not compatible with the address sharing solution selected by the service provider (for example, it does not handle port restriction for port-range solutions or it does not allow IPv4 in IPv6 encapsulation for the DS-Lite solution), and its replacement is not easy 😭
Different service providers have very different needs, bestie 🫶 A long-lived service provider, whose number of subscribers is rather stable, may have an existing address pool that will only need a small extension to cope with the next few years. That assumes the address pool can be re-purposed for an address sharing solution, which gives a small multiplicative factor (less than 10) 🦋 A new entrant or a new line of business will need a much bigger multiplicative factor (e.g., 1000) 🚀 A mobile operator may see its addressing needs grow dramatically as the IP-enabled mobile handset market grows 📱
When the multiplicative factor is large, the average number of ports per subscriber is small 😬 The measured disparity between average and peak port consumption is large [CGN_Viability], so if ports are allocated statically, this will create service problems. In that case it is essential for port allocation to map to need as closely as possible, and to avoid allocating ports for longer than necessary. So the larger the multiplicative factor, the more dynamic the port assignment has to be 👑
Authors' Addresses 🎀
Here are the authors, with their addresses exactly as they're written in the original 🫶
Mat Ford (editor)
Internet Society
Geneva
Switzerland
EMail: ford@isoc.orgMohamed Boucadair
France Telecom
Rennes 35000
France
EMail: mohamed.boucadair@orange-ftgroup.comAlain Durand
Juniper Networks
EMail: adurand@juniper.netPierre Levis
France Telecom
42 rue des Coutures
BP 6243
Caen Cedex 4 14066
France
EMail: pierre.levis@orange-ftgroup.comPhil Roberts
Internet Society
Reston, VA
USA
EMail: roberts@isoc.org📦 where this page comes from
- ietf: rfc6269 2011-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms