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. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 



----- Original Message -----

From: "Mel Beckman" <m...@beckman.org> 
To: "Josh Moore" <jmo...@atcnetworks.net> 
Cc: jo...@iecc.com, nanog@nanog.org 
Sent: Sunday, July 5, 2015 9:43:40 AM 
Subject: Re: Dual stack IPv6 for IPv4 depletion 

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