On Sunday, July 5, 2015, Baldur Norddahl <baldur.nordd...@gmail.com> wrote:
> 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. > > 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 <o...@delong.com <javascript:;>> > 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 <jmo...@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 <o...@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 <jmo...@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 <o...@delong.com > <javascript:;>> 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 <jmo...@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. 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 <m...@beckman.org > <javascript:;>> 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 <jmo...@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 <m...@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. 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 <jmo...@atcnetworks.net > <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 <m...@beckman.org > <javascript:;>> 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 :) > > >>>> > > >> > > > > >
