[181831] in North American Network Operators' Group
Re: Dual stack IPv6 for IPv4 depletion
daemon@ATHENA.MIT.EDU (Ca By)
Sun Jul 5 15:55:09 2015
X-Original-To: nanog@nanog.org
In-Reply-To: <CAPkb-7BoU1OSYmMiHFKj5wxdz7mvZqJ78-LTnU8=Bv5Duk=o3w@mail.gmail.com>
Date: Sun, 5 Jul 2015 12:55:05 -0700
From: Ca By <cb.list6@gmail.com>
To: Baldur Norddahl <baldur.norddahl@gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On Sunday, July 5, 2015, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
> MAP solves that by splitting NAT into a part that can be done without sta=
te
> (route a port range to a customer) and the actual NAT which is then done =
on
> the CPE.
>
>
But you need special cpe, not sure that is in the op biz case
> It is also the only NAT solution that scales.
>
>
Yet, there is no real world scaled deployment of it....
I'd be careful about making broad statements at what scales for a given set
of constraints.
CB
> Regards,
>
> Baldur
>
>
> On 5 July 2015 at 21:09, Owen DeLong <owen@delong.com <javascript:;>>
> wrote:
>
> > A NAT box is a central point of failure for which the only cure is to n=
ot
> > do NAT.
> >
> > You can get clustered NAT boxes (Juniper, for example), but that just
> > makes a bigger central point of failure.
> >
> > Owen
> >
> > > On Jul 5, 2015, at 11:49 , Josh Moore <jmoore@atcnetworks.net
> <javascript:;>> wrote:
> > >
> > > The point I am concerned about is a central point of failure.
> > >
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Joshua Moore
> > > Network Engineer
> > > ATC Broadband
> > > 912.632.3161
> > >
> > >> On Jul 5, 2015, at 2:46 PM, Owen DeLong <owen@delong.com
> <javascript:;>> wrote:
> > >>
> > >> 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
> <javascript:;>> wrote:
> > >>>
> > >>> So basically what you are telling me is that the NAT gateway needs =
to
> > be centrally aggregated.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Joshua Moore
> > >>> Network Engineer
> > >>> ATC Broadband
> > >>> 912.632.3161
> > >>>
> > >>>> On Jul 5, 2015, at 1:29 PM, Owen DeLong <owen@delong.com
> <javascript:;>> wrote:
> > >>>>
> > >>>> If you want to keep that, then you=E2=80=99ll need a public backbo=
ne network
> > that joins all of your NATs and you=E2=80=99ll need to have your NATs u=
se unique
> > exterior address pools.
> > >>>>
> > >>>> Load balancing a single session across multiple NATs isn=E2=80=99t=
really
> > possible.
> > >>>>
> > >>>> Owne
> > >>>>
> > >>>>> On Jul 5, 2015, at 08:11 , Josh Moore <jmoore@atcnetworks.net
> <javascript:;>>
> > wrote:
> > >>>>>
> > >>>>> Performing the NAT on the border routers is not a problem. The
> > problem comes into play where the connectivity is not symmetric. Multip=
le
> > 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.
> > >>>>>
> > >>>>> So traffic cones in ISP A might leave ISP B or traffic coming in
> ISP
> > A may come in ISP B simultaneously.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Thanks,
> > >>>>>
> > >>>>> Joshua Moore
> > >>>>> Network Engineer
> > >>>>> ATC Broadband
> > >>>>> 912.632.3161
> > >>>>>
> > >>>>>> On Jul 5, 2015, at 10:43 AM, Mel Beckman <mel@beckman.org
> <javascript:;>> wrote:
> > >>>>>>
> > >>>>>> WISPs have been good at solving this, as they are often deployin=
g
> > 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 upstrea=
m
> > 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 <jmoore@atcnetworks.net
> <javascript:;>>
> > 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 <mel@beckman.org
> <javascript:;>> 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. Unle=
ss
> > you're also an IT consultant to your customers, your job is done. If yo=
u
> > 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 <jmoore@atcnetworks.ne=
t
> <javascript:;>>
> > 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 <mel@beckman.org
> <javascript:;>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> Josh Moore wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes a=
s
> > they do not give the benefit of true end to end IPv6 connectivity in th=
e
> > sense of every device has a one to one global address mapping.
> > >>>>>>>>>>
> > >>>>>>>>>> No, tunnels do give you one to one global IPv6 address mappi=
ng
> > for every device. From a testing perspective, a tunnelbroker works jus=
t
> 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 communit=
y
> > >>>>>>>>>>> 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. S=
o
> > 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 :)
> > >>>>
> > >>
> >
> >
>
