Dual stack IPv6 for IPv4 depletion

Josh Moore jmoore at atcnetworks.net
Sun Jul 5 20:17:22 UTC 2015


Theoretically it should be possible with this on MPLS enabled devices. The "HA link" could then ride on top of the MPLS core redundancy alongside public outside NAT traffic and inside private traffic.

The good thing is that most of my customer access (DSL, cable, T1) is designed with established distribution points. Implementing sectional CGN at those points would be a good first step. We need to just get the policy side of things worked out on how we are going to automate the provisioning internally.

Thanks for all the input.

Thanks,

Joshua Moore
Network Engineer
ATC Broadband
912.632.3161

> On Jul 5, 2015, at 3:55 PM, Mel Beckman <mel at beckman.org> wrote:
> 
> Many firewalls will do state sync across an HA link. This works fine as long as you use BGP to ensure internet routing of your IPv4 to all gateways. But then the HA link is the single point of failure. I think the best you can hope for is that the importance of IPv4 NAT will diminish over time. One day it will be just a memory, like SNA :)
> 
> -mel beckman
> 
>> On Jul 5, 2015, at 12:37 PM, Josh Moore <jmoore at atcnetworks.net> wrote:
>> 
>> I was hoping to find a solution that maybe utilized some kind of session sync or something of that matter allowing for multiple entry and exit points (asymmetric routing).
>> 
>> 
>> 
>> 
>> Thanks,
>> 
>> Joshua Moore
>> Network Engineer
>> ATC Broadband
>> 912.632.3161
>> 
>>> On Jul 5, 2015, at 3:10 PM, Owen DeLong <owen at delong.com> wrote:
>>> 
>>> 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
>>> 
>>>> On Jul 5, 2015, at 11:49 , Josh Moore <jmoore at atcnetworks.net> wrote:
>>>> 
>>>> The point I am concerned about is a central point of failure.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> Joshua Moore
>>>> Network Engineer
>>>> ATC Broadband
>>>> 912.632.3161
>>>> 
>>>>> On Jul 5, 2015, at 2:46 PM, Owen DeLong <owen at delong.com> wrote:
>>>>> 
>>>>> 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
>>>>> 
>>>>>> On Jul 5, 2015, at 11:25 , Josh Moore <jmoore at atcnetworks.net> wrote:
>>>>>> 
>>>>>> 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
>>>>>> 
>>>>>>> On Jul 5, 2015, at 1:29 PM, Owen DeLong <owen at delong.com> wrote:
>>>>>>> 
>>>>>>> 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
>>>>>>> 
>>>>>>>> On Jul 5, 2015, at 08:11 , Josh Moore <jmoore at atcnetworks.net> wrote:
>>>>>>>> 
>>>>>>>> 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
>>>>>>>> 
>>>>>>>>> On Jul 5, 2015, at 10:43 AM, Mel Beckman <mel at beckman.org> wrote:
>>>>>>>>> 
>>>>>>>>> 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.  
>>>>>>>>> 
>>>>>>>>> -mel beckman
>>>>>>>>> 
>>>>>>>>>> On Jul 5, 2015, at 7:25 AM, Josh Moore <jmoore at atcnetworks.net> wrote:
>>>>>>>>>> 
>>>>>>>>>> So the question is: where do you perform the NAT and how can it be redundant?
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> 
>>>>>>>>>> Joshua Moore
>>>>>>>>>> Network Engineer
>>>>>>>>>> ATC Broadband
>>>>>>>>>> 912.632.3161
>>>>>>>>>> 
>>>>>>>>>>> On Jul 5, 2015, at 10:12 AM, Mel Beckman <mel at beckman.org> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Josh,
>>>>>>>>>>> 
>>>>>>>>>>> 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. 
>>>>>>>>>>> 
>>>>>>>>>>> -mel via cell
>>>>>>>>>>> 
>>>>>>>>>>>> On Jul 5, 2015, at 6:57 AM, Josh Moore <jmoore at atcnetworks.net> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> We are the ISP and I have a /32 :)
>>>>>>>>>>>> 
>>>>>>>>>>>> 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
>>>>>>>>>>>> 
>>>>>>>>>>>> On Jul 5, 2015, at 9:55 AM, Mel Beckman <mel at beckman.org> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Josh Moore wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 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 :)
>>> 



More information about the NANOG mailing list