Dual stack IPv6 for IPv4 depletion

Sun Jul 5 19:25:26 UTC 2015

MAP solves that by splitting NAT into a part that can be done without state
(route a port range to a customer) and the actual NAT which is then done on
the CPE.

It is also the only NAT solution that scales.

Regards,

Baldur

On 5 July 2015 at 21:09, Owen DeLong <owen at delong.com> wrote:

> A NAT box is a central point of failure for which the only cure is to not
> 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 at atcnetworks.net> 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 at delong.com> 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 at atcnetworks.net> 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 at delong.com> wrote:
> >>>>
> >>>> If you want to keep that, then you’ll need a public backbone network
> that joins all of your NATs and you’ll need to have your NATs use unique
> exterior address pools.
> >>>>
> >>>> Load balancing a single session across multiple NATs isn’t really
> possible.
> >>>>
> >>>> Owne
> >>>>
> >>>>> On Jul 5, 2015, at 08:11 , Josh Moore <jmoore at atcnetworks.net>
> wrote:
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> 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 at beckman.org> wrote:
> >>>>>>
> >>>>>> 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.
> >>>>>>
> >>>>>> -mel beckman
> >>>>>>
> >>>>>>> On Jul 5, 2015, at 7:25 AM, Josh Moore <jmoore at atcnetworks.net>
> 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 at beckman.org> 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. 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.
> >>>>>>>>
> >>>>>>>> -mel via cell
> >>>>>>>>
> >>>>>>>>> On Jul 5, 2015, at 6:57 AM, Josh Moore <jmoore at atcnetworks.net>
> 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 at beckman.org> wrote:
> >>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Josh Moore wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> 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.
> >>>>>>>>>>
> >>>>>>>>>> No, tunnels do give you one to one global IPv6 address mapping
> for every 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-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 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.
> >>>>>>>>>>
> >>>>>>>>>> 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 :)
> >>>>
> >>
>
>