[181804] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Dual stack IPv6 for IPv4 depletion

daemon@ATHENA.MIT.EDU (Mel Beckman)
Sun Jul 5 10:43:50 2015

X-Original-To: nanog@nanog.org
From: Mel Beckman <mel@beckman.org>
To: Josh Moore <jmoore@atcnetworks.net>
Date: Sun, 5 Jul 2015 14:43:40 +0000
In-Reply-To: <2FF7B7F3-9AE0-4809-9C86-A0055CD304B9@atcnetworks.net>
Cc: "johnl@iecc.com" <johnl@iecc.com>, "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org

WISPs have been good at solving this, as they are often deploying greenfiel=
d networks. They use private IPv4 internally and NAT IPv4 at multiple exit =
points. IPv6 is seamlessly redundant, since customers all receive global /6=
4s; BGP handles failover. If you home multiple upstream providers on a sing=
le NAT gateway hardware stack, redundancy is also seamless, since your NAT =
tables are synced across redundant stack members.  If you have separate sta=
cks, or even sites, IPv4 can fail over to an alternate NAT Border gateway b=
ut will lose session contexts, unless you go to the trouble of syncing the =
gateways. Most WISPs don't. =20

 -mel beckman

> On Jul 5, 2015, at 7:25 AM, Josh Moore <jmoore@atcnetworks.net> wrote:
>=20
> So the question is: where do you perform the NAT and how can it be redund=
ant?
>=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 and if th=
ey want IPv6 they need only get an IPv6-enabled firewall. Unless you're als=
o an IT consultant to your customers, your job is done. If you already supp=
ly the CPE firewall, then you need only turn on IPv6 for customers who requ=
est it. With the right kind of CPE, you can run MPLS or EoIP and deliver pu=
blic 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 subscribers of=
f v4 from the perspective of solving the address utilization crisis while s=
till providing compatibility for those one-off sites and services that 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 sense of e=
very device has a one to one global address mapping.
>>>>=20
>>>> No, tunnels do give you one to one global IPv6 address mapping for eve=
ry 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-stac=
k ISP already, you can forgo tunneling altogether and just use an IPv6-capa=
ble 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 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.
>>>>=20
>>>> Nobody is recommending the Apple router as a border firewall. It's ter=
rible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP ca=
n't deliver IPv6, tunneling is the clear path to building a lab. If you hav=
e a dual-stack ISP already, the clear path is to use an IPv6-capable border=
 firewall.=20
>>>>=20
>>>> So you are in a maze of non-twisty paths, all alike :)

home help back first fref pref prev next nref lref last post