You must know different WISPs than I know (and I know hundreds). Most WISPs use IPv4 publicly, no IPv6 and don't have any boxes capable of synced NAT tables.
Public or private you have the same issues of not putting too many Google requests through the same public v4 address, keeping things at multiple egress points in sync, etc.
Performing the NAT on the border routers is not a problem. The problem comes into play where the connectivity is not symmetric. Multiple entry/exit points to the Internet and some are load balanced. We'd like to keep that architecture too as it allows for very good protection in an internet link failure scenario and provides BGP best path connectivity.
So traffic cones in ISP A might leave ISP B or traffic coming in ISP A may come in ISP B simultaneously.
Thanks,
Joshua Moore
Network Engineer
ATC Broadband
912.632.3161
That's only an issue with airport devices and PPPoE. I can confirm it
does native DHCPv6-PD otherwise.
I guess the WISPs I advise get better advice 
-mel via cell
Dual-stack doesn't require public IPv4 addresses. Since IPv4 is in short supply, providers must still do what they can to conserve them. This means NAT, with appropriate management to not overload any one IP, or CGN if you want to keep public IPv4 (but no longer unique ones) on CPE. Not every customer needs direct IPv4 connectivity without NAT; those that do must pay for it. If those who have it aren't willing to pay, they must give up their public IPv4 address.
That is the most efficient direct IPv4 provisioning concept we have today. Given the history of IPv6 adoption, it's clear that people won't move until they experience pain sticking with IPv4.
"On demand" IPv4 isn't currently being done anywhere AFAIK, and since we're abandoning IPv4 it's not likely anyone has that on their priority list. It's not a good policy to go out of your way to make IPv4 users comfortable. IPv4 is going to go away, and the sooner customers get that and go to IPv6, the sooner the pain will stop
-mel beckman
I think this is a key item for people to have in mind. We can all follow poor advice and add in new layers of NATs, possibly including certain applications within the NAT cone, or we can deliver DS, or DS-like service via several technologies.
There are a lot of devices that can do NAT from roll your own Linux or pfSense style up to commercial solutions that vendors will sell you. (I recall cisco pitching the ASR1K for this years ago). You could even use something like LISP to do these redundancy things within your network.
I would treat NAT the same way people treat CDNs which is find the large destinations and encourage people to use IPv6 for those.
Looking at the “top sites” here: http://www.alexa.com/topsites
Almost all of them are IPv6 enabled. You can even poke at sites with external tools like this:
http://ipv6-test.com/validate.php
Frank Bulk also monitors most of the major carrier sites for their IPv6 reliability and stability. He often gets me to contact our IT department to address the issues they have coping with the traffic volumes involved on the IPv6 side for the www.us.ntt.net and www.ntt.net sites. (and yes frank, I got your email and texts yesterday )
I would say there is no one right/wrong way to do this, but getting the core of your network IPv6 enabled first then pushing to your edges is a must-do item for the upcoming quarter or two.
I was once advised on technical issues where I explained in perfect technical detail the problems and solution path, but the management started talking about the optics of the issue. Take advantage of the NBC, etc coverage to ensure these priorities are taken care of. This may feel like stooping low to some people, but it’s important to get any IPv6 items off your todo list. There is a great ipv6-ops list as well out there where detailed questions can be asked and answered amongst those that are doing similar things.
While I dislike what T-Mobile USA has done from a technical side, their success shows that the IPv6 only edge *is* possible. This means we can take away the idea that we *must* have IPv4 for a device to be reachable/considered “online”.
I anxiously await the results of the apple/IPv6/iOS9 changeover and the increased traffic that will occur as a result. I think 2016 will drive the traffic levels to many multiples where they are now and much closer to parity on the global backbones.
- Jared
You don't work with end-users much, do you? The same types that follow Free Press and what not about how their ISP breaks it off in their backside (despite no concrete evidence - see the recent M-Labs, Free Press incident)... they won't take too kindly to being told to pay more for IPv4 to make whatever game work properly. It has to be seamless and it has to be free.
Mike,
They certainly won't like it. But the situation is the same everywhere. It's not like they're being gouged.
-mel via cell
I like the sentiment of what Apple has done. It is a move in the right
direction.
I don't think apple's move will materially change traffic levels. IPv6
traffic levels will move when when iPhones can be deployed as ipv6-only
with parity to ipv4-only.
Time will tell.
But, it is also telling that android and windows phone are live in the
hands of ipv6-only customers and there is no plan for that with Apple.
CB
I dont think my customers would see it that way. They would say, "we'll
just go with ATT or Comcast instead." Poof, there goes that MRR!
-The other WISP Mike
Or better yet globally routed /48.
/56 is still a bad idea.
Owen
Well, that *is* one way to reduce your dependence on IPv4.
If you want to keep that, then you’ll need a public backbone network that joins all of your NATs and you’ll need to have your NATs use unique exterior address pools.
Load balancing a single session across multiple NATs isn’t really possible.
Owne
NAT at the POP seems much more feasible, then. Wherever your chokepoint is in network redundancy, do the NAT there.
So basically what you are telling me is that the NAT gateway needs to be centrally aggregated.
Thanks,
Joshua Moore
Network Engineer
ATC Broadband
912.632.3161
If you must do NAT it should be as close to the edge as
possible. Today that's usually at the CPE. Maybe tomorrow that's one
hop upstream at the distribution router. That way the core remains
clean and doesn't accumulate state or have to deal with asymmetries.
-w
Not necessarily. But what I am telling you is that whatever goes out NAT gateway A has to come back in through NAT gateway A.
You can build whatever topology you want on either side of that and nothing says B has to be any where near A.
Owen
The point I am concerned about is a central point of failure.
Thanks,
Joshua Moore
Network Engineer
ATC Broadband
912.632.3161
A NAT box is a central point of failure for which the only cure is to not do NAT.
You can get clustered NAT boxes (Juniper, for example), but that just makes a bigger central point of failure.
Owen