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 <jmo...@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 <m...@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 <jmo...@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 <m...@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 <jmo...@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 <m...@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 :)

Reply via email to