[181822] in North American Network Operators' Group
Re: Dual stack IPv6 for IPv4 depletion
daemon@ATHENA.MIT.EDU (Mike Hammett)
Sun Jul 5 13:43:48 2015
X-Original-To: nanog@nanog.org
Date: Sun, 5 Jul 2015 12:43:41 -0500 (CDT)
From: Mike Hammett <nanog@ics-il.net>
To: nanog@nanog.org
In-Reply-To: <6952A7F8-7899-4626-9097-9869E5E0BA62@delong.com>
Errors-To: nanog-bounces@nanog.org
NAT at the POP seems much more feasible, then. Wherever your chokepoint is =
in network redundancy, do the NAT there.=20
-----=20
Mike Hammett=20
Intelligent Computing Solutions=20
http://www.ics-il.com=20
Midwest Internet Exchange=20
http://www.midwest-ix.com=20
----- Original Message -----
From: "Owen DeLong" <owen@delong.com>=20
To: "Josh Moore" <jmoore@atcnetworks.net>=20
Cc: johnl@iecc.com, nanog@nanog.org=20
Sent: Sunday, July 5, 2015 12:29:21 PM=20
Subject: Re: Dual stack IPv6 for IPv4 depletion=20
If you want to keep that, then you=E2=80=99ll need a public backbone networ=
k that joins all of your NATs and you=E2=80=99ll need to have your NATs use=
unique exterior address pools.=20
Load balancing a single session across multiple NATs isn=E2=80=99t really p=
ossible.=20
Owne=20
> On Jul 5, 2015, at 08:11 , Josh Moore <jmoore@atcnetworks.net> wrote:=20
>=20
> Performing the NAT on the border routers is not a problem. The problem co=
mes 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 a=
rchitecture too as it allows for very good protection in an internet link f=
ailure scenario and provides BGP best path connectivity.=20
>=20
> So traffic cones in ISP A might leave ISP B or traffic coming in ISP A ma=
y come in ISP B simultaneously.=20
>=20
>=20
>=20
>=20
> Thanks,=20
>=20
> Joshua Moore=20
> Network Engineer=20
> ATC Broadband=20
> 912.632.3161=20
>=20
>> On Jul 5, 2015, at 10:43 AM, Mel Beckman <mel@beckman.org> wrote:=20
>>=20
>> WISPs have been good at solving this, as they are often deploying greenf=
ield networks. They use private IPv4 internally and NAT IPv4 at multiple ex=
it points. IPv6 is seamlessly redundant, since customers all receive global=
/64s; BGP handles failover. If you home multiple upstream providers on a s=
ingle NAT gateway hardware stack, redundancy is also seamless, since your N=
AT tables are synced across redundant stack members. If you have separate s=
tacks, 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 th=
e gateways. Most WISPs don't.=20
>>=20
>> -mel beckman=20
>>=20
>>> On Jul 5, 2015, at 7:25 AM, Josh Moore <jmoore@atcnetworks.net> wrote:=
=20
>>>=20
>>> So the question is: where do you perform the NAT and how can it be redu=
ndant?=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> Thanks,=20
>>>=20
>>> Joshua Moore=20
>>> Network Engineer=20
>>> ATC Broadband=20
>>> 912.632.3161=20
>>>=20
>>>> On Jul 5, 2015, at 10:12 AM, Mel Beckman <mel@beckman.org> wrote:=20
>>>>=20
>>>> Josh,=20
>>>>=20
>>>> 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 a=
lso an IT consultant to your customers, your job is done. If you already su=
pply the CPE firewall, then you need only turn on IPv6 for customers who re=
quest 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 priva=
te IPv4 and NAT as usual for IPv4 traffic.=20
>>>>=20
>>>> -mel via cell=20
>>>>=20
>>>>> On Jul 5, 2015, at 6:57 AM, Josh Moore <jmoore@atcnetworks.net> wrote=
:=20
>>>>>=20
>>>>> We are the ISP and I have a /32 :)=20
>>>>>=20
>>>>> 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 ar=
e still on v4.=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Thanks,=20
>>>>>=20
>>>>> Joshua Moore=20
>>>>> Network Engineer=20
>>>>> ATC Broadband=20
>>>>> 912.632.3161=20
>>>>>=20
>>>>> On Jul 5, 2015, at 9:55 AM, Mel Beckman <mel@beckman.org> wrote:=20
>>>>>=20
>>>>>>>=20
>>>>>>> Josh Moore wrote:=20
>>>>>>>=20
>>>>>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they d=
o 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.=20
>>>>>>=20
>>>>>> No, tunnels do give you one to one global IPv6 address mapping for e=
very device. From a testing perspective, a tunnelbroker works just as if yo=
u had a second IPv6-only ISP. If you're fortunate enough to have a dual-sta=
ck ISP already, you can forgo tunneling altogether and just use an IPv6-cap=
able border firewall.=20
>>>>>>=20
>>>>>> William Waites wrote:=20
>>>>>>> I was helping my=20
>>>>>>> friend who likes Apple things connect to the local community=20
>>>>>>> network. He wanted to use an Airport as his home gateway rather tha=
n=20
>>>>>>> the router that we normally use. Turns out these things can *only* =
do=20
>>>>>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there =
is=20
>>>>>>> not exactly a clear path to native IPv6 for your lab this way.=20
>>>>>>=20
>>>>>> Nobody is recommending the Apple router as a border firewall. It's t=
errible 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 h=
ave a dual-stack ISP already, the clear path is to use an IPv6-capable bord=
er firewall.=20
>>>>>>=20
>>>>>> So you are in a maze of non-twisty paths, all alike :)=20
