[181825] in North American Network Operators' Group
Re: Dual stack IPv6 for IPv4 depletion
daemon@ATHENA.MIT.EDU (Owen DeLong)
Sun Jul 5 14:47:17 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <9D9406E1-1C9B-4D1F-A211-583412E520FF@atcnetworks.net>
Date: Sun, 5 Jul 2015 11:46:52 -0700
To: Josh Moore <jmoore@atcnetworks.net>
Cc: "johnl@iecc.com" <johnl@iecc.com>, "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Not necessarily. But what I am telling you is that whatever goes out NAT =
gateway A has to come back in through NAT gateway A.
You can build whatever topology you want on either side of that and =
nothing says B has to be any where near A.
Owen
> 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 =
network that joins all of your NATs and you=92ll need to have your NATs =
use unique 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> =
wrote:
>>>=20
>>> 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.
>>>=20
>>> So traffic cones in ISP A might leave ISP B or traffic coming in ISP =
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 =
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. =20=
>>>>=20
>>>> -mel beckman
>>>>=20
>>>>> 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 =
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 =
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.=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 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.
>>>>>>>=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 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. =46rom 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.=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 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.=20
>>>>>>>>=20
>>>>>>>> So you are in a maze of non-twisty paths, all alike :)
>>=20
