[181832] in North American Network Operators' Group
Re: Dual stack IPv6 for IPv4 depletion
daemon@ATHENA.MIT.EDU (Mel Beckman)
Sun Jul 5 15:59:18 2015
X-Original-To: nanog@nanog.org
From: Mel Beckman <mel@beckman.org>
To: Josh Moore <jmoore@atcnetworks.net>
Date: Sun, 5 Jul 2015 19:55:17 +0000
In-Reply-To: <C26E7822-7795-4D6A-8E9A-7C8DADEF7DFA@atcnetworks.net>
Cc: "johnl@iecc.com" <johnl@iecc.com>, "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Many firewalls will do state sync across an HA link. This works fine as lon=
g as you use BGP to ensure internet routing of your IPv4 to all gateways. B=
ut then the HA link is the single point of failure. I think the best you ca=
n 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@atcnetworks.net> wrote:
>=20
> 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 point=
s (asymmetric routing).
>=20
>=20
>=20
>=20
> Thanks,
>=20
> Joshua Moore
> Network Engineer
> ATC Broadband
> 912.632.3161
>=20
>> On Jul 5, 2015, at 3:10 PM, Owen DeLong <owen@delong.com> wrote:
>>=20
>> A NAT box is a central point of failure for which the only cure is to no=
t do NAT.
>>=20
>> You can get clustered NAT boxes (Juniper, for example), but that just ma=
kes a bigger central point of failure.
>>=20
>> Owen
>>=20
>>> On Jul 5, 2015, at 11:49 , Josh Moore <jmoore@atcnetworks.net> wrote:
>>>=20
>>> The point I am concerned about is a central point of failure.
>>>=20
>>>=20
>>>=20
>>>=20
>>> Thanks,
>>>=20
>>> Joshua Moore
>>> Network Engineer
>>> ATC Broadband
>>> 912.632.3161
>>>=20
>>>> On Jul 5, 2015, at 2:46 PM, Owen DeLong <owen@delong.com> wrote:
>>>>=20
>>>> Not necessarily. But what I am telling you is that whatever goes out N=
AT gateway A has to come back in through NAT gateway A.
>>>>=20
>>>> You can build whatever topology you want on either side of that and no=
thing says B has to be any where near A.
>>>>=20
>>>> Owen
>>>>=20
>>>>> On Jul 5, 2015, at 11:25 , Josh Moore <jmoore@atcnetworks.net> wrote:
>>>>>=20
>>>>> So basically what you are telling me is that the NAT gateway needs to=
be centrally aggregated.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Thanks,
>>>>>=20
>>>>> Joshua Moore
>>>>> Network Engineer
>>>>> ATC Broadband
>>>>> 912.632.3161
>>>>>=20
>>>>>> On Jul 5, 2015, at 1:29 PM, Owen DeLong <owen@delong.com> wrote:
>>>>>>=20
>>>>>> If you want to keep that, then you=92ll need a public backbone netwo=
rk that joins all of your NATs and you=92ll need to have your NATs use uniq=
ue exterior address pools.
>>>>>>=20
>>>>>> Load balancing a single session across multiple NATs isn=92t really =
possible.
>>>>>>=20
>>>>>> Owne
>>>>>>=20
>>>>>>> On Jul 5, 2015, at 08:11 , Josh Moore <jmoore@atcnetworks.net> wrot=
e:
>>>>>>>=20
>>>>>>> Performing the NAT on the border routers is not a problem. The prob=
lem 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.
>>>>>>>=20
>>>>>>> So traffic cones in ISP A might leave ISP B or traffic coming in IS=
P A may come in ISP B simultaneously.
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> Thanks,
>>>>>>>=20
>>>>>>> Joshua Moore
>>>>>>> Network Engineer
>>>>>>> ATC Broadband
>>>>>>> 912.632.3161
>>>>>>>=20
>>>>>>>> On Jul 5, 2015, at 10:43 AM, Mel Beckman <mel@beckman.org> wrote:
>>>>>>>>=20
>>>>>>>> WISPs have been good at solving this, as they are often deploying =
greenfield networks. They use private IPv4 internally and NAT IPv4 at multi=
ple 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 sep=
arate 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 syn=
cing the gateways. Most WISPs don't. =20
>>>>>>>>=20
>>>>>>>> -mel beckman
>>>>>>>>=20
>>>>>>>>> On Jul 5, 2015, at 7:25 AM, Josh Moore <jmoore@atcnetworks.net> w=
rote:
>>>>>>>>>=20
>>>>>>>>> So the question is: where do you perform the NAT and how can it b=
e redundant?
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Thanks,
>>>>>>>>>=20
>>>>>>>>> Joshua Moore
>>>>>>>>> Network Engineer
>>>>>>>>> ATC Broadband
>>>>>>>>> 912.632.3161
>>>>>>>>>=20
>>>>>>>>>> On Jul 5, 2015, at 10:12 AM, Mel Beckman <mel@beckman.org> wrote=
:
>>>>>>>>>>=20
>>>>>>>>>> Josh,
>>>>>>>>>>=20
>>>>>>>>>> Your job is simple, then. Deliver dual-stack to your customers a=
nd if they want IPv6 they need only get an IPv6-enabled firewall. Unless yo=
u're also an IT consultant to your customers, your job is done. If you alre=
ady 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 de=
liver public IPv4 /32s to customers willing to pay for them. Otherwise it's=
private IPv4 and NAT as usual for IPv4 traffic.=20
>>>>>>>>>>=20
>>>>>>>>>> -mel via cell
>>>>>>>>>>=20
>>>>>>>>>>> On Jul 5, 2015, at 6:57 AM, Josh Moore <jmoore@atcnetworks.net>=
wrote:
>>>>>>>>>>>=20
>>>>>>>>>>> We are the ISP and I have a /32 :)
>>>>>>>>>>>=20
>>>>>>>>>>> I'm simply looking at the best strategy for migrating my subscr=
ibers off v4 from the perspective of solving the address utilization crisis=
while still providing compatibility for those one-off sites and services t=
hat are still on v4.
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> Thanks,
>>>>>>>>>>>=20
>>>>>>>>>>> Joshua Moore
>>>>>>>>>>> Network Engineer
>>>>>>>>>>> ATC Broadband
>>>>>>>>>>> 912.632.3161
>>>>>>>>>>>=20
>>>>>>>>>>> On Jul 5, 2015, at 9:55 AM, Mel Beckman <mel@beckman.org> wrote=
:
>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Josh Moore wrote:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> 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 se=
nse of every device has a one to one global address mapping.
>>>>>>>>>>>>=20
>>>>>>>>>>>> No, tunnels do give you one to one global IPv6 address mapping=
for every device. From a testing perspective, a tunnelbroker works just a=
s if you had a second IPv6-only ISP. If you're fortunate enough to have a d=
ual-stack ISP already, you can forgo tunneling altogether and just use an I=
Pv6-capable border firewall.=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> 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 rath=
er 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=
.
>>>>>>>>>>>>=20
>>>>>>>>>>>> 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 you=
r 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-capabl=
e border firewall.=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> So you are in a maze of non-twisty paths, all alike :)
>>=20
