Sharing an IPv4 Address Across Multiple Subscribers – Part Two – Inbound Services
Tuesday, December 16th, 2008In the last discussion, we talked about service providers using a single IPv4 address shared between subscribers. Carriers may well do this not as an alternative to IPv6 deployment – which pretty much everyone (finally) agrees is the “real” solution – but as a stopgap measure to allow them more time to complete their IPv6 deployments. Many providers have done a poor job of preparing their businesses for the “post ready availability of IPv4 routable addresses world”. Additionally, and as an aside, not all in-home platforms are IPv6 ready and on-by-default (Windows XP, for example, have IPv6 but it is not on by default. So, there are a number of reasons why providers need to be able to provision IPv4 to existing and new subscribers for another few years.
In the “shared IPv4 address” schemes, rather than have “one IPv4 address per subscriber” there would be a new practice – “one IPv4 address per multiple subscribers”. There are several implementation schemes under discussion for how the provider would actually do this. One schemes call for “double NAT”, where the subscriber (with a NAT router at the edge) uses RFC1918 internally, does NAT at the edge, and then the provider does NAT *again*. Another scheme simply moves the NAT function from the subscriber edge router into the provider cloud, leaving it still “single NAT”, but no longer in the subscriber device. More about these another time.
The issue left on the table last time was “what do we do about inbound services”? Suppose a subscriber wants to run a webserver, for example. Suppose another subscriber sharing that routable IPv4 address also wants to run a webserver? Clearly, both cannot receive traffic inbound destined for “IPv4_Addr:80” – the standard HTTP TCP service port. What do we do in this situation?
I think the answer is the simple one – “don’t do that”.
The most likely implementation will be for the “standard” subscriber service offered to home users (“consumer class”) to indeed be a “shared IPv4 address” scheme. These addresses are probably most often, for almost all carriers, assigned via DHCPv4 anyway, and are dynamic. Someone using the standard service would not be expected to run services requiring specific inbound ports. These subscribers would only be expected to run “NAT-friendly” applications – as most subscribers do today.
For subscribers hosting services, or using more advanced applications, however, the provider will offer a “premium service” – a dedicated IPv4 address. That will be the solution. A “normal” subscriber gets a shared IPv4 address. A “premium” subscriber pays a little extra, gets a dedicated IPv4 address (and probably a static IPv4 address, which some carriers offer today as a premium service), and is not subject to NAT within the carrier cloud. If the subscriber does NAT locally, within their home edge device, that is up to them.
In some ways, this is a simple solution. It only appears simple from the subscriber view. They pay a little extra. For the provider – not simple. Remember that solutions only work for providers that are scalable. Think about the impact on the provisioning and billing systems or the provider. Think about the network impacts of implementing the “shared IPv4 address” scheme. Lots of challenges, lots of work to do, and – look around – in a pretty challenging business environment.
I always say it is not easy being a provider. This is another example. But what choice do the providers have? They need to keep signing up new customers, and not all subscribers are ready for IPv6 today (nor will they be in 2009, when the IPv4 address shortage really will begin to constrain their business).
Ahead, we’ll talk about applications that will not work (or as well) in a double-NAT environment, and also about some of the more popular “shared address” schemes.