Traditional dual stack deployments implement both IPv4 and IPv6 to the CPE.
Consider the following:
An ISP is at 90% IPv4 utilization and would like to deploy dual stack with the purpose of allowing their subscriber base to continue to grow regardless of the depletion of the IPv4 space. Current dual stack best practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If this is the case, and BOTH are still required, then how does IPv6 help with the v4 address depletion crisis? Many sites and services would still need legacy IPv4 compatibility. Sure, CGN technology may be a solution but what about applications that need direct IPv4 connectivity without NAT? It seems that there should be a mechanism to enable on-demand and efficient IPv4 address consumption ONLY when needed. My question is this: What, if any, solutions like this exist? If no solution exists then what is the next best thing? What would the overall IPv6 migration strategy and goal be?
Sorry for the length of this email but these are legitimate concerns and while I understand the need for IPv6 and the importance of getting there; I don't understand exactly HOW that can be done considering the immediate issue: IPv4 depletion.
Thanks
Joshua Moore
Network Engineer
ATC Broadband
912.632.3161
Yep, dual-stack does not solve problems for eyeball networks. This is why
eyeball networks use ds-lite, 464xlat, and map. Each requires some sort of
compromise.
At the end of the day, we all need to reject 'direct ipv4', it is an
invalid requirement that cannot be supported at scale over time.
But what is the "best compromise" strategy? Dual stack + CGN? Some kind of intelligent 6to4 NAT?
Depends on the application(s). One that seems to work OK is to dual
stack everyone and put them behind a NAT unless they ask to have a
private IP. Depending on who your customers are, charge more for a
private IP, or if you want to look less obviously venal, say you're
offering a discount to customers who move their applications that
require end-to-end addressing to IPv6. It is my strong impression
that people who think they're 100% IPv6 enabled still often need a
little IPv4 (NAT OK) for bootstrapping and the like, so you need to
dual stack no matter what you do.
If you do charge extra for IPv4, that makes it easier to go buy used
IPv4 space on the aftermarket.
The price of IPv4 addresses will go up now that supply is seriously constrained. The price increase will push information producers, who generally are the people needing public IPv4 space, over to IPv6, which is plentiful. This will create a class of services that is IPv6-only (e.g., Microsoft DirectAccess), which will encourage IPv4 information consumers to dual-stack. IPv4-only consumers will find themselves in an information ghetto, but one that they can easily get out of by just exerting a little effort. In the worst case scenario, an ISP customer stuck behind an IPv4 Internet connection can simply tunnel to IPv6 via one of the free tunnelbroker services such as HE.net<http://HE.net>’s tunnelbroker.net<http://tunnelbroker.net>.
This is a problem that will solve itself in a natural, and capitalist, way. Market pressures will push everyone to IPv6, and nobody need be left behind. I predict some enterprising inventor will create (if they haven’t already) a cheap IPv6 appliance akin to Roku or Apple TV that anyone can just drop onto their network to become IPv6 enabled via a tunnelbroker. In fact, I show just how to do this using a $99 Apple Airport Express in my three-hour online course “Build your own IPv6 Lab” (http://windowsitpro.com/build-your-own-ipv6-lab-and-become-ipv6-guru-demand).
If you don’t have an IPv6 lab yet, you should set one up ASAP. That’s the easiest way to get your head around all IPv6 issues. HE.net<http://HE.net> also has a very nice certification program that will take you through all the basic tasks of being IPv6 enabled both as an information producer and a consumer.
Incidentally, you don’t even need to spend $99 on a hardware device. Jeff Carrell of TeachMeIPv6.com<http://TeachMeIPv5.com> has a nice slide deck on building an IPv6 lab using VirtualBox:
Currently IPv4 is rather cheap. The first step is to conserve your
resources by deploying schemes to effectively use your IPv4 allocation. You
have to drop using a /30 for each customer and instead have your customer
on a shared subnet. We group our customers up to 60 customers in a /26.
I do not believe IPv4 will become expensive for some time. There are simply
too many people that made sure they got more than their share of the pool
and now they are all trying to sell the excess. Also many companies will
realize the need to optimize their IPv4 usage and as soon they do, they
will realize they actually posses excess IPv4 that can be sold. This is
especially true for the ARIN zone, where you have the most IPv4 address
space compared to population size.
So the answer for now is that you can continue business as usual. Something
that used to be free is now a cost, but it is not very expensive.
Of course not deploying IPv6 is a bad idea. It is in your best interest to
promote IPv6 so you have that, when IPv4 becomes too expensive.
When that time comes, I am betting on one of the Address plus Port schemes.
Most promising is MAP. You will have several users sharing an IPv4 address.
It will be ok for surfing the web but it will suck for many other things.
Therefore you want widespread use of IPv6 by the time you deploy this.
If everyone are using IPv6 most of the time, the customers are likely to
care less about the limitations of sharing an IPv4 address.
An anectode about this, maybe out of date, maybe not. I was helping my
friend who likes Apple things connect to the local community
network. He wanted to use an Airport as his home gateway rather than
the router that we normally use. Turns out these things can *only* do
IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is
not exactly a clear path to native IPv6 for your lab this way.
Creating this in a test lab is mandatory for a successful migration. Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping.
Seems that my initial thoughts of dual stack and v4 overloading using private addresses to ensure compatibility is the way to go. Any input on good, possibly application aware, CGN solutions? Maybe even some policy-based DHCP/NAT product?
Thanks,
Joshua Moore
Network Engineer
ATC Broadband
912.632.3161
The airport devices/airport express class are not that good of devices
as the embedded software doesn’t handle a lot of traffic or long uptime
well.
Most devices that are over 3 years old likely are not suitable for
IPv6 testing aside from understanding what is broken. Keep in mind
that software on a CPE device may be 6 months out of date by the time
it comes out of a container stateside.
Expecting people to use tunnels, etc doesn’t really scale properly.
I do wish that I could get static IPv6 prefixes along with my
static IPv4 at home, but having IPv6 at all took precedence.
Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping.
No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall.
William Waites wrote:
I was helping my
friend who likes Apple things connect to the local community
network. He wanted to use an Airport as his home gateway rather than
the router that we normally use. Turns out these things can *only* do
IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is
not exactly a clear path to native IPv6 for your lab this way.
Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall.
So you are in a maze of non-twisty paths, all alike
I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4.
Thanks,
Joshua Moore
Network Engineer
ATC Broadband
912.632.3161
Tunneling gets customers onto IPv6 with little trouble. I've deployed hundred of Apple Airports in this capacity and they have no problem with speeds of 200Mbps and more, and they rarely have downtime. The firmware is auto-updating and is kept very current by Apple. The one feature they don't support well is IPv6 DNS, since Airport has no DHCPv6 support. But an IPv4 name server works fine since the customers have an IPv4 link already.
Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic.
I believe he (at least someone) was looking for recommendations to CGN type devices. Many can do NAT, but looking for something a bit more intelligent. Your standard residential user may not understand, but would also be unwilling to pay any difference.
WISPs have been good at solving this, as they are often deploying greenfield networks. They use private IPv4 internally and NAT IPv4 at multiple exit points. IPv6 is seamlessly redundant, since customers all receive global /64s; BGP handles failover. If you home multiple upstream providers on a single NAT gateway hardware stack, redundancy is also seamless, since your NAT tables are synced across redundant stack members. If you have separate stacks, or even sites, IPv4 can fail over to an alternate NAT Border gateway but will lose session contexts, unless you go to the trouble of syncing the gateways. Most WISPs don't.
That's only an issue if you distribute a public IPv4 address to each customer. If you use private addressing in the core, ordinary NAT works if you're not a carrier-grade provider, and even then it can be practical in many cases. CGN is a solution for providers not willing to migrate to a private core.
