But what is the "best compromise" strategy? Dual stack + CGN? Some kind of intelligent 6to4 NAT? Thanks, Joshua Moore Network Engineer ATC Broadband 912.632.3161 On Jul 4, 2015, at 10:35 PM, Ca By <cb.list6@gmail.com<mailto:cb.list6@gmail.com>> wrote: On Saturday, July 4, 2015, Josh Moore <jmoore@atcnetworks.net<mailto:jmoore@atcnetworks.net>> wrote: Traditional dual stack deployments implement both IPv4 and IPv6 to the CPE. Consider the following: An ISP is at 90% IPv4 utilization and would like to deploy dual stack with the purpose of allowing their subscriber base to continue to grow regardless of the depletion of the IPv4 space. Current dual stack best practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If this is the case, and BOTH are still required, then how does IPv6 help with the v4 address depletion crisis? Many sites and services would still need legacy IPv4 compatibility. Sure, CGN technology may be a solution but what about applications that need direct IPv4 connectivity without NAT? It seems that there should be a mechanism to enable on-demand and efficient IPv4 address consumption ONLY when needed. My question is this: What, if any, solutions like this exist? If no solution exists then what is the next best thing? What would the overall IPv6 migration strategy and goal be? Sorry for the length of this email but these are legitimate concerns and while I understand the need for IPv6 and the importance of getting there; I don't understand exactly HOW that can be done considering the immediate issue: IPv4 depletion. Thanks Joshua Moore Network Engineer ATC Broadband 912.632.3161 Yep, dual-stack does not solve problems for eyeball networks. This is why eyeball networks use ds-lite, 464xlat, and map. Each requires some sort of compromise. At the end of the day, we all need to reject 'direct ipv4', it is an invalid requirement that cannot be supported at scale over time.

Josh, The price of IPv4 addresses will go up now that supply is seriously constrained. The price increase will push information producers, who generally are the people needing public IPv4 space, over to IPv6, which is plentiful. This will create a class of services that is IPv6-only (e.g., Microsoft DirectAccess), which will encourage IPv4 information consumers to dual-stack. IPv4-only consumers will find themselves in an information ghetto, but one that they can easily get out of by just exerting a little effort. In the worst case scenario, an ISP customer stuck behind an IPv4 Internet connection can simply tunnel to IPv6 via one of the free tunnelbroker services such as HE.net<http://HE.net>’s tunnelbroker.net<http://tunnelbroker.net>. This is a problem that will solve itself in a natural, and capitalist, way. Market pressures will push everyone to IPv6, and nobody need be left behind. I predict some enterprising inventor will create (if they haven’t already) a cheap IPv6 appliance akin to Roku or Apple TV that anyone can just drop onto their network to become IPv6 enabled via a tunnelbroker. In fact, I show just how to do this using a $99 Apple Airport Express in my three-hour online course “Build your own IPv6 Lab” (http://windowsitpro.com/build-your-own-ipv6-lab-and-become-ipv6-guru-demand). If you don’t have an IPv6 lab yet, you should set one up ASAP. That’s the easiest way to get your head around all IPv6 issues. HE.net<http://HE.net> also has a very nice certification program that will take you through all the basic tasks of being IPv6 enabled both as an information producer and a consumer. -mel On Jul 4, 2015, at 8:41 PM, John Levine <johnl@iecc.com<mailto:johnl@iecc.com>> wrote: In article <F78EE6A5-D4E5-435B-A6BF-BB6A84223415@atcnetworks.net<mailto:F78EE6A5-D4E5-435B-A6BF-BB6A84223415@atcnetworks.net>> you write: But what is the "best compromise" strategy? Dual stack + CGN? Some kind of intelligent 6to4 NAT? Depends on the application(s). One that seems to work OK is to dual stack everyone and put them behind a NAT unless they ask to have a private IP. Depending on who your customers are, charge more for a private IP, or if you want to look less obviously venal, say you're offering a discount to customers who move their applications that require end-to-end addressing to IPv6. It is my strong impression that people who think they're 100% IPv6 enabled still often need a little IPv4 (NAT OK) for bootstrapping and the like, so you need to dual stack no matter what you do. If you do charge extra for IPv4, that makes it easier to go buy used IPv4 space on the aftermarket. R's, John

I don't have any skin in the game, but the following devices popped into my head while reading that paragraph: http://www.gogo6.com/gogoware/gogoserver http://www.gogo6.com/gogoware/gogocpe Jima On 2015-07-05 00:13, Mel Beckman wrote:

I predict some enterprising inventor will create (if they haven’t already) a cheap IPv6 appliance akin to Roku or Apple TV that anyone can just drop onto their network to become IPv6 enabled via a tunnelbroker.

Creating this in a test lab is mandatory for a successful migration. 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. Seems that my initial thoughts of dual stack and v4 overloading using private addresses to ensure compatibility is the way to go. Any input on good, possibly application aware, CGN solutions? Maybe even some policy-based DHCP/NAT product? Thanks, Joshua Moore Network Engineer ATC Broadband 912.632.3161

On Jul 5, 2015, at 5:35 AM, William Waites <wwaites@tardis.ed.ac.uk> wrote:

On Sun, 5 Jul 2015 06:13:52 +0000, Mel Beckman <mel@beckman.org> said:

...

In fact, I show just how to do this using a $99 Apple Airport Express in my three-hour online course “Build your own IPv6 Lab”

An anectode about this, maybe out of date, maybe not. 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.

-w

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> 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 :)

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> 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@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@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 :)

You must know different WISPs than I know (and I know hundreds). Most WISPs use IPv4 publicly, no IPv6 and don't have any boxes capable of synced NAT tables. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Mel Beckman" <mel@beckman.org> To: "Josh Moore" <jmoore@atcnetworks.net> Cc: johnl@iecc.com, nanog@nanog.org Sent: Sunday, July 5, 2015 9:43:40 AM Subject: Re: Dual stack IPv6 for IPv4 depletion 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@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@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@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@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 :)

On Jul 5, 2015, at 11:35 AM, Mel Beckman <mel@beckman.org> wrote:

I guess the WISPs I advise get better advice :)

I think this is a key item for people to have in mind. We can all follow poor advice and add in new layers of NATs, possibly including certain applications within the NAT cone, or we can deliver DS, or DS-like service via several technologies. There are a lot of devices that can do NAT from roll your own Linux or pfSense style up to commercial solutions that vendors will sell you. (I recall cisco pitching the ASR1K for this years ago). You could even use something like LISP to do these redundancy things within your network. I would treat NAT the same way people treat CDNs which is find the large destinations and encourage people to use IPv6 for those. Looking at the “top sites” here: http://www.alexa.com/topsites Almost all of them are IPv6 enabled. You can even poke at sites with external tools like this: http://ipv6-test.com/validate.php Frank Bulk also monitors most of the major carrier sites for their IPv6 reliability and stability. He often gets me to contact our IT department to address the issues they have coping with the traffic volumes involved on the IPv6 side for the www.us.ntt.net and www.ntt.net sites. (and yes frank, I got your email and texts yesterday :) ) I would say there is no one right/wrong way to do this, but getting the core of your network IPv6 enabled first then pushing to your edges is a must-do item for the upcoming quarter or two. I was once advised on technical issues where I explained in perfect technical detail the problems and solution path, but the management started talking about the optics of the issue. Take advantage of the NBC, etc coverage to ensure these priorities are taken care of. This may feel like stooping low to some people, but it’s important to get any IPv6 items off your todo list. There is a great ipv6-ops list as well out there where detailed questions can be asked and answered amongst those that are doing similar things. While I dislike what T-Mobile USA has done from a technical side, their success shows that the IPv6 only edge *is* possible. This means we can take away the idea that we *must* have IPv4 for a device to be reachable/considered “online”. I anxiously await the results of the apple/IPv6/iOS9 changeover and the increased traffic that will occur as a result. I think 2016 will drive the traffic levels to many multiples where they are now and much closer to parity on the global backbones. - Jared

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@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@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@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@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@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 :)

NAT at the POP seems much more feasible, then. Wherever your chokepoint is in network redundancy, do the NAT there. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Owen DeLong" <owen@delong.com> To: "Josh Moore" <jmoore@atcnetworks.net> Cc: johnl@iecc.com, nanog@nanog.org Sent: Sunday, July 5, 2015 12:29:21 PM Subject: Re: Dual stack IPv6 for IPv4 depletion 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@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@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@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@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@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@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 :)

On Sun, 5 Jul 2015 18:25:26 +0000, Josh Moore <jmoore@atcnetworks.net> said: > So basically what you are telling me is that the NAT gateway > needs to be centrally aggregated. If you must do NAT it should be as close to the edge as possible. Today that's usually at the CPE. Maybe tomorrow that's one hop upstream at the distribution router. That way the core remains clean and doesn't accumulate state or have to deal with asymmetries. -w

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> 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> 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> 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@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@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@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@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@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@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 :)

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@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@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@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@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@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@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@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@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@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@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@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 :)

I was hoping to find a solution that maybe utilized some kind of session sync or something of that matter allowing for multiple entry and exit points (asymmetric routing). Thanks, Joshua Moore Network Engineer ATC Broadband 912.632.3161

On Jul 5, 2015, at 3:10 PM, Owen DeLong <owen@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@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@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@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@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@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@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@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@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@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@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 :)

Theoretically it should be possible with this on MPLS enabled devices. The "HA link" could then ride on top of the MPLS core redundancy alongside public outside NAT traffic and inside private traffic. The good thing is that most of my customer access (DSL, cable, T1) is designed with established distribution points. Implementing sectional CGN at those points would be a good first step. We need to just get the policy side of things worked out on how we are going to automate the provisioning internally. Thanks for all the input. Thanks, Joshua Moore Network Engineer ATC Broadband 912.632.3161

On Jul 5, 2015, at 3:55 PM, Mel Beckman <mel@beckman.org> wrote:

Many firewalls will do state sync across an HA link. This works fine as long as you use BGP to ensure internet routing of your IPv4 to all gateways. But then the HA link is the single point of failure. I think the best you can hope for is that the importance of IPv4 NAT will diminish over time. One day it will be just a memory, like SNA :)

-mel beckman

...

On Jul 5, 2015, at 12:37 PM, Josh Moore <jmoore@atcnetworks.net> wrote:

I was hoping to find a solution that maybe utilized some kind of session sync or something of that matter allowing for multiple entry and exit points (asymmetric routing).

Thanks,

Joshua Moore Network Engineer ATC Broadband 912.632.3161

...

On Jul 5, 2015, at 3:10 PM, Owen DeLong <owen@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@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@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@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@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@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@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@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@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@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@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 :)

Hi,

I was hoping to find a solution that maybe utilized some kind of session sync or something of that matter [...]

And the session sync is then the weakest link. I have seen a cluster of Nexus switches crash in sync when saving the configuration (which was synced). True redundancy is only when the elements can operate independently of each other, and the syncing makes them dependent and vulnerable. Cheers, Sander

I believe he (at least someone) was looking for recommendations to CGN type devices. Many can do NAT, but looking for something a bit more intelligent. Your standard residential user may not understand, but would also be unwilling to pay any difference. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Mel Beckman" <mel@beckman.org> To: "Josh Moore" <jmoore@atcnetworks.net> Cc: johnl@iecc.com, nanog@nanog.org Sent: Sunday, July 5, 2015 9:12:37 AM Subject: Re: Dual stack IPv6 for IPv4 depletion 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@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@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 :)

Public or private you have the same issues of not putting too many Google requests through the same public v4 address, keeping things at multiple egress points in sync, etc. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Mel Beckman" <mel@beckman.org> To: "Mike Hammett" <nanog@ics-il.net> Cc: "Nanog" <nanog@nanog.org> Sent: Sunday, July 5, 2015 9:47:14 AM Subject: Re: Dual stack IPv6 for IPv4 depletion That's only an issue if you distribute a public IPv4 address to each customer. If you use private addressing in the core, ordinary NAT works if you're not a carrier-grade provider, and even then it can be practical in many cases. CGN is a solution for providers not willing to migrate to a private core. -mel beckman

On Jul 5, 2015, at 7:35 AM, Mike Hammett <nanog@ics-il.net> wrote:

I believe he (at least someone) was looking for recommendations to CGN type devices. Many can do NAT, but looking for something a bit more intelligent. Your standard residential user may not understand, but would also be unwilling to pay any difference.

----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

----- Original Message -----

From: "Mel Beckman" <mel@beckman.org> To: "Josh Moore" <jmoore@atcnetworks.net> Cc: johnl@iecc.com, nanog@nanog.org Sent: Sunday, July 5, 2015 9:12:37 AM Subject: Re: Dual stack IPv6 for IPv4 depletion

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@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@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 :)

On Jul 5, 2015, at 5:32 AM, William Waites <wwaites@tardis.ed.ac.uk> wrote:

On Sun, 5 Jul 2015 06:13:52 +0000, Mel Beckman <mel@beckman.org> said:

...

In fact, I show just how to do this using a $99 Apple Airport Express in my three-hour online course “Build your own IPv6 Lab”

An anectode about this, maybe out of date, maybe not. 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.

The airport devices/airport express class are not that good of devices as the embedded software doesn’t handle a lot of traffic or long uptime well. Most devices that are over 3 years old likely are not suitable for IPv6 testing aside from understanding what is broken. Keep in mind that software on a CPE device may be 6 months out of date by the time it comes out of a container stateside. Expecting people to use tunnels, etc doesn’t really scale properly. I do wish that I could get static IPv6 prefixes along with my static IPv4 at home, but having IPv6 at all took precedence. - Jared

That's only an issue with airport devices and PPPoE. I can confirm it does native DHCPv6-PD otherwise. On Sun, Jul 5, 2015 at 5:32 AM, William Waites <wwaites@tardis.ed.ac.uk> wrote:

On Sun, 5 Jul 2015 06:13:52 +0000, Mel Beckman <mel@beckman.org> said:

> In fact, I show just how to do this using a $99 Apple Airport > Express in my three-hour online course “Build your own IPv6 Lab”

An anectode about this, maybe out of date, maybe not. 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.

-w

On Jul 4, 2015, at 23:51 , Valdis.Kletnieks@vt.edu wrote:

On 05 Jul 2015 03:41:26 -0000, "John Levine" said:

...

Depends on the application(s). One that seems to work OK is to dual stack everyone and put them behind a NAT unless they ask to have a private IP.

Put their IPv4 behind a NAT and a globally routed /56.

There, FTFY. :)

Or better yet globally routed /48. /56 is still a bad idea. Owen

In message <559DB604.8060901@lugosys.com>, "Israel G. Lugo" writes:

On 07/05/2015 06:26 PM, Owen DeLong wrote:

...

...

On Jul 4, 2015, at 23:51 , Valdis.Kletnieks@vt.edu wrote:

Put their IPv4 behind a NAT and a globally routed /56.

There, FTFY. :) Or better yet globally routed /48.

/56 is still a bad idea.

Owen I've read this many times and am aware it's the standard recommendation. Makes perfect sense for the customer side, as it would be hard for him to subnet properly otherwise.

Doesn't seem to make sense at all for the ISP side, though. Standard allocation /32. Giving out /48s. Even if we leave out proper subnet organization and allocate fully densely, that's at most 65,536 subnets. Not a very large ISP.

/32 is not the standard allocation. It is the *minimum* allocation for a ISP. ISPs are expected to ask for *more* addresses to meet their actual requirements.

You can say "get more blocks", or "get larger blocks". Sure, let's give each ISP a /24. That lets them have up to 16M customers (and that's still subnetting densely, which sucks rather a lot). Doesn't leave that many allocation blocks for the RIRs to hand out, though.

Which in part is why the minimum is a /32.

People usually look at IPv6 and focus on the vast numbers of individual addresses. Naysayers usually get shot down with some quote mentioning the number of atoms in the universe or some such. Personally, I think that's a red herring; the real problem is subnets. At this rate I believe subnets will become the scarce resource sooner or later.

No. People look at /48's for sites. 35,184,372,088,832 /48 sites out of the 1/8th of the total IPv6 space currently in use. That is 35 trillion sites and if we use that up we can look at using a different default size in the next 1/8th.

Sure, in the LAN side we'll never have to worry about address scarcity. But what's the point of having addresses to spare, if it just means you've got to start worrying about subnet scarcity? If the goal was never having to worry about counting anymore, I propose that 128 bits is far too little. Should've gone a full 256 and be done with it.

Regards, Israel G. Lugo

P.S.: I'm 100% for IPv6 and $dayjob has been fully dual stacked for 10 years now. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Isn't /56 the standard end-user allocation? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Israel G. Lugo" <israel.lugo@lugosys.com> To: "Mark Andrews" <marka@isc.org> Cc: "NANOG" <nanog@nanog.org> Sent: Wednesday, July 8, 2015 7:45:50 PM Subject: Re: Dual stack IPv6 for IPv4 depletion On 07/09/2015 12:59 AM, Mark Andrews wrote:

In message <559DB604.8060901@lugosys.com>, "Israel G. Lugo" writes:

...

Doesn't seem to make sense at all for the ISP side, though. Standard allocation /32. Giving out /48s. Even if we leave out proper subnet organization and allocate fully densely, that's at most 65,536 subnets. Not a very large ISP. /32 is not the standard allocation. It is the *minimum* allocation for a ISP. ISPs are expected to ask for *more* addresses to meet their actual requirements.

Thank you for pointing that out. When speaking of /32 I was referring specifically to RIPE policy, with which I am more familiar: "Initial allocation size" for a LIR is /32, extensive to a /29 with minimal bureaucracy. Perhaps I should have said "default allocation". I understand ISPs should ask for more addresses; however, even e.g. a /24 (8x /32) seems to me like it could be "roomier".

...

People usually look at IPv6 and focus on the vast numbers of individual addresses. Naysayers usually get shot down with some quote mentioning the number of atoms in the universe or some such. Personally, I think that's a red herring; the real problem is subnets. At this rate I believe subnets will become the scarce resource sooner or later. No. People look at /48's for sites. 35,184,372,088,832 /48 sites out of the 1/8th of the total IPv6 space currently in use. That is 35 trillion sites and if we use that up we can look at using a different default size in the next 1/8th. Yes, if we look at end sites individually. My hypothesis is that these astronomic numbers are in fact misleading. There isn't, after all, one single ISP-Of-The-World, with The-One-Big-Router.

We must divide the addresses by ISPs/LIRs, and so on. Several bits in the prefix must be used for subaddressing. A larger ISP will probably want to further subdivide its addressing by region, and so on. With subdivisions comes "waste". Which is something we don't need to worry about at the LAN level, but it would be nice to have that level of comfort at the subaddressing level as well. Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so: - I reserve 1 bit for future allocation schemes, leaving me a /33; - 2 bits for network type (infrastructure, residential, business, LTE): /35 - 3 bits for geographic region, state, whatever: /38 - 5 bits for PoP, or city: /43 This leaves me 5 bits for end sites: no joy. Granted, this is just a silly example, and I don't have to divide my address space like this. In fact, I really can't, unless I want to have more than 32 customers per city. But I don't think it's a very far-fetched example. Perhaps I'm missing something obvious here, but it seems to me that it would've been nice to have these kinds of possibilities, and more. It seems counterintuitive, especially given the "IPv6 way of thinking" which is normally encouraged: "stop counting beans, this isn't IPv4". Regards, Israel G. Lugo

/56 even seems a bit excessive for a residential user, but *shrugs* ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Mel Beckman" <mel@beckman.org> To: "Mike Hammett" <nanog@ics-il.net> Cc: "NANOG" <nanog@nanog.org> Sent: Wednesday, July 8, 2015 8:11:05 PM Subject: Re: Dual stack IPv6 for IPv4 depletion Yes. The v6 allocation standards are simple, but can alarming to old-schoolers who have not really thought through the math. A customer gets a /56, which gives them 256 /64 subnets for their own internal use. That accommodates all except the largest customers, and those have the option of getting a /32, which gives them 4.2 billion /64s. ISPs each get a /32 by default, which supports 16.7 million /56 customers. And, of course, the /32 ISP allocation accommodates 4.2 billion ISPs. I don't see the fear. These are just integers, after all. Nothing is really "going to waste". -mel beckman

On Jul 8, 2015, at 5:58 PM, Mike Hammett <nanog@ics-il.net> wrote:

Isn't /56 the standard end-user allocation?

----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

Midwest Internet Exchange http://www.midwest-ix.com

----- Original Message -----

From: "Israel G. Lugo" <israel.lugo@lugosys.com> To: "Mark Andrews" <marka@isc.org> Cc: "NANOG" <nanog@nanog.org> Sent: Wednesday, July 8, 2015 7:45:50 PM Subject: Re: Dual stack IPv6 for IPv4 depletion

...

...

On 07/09/2015 12:59 AM, Mark Andrews wrote: In message <559DB604.8060901@lugosys.com>, "Israel G. Lugo" writes: Doesn't seem to make sense at all for the ISP side, though. Standard allocation /32. Giving out /48s. Even if we leave out proper subnet organization and allocate fully densely, that's at most 65,536 subnets. Not a very large ISP. /32 is not the standard allocation. It is the *minimum* allocation for a ISP. ISPs are expected to ask for *more* addresses to meet their actual requirements.

Thank you for pointing that out. When speaking of /32 I was referring specifically to RIPE policy, with which I am more familiar: "Initial allocation size" for a LIR is /32, extensive to a /29 with minimal bureaucracy. Perhaps I should have said "default allocation".

I understand ISPs should ask for more addresses; however, even e.g. a /24 (8x /32) seems to me like it could be "roomier".

...

...

People usually look at IPv6 and focus on the vast numbers of individual addresses. Naysayers usually get shot down with some quote mentioning the number of atoms in the universe or some such. Personally, I think that's a red herring; the real problem is subnets. At this rate I believe subnets will become the scarce resource sooner or later. No. People look at /48's for sites. 35,184,372,088,832 /48 sites out of the 1/8th of the total IPv6 space currently in use. That is 35 trillion sites and if we use that up we can look at using a different default size in the next 1/8th. Yes, if we look at end sites individually. My hypothesis is that these astronomic numbers are in fact misleading. There isn't, after all, one single ISP-Of-The-World, with The-One-Big-Router.

We must divide the addresses by ISPs/LIRs, and so on. Several bits in the prefix must be used for subaddressing. A larger ISP will probably want to further subdivide its addressing by region, and so on. With subdivisions comes "waste". Which is something we don't need to worry about at the LAN level, but it would be nice to have that level of comfort at the subaddressing level as well.

Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so:

- I reserve 1 bit for future allocation schemes, leaving me a /33; - 2 bits for network type (infrastructure, residential, business, LTE): /35 - 3 bits for geographic region, state, whatever: /38 - 5 bits for PoP, or city: /43

This leaves me 5 bits for end sites: no joy.

Granted, this is just a silly example, and I don't have to divide my address space like this. In fact, I really can't, unless I want to have more than 32 customers per city. But I don't think it's a very far-fetched example.

Perhaps I'm missing something obvious here, but it seems to me that it would've been nice to have these kinds of possibilities, and more. It seems counterintuitive, especially given the "IPv6 way of thinking" which is normally encouraged: "stop counting beans, this isn't IPv4".

Regards, Israel G. Lugo

Matthew, This is where we have to excise our IPv4 "fear of waste" reflex. A /64 subnet, for example, doesn't waste anything material -- these are just integers, after all. If the number of integers was scarce, as they are with IPv4, then yes, we must conserve. But IPv6 is well thought out and it's design carefully considered practical IP allocation requirements before deciding on 128 bit addresses. It's enough. Really. -mel beckman

On Jul 8, 2015, at 6:46 PM, Matthew Kaufman <matthew@matthew.at> wrote:

What's excessive is >32 bits for a subnet.

No reason subnets should have been as big as they are. Bad for local forwarding decisions, waste of bits, etc.

Nobody has a physical subnet technology that works for more than a few thousand hosts anyway.

Matthew Kaufman

(Sent from my iPhone)

...

On Jul 8, 2015, at 6:19 PM, Mike Hammett <nanog@ics-il.net> wrote:

/56 even seems a bit excessive for a residential user, but *shrugs*

----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

Midwest Internet Exchange http://www.midwest-ix.com

----- Original Message -----

From: "Mel Beckman" <mel@beckman.org> To: "Mike Hammett" <nanog@ics-il.net> Cc: "NANOG" <nanog@nanog.org> Sent: Wednesday, July 8, 2015 8:11:05 PM Subject: Re: Dual stack IPv6 for IPv4 depletion

Yes. The v6 allocation standards are simple, but can alarming to old-schoolers who have not really thought through the math.

A customer gets a /56, which gives them 256 /64 subnets for their own internal use. That accommodates all except the largest customers, and those have the option of getting a /32, which gives them 4.2 billion /64s.

ISPs each get a /32 by default, which supports 16.7 million /56 customers. And, of course, the /32 ISP allocation accommodates 4.2 billion ISPs.

I don't see the fear. These are just integers, after all. Nothing is really "going to waste".

-mel beckman

...

On Jul 8, 2015, at 5:58 PM, Mike Hammett <nanog@ics-il.net> wrote:

Isn't /56 the standard end-user allocation?

----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

Midwest Internet Exchange http://www.midwest-ix.com

----- Original Message -----

From: "Israel G. Lugo" <israel.lugo@lugosys.com> To: "Mark Andrews" <marka@isc.org> Cc: "NANOG" <nanog@nanog.org> Sent: Wednesday, July 8, 2015 7:45:50 PM Subject: Re: Dual stack IPv6 for IPv4 depletion

...

...

On 07/09/2015 12:59 AM, Mark Andrews wrote: In message <559DB604.8060901@lugosys.com>, "Israel G. Lugo" writes: Doesn't seem to make sense at all for the ISP side, though. Standard allocation /32. Giving out /48s. Even if we leave out proper subnet organization and allocate fully densely, that's at most 65,536 subnets. Not a very large ISP. /32 is not the standard allocation. It is the *minimum* allocation for a ISP. ISPs are expected to ask for *more* addresses to meet their actual requirements.

Thank you for pointing that out. When speaking of /32 I was referring specifically to RIPE policy, with which I am more familiar: "Initial allocation size" for a LIR is /32, extensive to a /29 with minimal bureaucracy. Perhaps I should have said "default allocation".

I understand ISPs should ask for more addresses; however, even e.g. a /24 (8x /32) seems to me like it could be "roomier".

...

...

People usually look at IPv6 and focus on the vast numbers of individual addresses. Naysayers usually get shot down with some quote mentioning the number of atoms in the universe or some such. Personally, I think that's a red herring; the real problem is subnets. At this rate I believe subnets will become the scarce resource sooner or later. No. People look at /48's for sites. 35,184,372,088,832 /48 sites out of the 1/8th of the total IPv6 space currently in use. That is 35 trillion sites and if we use that up we can look at using a different default size in the next 1/8th. Yes, if we look at end sites individually. My hypothesis is that these astronomic numbers are in fact misleading. There isn't, after all, one single ISP-Of-The-World, with The-One-Big-Router.

We must divide the addresses by ISPs/LIRs, and so on. Several bits in the prefix must be used for subaddressing. A larger ISP will probably want to further subdivide its addressing by region, and so on. With subdivisions comes "waste". Which is something we don't need to worry about at the LAN level, but it would be nice to have that level of comfort at the subaddressing level as well.

Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so:

- I reserve 1 bit for future allocation schemes, leaving me a /33; - 2 bits for network type (infrastructure, residential, business, LTE): /35 - 3 bits for geographic region, state, whatever: /38 - 5 bits for PoP, or city: /43

This leaves me 5 bits for end sites: no joy.

Granted, this is just a silly example, and I don't have to divide my address space like this. In fact, I really can't, unless I want to have more than 32 customers per city. But I don't think it's a very far-fetched example.

Perhaps I'm missing something obvious here, but it seems to me that it would've been nice to have these kinds of possibilities, and more. It seems counterintuitive, especially given the "IPv6 way of thinking" which is normally encouraged: "stop counting beans, this isn't IPv4".

Regards, Israel G. Lugo

excise verb 1. To excise is defined as to cut out surgically. When a tumor is surgically cut out, this is an example of excise. Exercise wouldn't work. That would mean "repeatedly employ the fear". Exorcise (as in The Exorcist) might serve, except the IPv4 "fear of waste" is not a demon. It's a good thing. -mel beckman On Jul 8, 2015, at 6:59 PM, Paul Ferguson <fergdawgster@mykolab.com<mailto:fergdawgster@mykolab.com>> wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 7/8/2015 6:51 PM, Mel Beckman wrote: This is where we have to excise our IPv4 "fear of waste" reflex. Excise or exercise? I am partially serious. - - ferg - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlWd1VQACgkQKJasdVTchbLULwEAjnnJgH153ewFHb5ZONrUivCS LOjg+GByXK/dzeFIgDIBANc9hmFO+2Kd/vxK47ZVvgNuzy3cqTJYxrV6zYZ8IODi =OzVs -----END PGP SIGNATURE-----

On Wed, 08 Jul 2015 22:13:24 -0400, <Valdis.Kletnieks@vt.edu> wrote:

On Wed, 08 Jul 2015 20:19:52 -0500, Mike Hammett said:

...

/56 even seems a bit excessive for a residential user, but *shrugs*

It goes pretty quick when each WNDR3800 running CeroWRT will chew through 4 bits worth of subnets just by powering on, and even more if you start doing any VLAN stuff.... and then you put a second one at the far end of the house for better coverage and it asks for its own PD space from your main one.....

If everyone wants their networks hobbled by shitty software routing, sure. There are plenty who stack their "wireless extension" LAN-WAN (creating double NAT) because they simply don't know jack about networking. There are over 100 million "home networks" in the country that are literally 100% out-of-the-box defaults. It comes out of the box, the color coded cables are connected to the color coded ports according to the Ikea pictorial diagram. And it better Just Work(tm), because they will never understand to configure any part of it -- doubly so for the *networking*. We are years (DECADES) from a multi-network default. Hell, it's been 20 years and IPv6 is still not more a foot off the ground. (plus, it's been rewritten a dozen times.)

Only if you are trying to prevent IPv6 from reaching its full potential. Owen

On Jul 8, 2015, at 17:57 , Mike Hammett <nanog@ics-il.net> wrote:

Isn't /56 the standard end-user allocation?

----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

Midwest Internet Exchange http://www.midwest-ix.com

----- Original Message -----

From: "Israel G. Lugo" <israel.lugo@lugosys.com> To: "Mark Andrews" <marka@isc.org> Cc: "NANOG" <nanog@nanog.org> Sent: Wednesday, July 8, 2015 7:45:50 PM Subject: Re: Dual stack IPv6 for IPv4 depletion

On 07/09/2015 12:59 AM, Mark Andrews wrote:

...

In message <559DB604.8060901@lugosys.com>, "Israel G. Lugo" writes:

...

Doesn't seem to make sense at all for the ISP side, though. Standard allocation /32. Giving out /48s. Even if we leave out proper subnet organization and allocate fully densely, that's at most 65,536 subnets. Not a very large ISP. /32 is not the standard allocation. It is the *minimum* allocation for a ISP. ISPs are expected to ask for *more* addresses to meet their actual requirements.

Thank you for pointing that out. When speaking of /32 I was referring specifically to RIPE policy, with which I am more familiar: "Initial allocation size" for a LIR is /32, extensive to a /29 with minimal bureaucracy. Perhaps I should have said "default allocation".

I understand ISPs should ask for more addresses; however, even e.g. a /24 (8x /32) seems to me like it could be "roomier".

...

...

People usually look at IPv6 and focus on the vast numbers of individual addresses. Naysayers usually get shot down with some quote mentioning the number of atoms in the universe or some such. Personally, I think that's a red herring; the real problem is subnets. At this rate I believe subnets will become the scarce resource sooner or later. No. People look at /48's for sites. 35,184,372,088,832 /48 sites out of the 1/8th of the total IPv6 space currently in use. That is 35 trillion sites and if we use that up we can look at using a different default size in the next 1/8th. Yes, if we look at end sites individually. My hypothesis is that these astronomic numbers are in fact misleading. There isn't, after all, one single ISP-Of-The-World, with The-One-Big-Router.

We must divide the addresses by ISPs/LIRs, and so on. Several bits in the prefix must be used for subaddressing. A larger ISP will probably want to further subdivide its addressing by region, and so on. With subdivisions comes "waste". Which is something we don't need to worry about at the LAN level, but it would be nice to have that level of comfort at the subaddressing level as well.

Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so:

- I reserve 1 bit for future allocation schemes, leaving me a /33; - 2 bits for network type (infrastructure, residential, business, LTE): /35 - 3 bits for geographic region, state, whatever: /38 - 5 bits for PoP, or city: /43

This leaves me 5 bits for end sites: no joy.

Granted, this is just a silly example, and I don't have to divide my address space like this. In fact, I really can't, unless I want to have more than 32 customers per city. But I don't think it's a very far-fetched example.

Perhaps I'm missing something obvious here, but it seems to me that it would've been nice to have these kinds of possibilities, and more. It seems counterintuitive, especially given the "IPv6 way of thinking" which is normally encouraged: "stop counting beans, this isn't IPv4".

Regards, Israel G. Lugo

I wasn't aware that residential users had (intentionally) multiple layers of routing within the home. I'm also not sure what address length has to do with routability, other than networks filtering prefix lengths. If that's an issue, that customer is covered by the ISP's larger allocation, or they get their own PI space if they're BGPing. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Karl Auer" <kauer@biplane.com.au> To: nanog@nanog.org Sent: Wednesday, July 8, 2015 8:36:41 PM Subject: Re: Dual stack IPv6 for IPv4 depletion On Wed, 2015-07-08 at 19:57 -0500, Mike Hammett wrote:

Isn't /56 the standard end-user allocation?

No - it's just a common one. And a bad one. /48s for all opens up a whole different world of end-user reachability, routability and flexibility that a mere /56 does not. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882

On Wed, 2015-07-08 at 21:03 -0500, Mike Hammett wrote:

I wasn't aware that residential users had (intentionally) multiple layers of routing within the home.

You, we, all of us have to stop using the present to limit the future. What IS should not be used to define what SHOULD BE. What people NOW HAVE in their homes should not be used to dictate to them what they CAN HAVE in their homes, which is what you do when you provide them only with non-globally-routable address space (IPv4 NAT), or too few subnets (IPv6 /56) to name just two examples. Multiple layers of routing might not be what is now in the home, but it doesn't take that much imagination to envision a future where there are hundreds, or even thousands of separate networks in the average home, some permanent, some ephemeral, and quite possibly all requiring end-to-end connectivity into the wider Internet. Taking into account just a few current technologies (virtual machines, car networks, personal networks, guest networks, entertainment systems) and fast-forwarding just a few years it's easy to imagine tens of subnets being needed - so it's not much of a leap to hundreds. And if we can already dimly see a future where hundreds might be needed, history tells us that there will probably be applications that need thousands. Unless of course we decide now that we don't WANT that. Then we should make it hard for it to happen by applying entirely arbitrary brakes like "/48 sounds too big to me, let's make it 1/256th of that." Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882

On Wed, Jul 8, 2015 at 7:49 PM, Karl Auer <kauer@biplane.com.au> wrote:

On Wed, 2015-07-08 at 21:03 -0500, Mike Hammett wrote:

...

I wasn't aware that residential users had (intentionally) multiple layers of routing within the home.

No, what they often have is multiple layers of nat. I was at a hotel once that had plugged in 12 APs, serially, wan, to lan, to wan, to lan, to wan ports... because the Internet is a series of tubes, right?

You, we, all of us have to stop using the present to limit the future. What IS should not be used to define what SHOULD BE.

What people NOW HAVE in their homes should not be used to dictate to them what they CAN HAVE in their homes, which is what you do when you provide them only with non-globally-routable address space (IPv4 NAT), or too few subnets (IPv6 /56) to name just two examples.

Multiple layers of routing might not be what is now in the home, but it doesn't take that much imagination to envision a future where there are hundreds, or even thousands of separate networks in the average home, some permanent, some ephemeral, and quite possibly all requiring end-to-end connectivity into the wider Internet. Taking into account just a few current technologies (virtual machines, car networks, personal networks, guest networks, entertainment systems) and fast-forwarding just a few years it's easy to imagine tens of subnets being needed - so it's not much of a leap to hundreds. And if we can already dimly see a future where hundreds might be needed, history tells us that there will probably be applications that need thousands.

Unless of course we decide now that we don't WANT that. Then we should make it hard for it to happen by applying entirely arbitrary brakes like "/48 sounds too big to me, let's make it 1/256th of that."

In my case I have completely abandoned much of the debris of ipv4 and ipv6 - using self assigned /128s and a mesh routing protocol everywhere, giving up on multicast as we knew it, and all I need is one /64 to route my (almost entirely wireless) world. Somehow I doubt this will become a common option for others, but it sure is easier than navigating the slew of standards, configuring centralized services, and casting and configuring limited and highly dynamic ipv6 subnets around.

Regards, K.

-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389

GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882

-- Dave Täht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast

Don't confuse someone's poor design with design goals. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Dave Taht" <dave.taht@gmail.com> To: "Karl Auer" <kauer@biplane.com.au> Cc: "NANOG" <nanog@nanog.org> Sent: Wednesday, July 8, 2015 10:48:26 PM Subject: Re: Dual stack IPv6 for IPv4 depletion On Wed, Jul 8, 2015 at 7:49 PM, Karl Auer <kauer@biplane.com.au> wrote:

On Wed, 2015-07-08 at 21:03 -0500, Mike Hammett wrote:

...

I wasn't aware that residential users had (intentionally) multiple layers of routing within the home.

No, what they often have is multiple layers of nat. I was at a hotel once that had plugged in 12 APs, serially, wan, to lan, to wan, to lan, to wan ports... because the Internet is a series of tubes, right?

You, we, all of us have to stop using the present to limit the future. What IS should not be used to define what SHOULD BE.

What people NOW HAVE in their homes should not be used to dictate to them what they CAN HAVE in their homes, which is what you do when you provide them only with non-globally-routable address space (IPv4 NAT), or too few subnets (IPv6 /56) to name just two examples.

Multiple layers of routing might not be what is now in the home, but it doesn't take that much imagination to envision a future where there are hundreds, or even thousands of separate networks in the average home, some permanent, some ephemeral, and quite possibly all requiring end-to-end connectivity into the wider Internet. Taking into account just a few current technologies (virtual machines, car networks, personal networks, guest networks, entertainment systems) and fast-forwarding just a few years it's easy to imagine tens of subnets being needed - so it's not much of a leap to hundreds. And if we can already dimly see a future where hundreds might be needed, history tells us that there will probably be applications that need thousands.

Unless of course we decide now that we don't WANT that. Then we should make it hard for it to happen by applying entirely arbitrary brakes like "/48 sounds too big to me, let's make it 1/256th of that."

In my case I have completely abandoned much of the debris of ipv4 and ipv6 - using self assigned /128s and a mesh routing protocol everywhere, giving up on multicast as we knew it, and all I need is one /64 to route my (almost entirely wireless) world. Somehow I doubt this will become a common option for others, but it sure is easier than navigating the slew of standards, configuring centralized services, and casting and configuring limited and highly dynamic ipv6 subnets around.

Regards, K.

-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389

GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882

-- Dave Täht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast

In message <op.x1hpayv0tfhldh@rbeam.xactional.com>, "Ricky Beam" writes:

On Wed, 08 Jul 2015 22:49:17 -0400, Karl Auer <kauer@biplane.com.au> wrote:

...

You, we, all of us have to stop using the present to limit the future. What IS should not be used to define what SHOULD BE.

What people NOW HAVE in their homes should not be used to dictate to them what they CAN HAVE in their homes, which is what you do when you provide them only with non-globally-routable address space (IPv4 NAT), or too few subnets (IPv6 /56) to name just two examples.

Talking about IPv6, we aren't carving a limit in granite. 99.99999% of home networks currently have no need for multiple networks, and thus, don't ask for anything more; they get a single /64 prefix. If tomorrow they need more, set the hint to 60 and they get a /60. Need more, ask for 56... CURRENTLY, providers have their DHCP server(s) set to a limit of 56. But that's simply a number in a config file; it can be changed as easily as it was set the first time. (source pool size and other infrastructure aside.) It's just like the escalation of speeds: as the need for it rises, it becomes available. (in general, at least)

I already have 3 /64's hanging off a WNDR3700 (one for each of the wireless networks and one for the wired). If I turn on the second ssid's for each radio that would be 5. As for a customer getting a ISP's to increase the /56 PD to a /52 or a /48 I just don't see that happening. It will either require custom configuration for the customer or going back to the RIR and asking for a bigger allocation based on moving from /56 to /52 or /48 for all customers. You then have to manage the transition. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Jul 8, 2015, at 21:55 , Ricky Beam <jfbeam@gmail.com> wrote:

On Wed, 08 Jul 2015 22:49:17 -0400, Karl Auer <kauer@biplane.com.au> wrote:

...

You, we, all of us have to stop using the present to limit the future. What IS should not be used to define what SHOULD BE.

What people NOW HAVE in their homes should not be used to dictate to them what they CAN HAVE in their homes, which is what you do when you provide them only with non-globally-routable address space (IPv4 NAT), or too few subnets (IPv6 /56) to name just two examples.

Talking about IPv6, we aren't carving a limit in granite. 99.99999% of home networks currently have no need for multiple networks, and thus, don't ask for anything more; they get a single /64 prefix. If tomorrow they need more, set the hint to 60 and they get a /60. Need more, ask for 56... CURRENTLY, providers have their DHCP server(s) set to a limit of 56. But that's simply a number in a config file; it can be changed as easily as it was set the first time. (source pool size and other infrastructure aside.) It's just like the escalation of speeds: as the need for it rises, it becomes available. (in general, at least)

But we are carving a limit in stone without realizing it. Changing the network to give out larger prefixes is easy. However, developers consistently develop to the lowest common denominator. Don’t believe me? Try to use any of a variety of mobile apps to control a non-NAT device in your home from your cell phone when you’re not in the same broadcast domain as the device you want to control. The developers have assumed that: 1. Every household is behind NAT 2. Every household is a single broadcast domain 3. There’s never any need to talk to a device that isn’t within the same broadcast domain as the handset. 4. Nobody would ever want to use their cell phone to control their $PRODUCT without putting it on the wifi network and the $PRODUCT wired network interface will always be bridged to the wifi on the same subnet, right? Given how baked in these bad assumptions have become, I shudder at the thought of how long after ISPs start issuing /48s it will take before we start to see useful products designed with that expectation in mind. Owen

I think you're confusing very common for a tech guy and very common for the common man. I have a dozen or two v4 subnets in my house. Then again, I also run my ISP out of my house, so I have a ton of stuff going on. I can't even think of a handful of other people that would have more than one. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Tony Finch" <dot@dotat.at> To: "Ricky Beam" <jfbeam@gmail.com> Cc: nanog@nanog.org Sent: Thursday, July 9, 2015 6:17:17 AM Subject: Re: Dual stack IPv6 for IPv4 depletion Ricky Beam <jfbeam@gmail.com> wrote:

Talking about IPv6, we aren't carving a limit in granite. 99.99999% of home networks currently have no need for multiple networks, and thus, don't ask for anything more; they get a single /64 prefix.

Personal-area networks already exist. Phone/watch/laptop etc. Virtual machines are common, e.g. for running multiple different operating systems on your computer. And automotive networks need connectivity. There are often separate VLANs for VOIP and IP TV and smart meters. Separate wifi networks tuned for low-latency synchronized audio. So it's very common to have multiple networks in a home with multiple layers of routing. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Shannon, Rockall: South or southeast 5 or 6, increasing 6 or 7 later. Moderate, occasionally rough. Rain, fog patches. Moderate, occasionally very poor.

Probably because he got good advise from his father :) On Thu, Jul 9, 2015 at 3:46 PM, Harald Koch <chk@pobox.com> wrote:

On 9 July 2015 at 09:11, Mike Hammett <nanog@ics-il.net> wrote:

...

I think you're confusing very common for a tech guy and very common for the common man. I have a dozen or two v4 subnets in my house. Then again, I also run my ISP out of my house, so I have a ton of stuff going on. I can't even think of a handful of other people that would have more than one.

My son (who is not a tech guy but is a gamer) has four subnets in his (rented) house already: private LAN, guest network, home control network, and a separate LAN for the tenant downstairs who is sharing their broadband connection. And he's just getting started.

The "common man" is becoming much more sophisticated in their networking requirements, and they need this stuff to just work. Please don't place artificially small limits just because you can't see a need.

-- Harald

On 9 July 2015 at 11:42, Matthew Huff <mhuff@ox.com> wrote:

What am I missing? Is it just the splitting on the sextet boundary that is an issue, or do people think people really need 64k subnets per household?

One thing you're missing is that some of these new-fangled uses for IP networking will want to do their own subnetting. It's not "here's a subnet for the car", it's "here's a /56 for the car to break into smaller pieces as required". A /56 isn't 256 subnets, it's 8 levels of subnetting (or 2 levels, if you're human and want to subnet at nibble boundaries). A /48 is 16 (or 4) levels. I have four vehicles, so I'd want to carve out a /52 for "the car network" to make the routing and security easier to manage, and leave room for expansion (or for my guests...) One more consideration for you: we're currently allocating all IPv6 addresses out of 2000::/3. That's 1/8th of the space available. If we discover we've messed up with this sparse address allocation idea, we have 7/8ths of the remaining space left to do something different. -- Harald

When I see a car that needs a /56 subnet then I’ll take your use case seriously. Otherwise, it’s just plain laughable. Yes, I could theorize a use case for this, but then I could theorize that someday everyone will get to work using jetpacks. We have prefix delegation already via DHCP-PD, but some in the IPv6 world don’t even want to support DHCP, how does SLAAC do prefix delegation, or am I missing something else? I assume each car is going to be running as RA? Given quality of implementations of IPv6 in embedded devices so far, I found that pretty ludicrous. Seriously, the IPv6 world needs to get a clue. Creating new protocols and solutions at this point in the game is only making it more difficult for IPv6 deployment, not less. IPv6 needs to stabilize and get going.. instead it seems everyone is musing about theoretical world where users need 64k networks. I understand the idea of not wanting to not think things through, but IPv6 is how many years old, and we are still arguing about these things? Don’t let the prefect be the enemy of the good. ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 From: Harald Koch [mailto:chk@pobox.com] Sent: Thursday, July 9, 2015 12:01 PM To: Matthew Huff Cc: Marco Teixeira; NANOG list Subject: Re: Dual stack IPv6 for IPv4 depletion On 9 July 2015 at 11:42, Matthew Huff <mhuff@ox.com<mailto:mhuff@ox.com>> wrote: What am I missing? Is it just the splitting on the sextet boundary that is an issue, or do people think people really need 64k subnets per household? One thing you're missing is that some of these new-fangled uses for IP networking will want to do their own subnetting. It's not "here's a subnet for the car", it's "here's a /56 for the car to break into smaller pieces as required". A /56 isn't 256 subnets, it's 8 levels of subnetting (or 2 levels, if you're human and want to subnet at nibble boundaries). A /48 is 16 (or 4) levels. I have four vehicles, so I'd want to carve out a /52 for "the car network" to make the routing and security easier to manage, and leave room for expansion (or for my guests...) One more consideration for you: we're currently allocating all IPv6 addresses out of 2000::/3. That's 1/8th of the space available. If we discover we've messed up with this sparse address allocation idea, we have 7/8ths of the remaining space left to do something different. -- Harald

It seems like there might be several incorrect assumptions here leading to over thinking the issue. 1. Over a long period of time, will the size or number of subnets be significantly different than today. Even today a bunch of our assumptions on why subnets are created the way they are might be obsolete or close to it. For example, broadcast domain size becomes less of an issue as broadcasts are used less (presumably by better targeted multicast and smarter protocols) and device performance increases. Maybe networks get smart enough to reorganize themselves and their subnets to optimize performance or maybe there will not be the need to do so. 2. Am I wrong or are we making some bad assumptions about "routability" of subnets? It seems like we might be too concerned about the minimum routable sized subnet when in reality that is just a policy decision open to change over time. Also, the routing I do inside my home does not need to be routable to the Internet at large. Summarization can occur in my home and at the service provider level. 3. If a couple of users required an inordinate amount of subnets, why not assign them an additional netblock? In the V4 world Fortune 500 global networks are not treated the same as your grandma's cell phone. It's nice to have the comfort of doing it with V6 but no real compelling reason not to have more than one type of customer assignment. Why not size things for the usual use case and add another allocation as needed? Seems really wasteful to do anything else. The NICs don't give a global carriers the same assignments they give a simple dual homed user why should you think all of your sub-assignments would be identical? 4. This is not the last time in history that you might get to reorganize your address space so don't try to plan for crazy edge cases. Given the widespread use of DHCP (or any other automatic addressing technology) in the V6 world it is archaic to think that an address change will be a big inconvenience. If my device receives an address and auto updates DNS records then I really do not care what that address is. Feel free to reorganize the network whenever you want. 5. The car example does not work because I am assuming you don't drive in your home. You probably roam all around the area and will be getting dynamic assignments from whomever the provider is. Do you statically address your iPhone when it is on the 3G/4G/LTE network? Steven Naslund Chicago IL

...

...

Subject: Re: Dual stack IPv6 for IPv4 depletion

...

...

On 9 July 2015 at 11:42, Matthew Huff <mhuff@ox.com<mailto:mhuff@ox.com>> wrote: What am I missing? Is it just the splitting on the sextet boundary that is an issue, or do people think people really need 64k subnets per household?

...

...

One thing you're missing is that some of these new-fangled uses for IP networking will want to do their own subnetting. It's not "here's a subnet for the car", it's "here's a /56 for the car to break into smaller pieces as >>>required".

...

A /56 isn't 256 subnets, it's 8 levels of subnetting (or 2 levels, if you're human and want to subnet at nibble boundaries). A /48 is 16 (or 4) levels. I have four vehicles, so I'd want to carve out a /52 for "the car network" to >>make the routing and security easier to manage, and leave room for expansion (or for my guests...)

...

One more consideration for you: we're currently allocating all IPv6 addresses out of 2000::/3. That's 1/8th of the space available. If we discover we've messed up with this sparse address allocation idea, we have 7/8ths of the >>remaining space left to do something different.

Seems to me that the problem might be thinking that the allocation toward the customer is a static thing. I think it is limiting to think that was going forward. Our industry created DHCP so we didn't have to deal with statically configured users who did not want to deal with IP addressing. Seems to me that a natural progression is to hand a network block to the CPE (DHCP-PD) and let it deal with it. No reason a CPE device cannot be created that will request more addresses when it needs them and dynamically receive a larger assignment. When you think about it long term our network infrastructure is pretty archaic in that we have to do paperwork to get an block assignment from the regional numbering authority and then manually chop that up. I would expect that model to die over time and become more of a hierarchy whereby addresses are dynamically assigned top to bottom. Seems like the numbering authority could be a lot more effective if a network could tell them about its utilization and have additional addresses assignments happen automatically. The converse would be true as well, a network could reconfigure to free underutilized blocks on its own. If a customer CPE needs more addresses it will request them. If you add a pop to your network it should automatically get an allocation from an upstream device. The only reason why anyone cares what their address is results from the fact that our name to address mapping via DNS is so slow to update. The end user does not care what addresses they get as long as everyone can reach what they need to. Your customers would not care about renumbering pain if there wasn't any. Today they could care less if it is V4 or V6 as long as everyone can see each other. My dad gets V6 on his cell phone and he can't even spell IP. Another inefficient legacy is the assignment of address space on a service provider basis when geographic assignment would allow for better summarization. If that happened you could create a better model where less routers need to carry a "full table" view of the Internet. As long as I know how to get around my area and to regional routers that can reach out globally, that is all we need. Now you would not have the limitation that a wide variety of routers need to carry every route and the /64 routing limitation goes away. Today our routing is very much all or nothing. Either use defaults or get a whole table via are probably the two most common options (yeah, I know there are others but those are the main two). The ideas on the reasons for building VLANs is pretty out of date too. It drives me nuts when I see the usual books giving you the usual example that "accounting and their server are on one VLAN and engineering and their server are on another VLAN" and that this is for performance and security reasons. Some of the biggest vendors in the business use examples like this (yes, Cisco, I'm looking at you) and it just does not work that way in the real world. Who gets to what server is most often decided by the server (AD membership or group policy of some type). If the accounting and engineering department are both going to a cloud service VLAN separation is pretty moot. In a world where my refrigerator wants to talk to the power company and send a shopping list to my car, VLAN based security is not really a solution. In the "Internet of things" we keep hearing about, everything is talking to everything. Security is highly dependent in that world on a device defending itself and not relying on a VLAN boundary. From what I am seeing out there today, there are usually far too many VLANs and too much layer three going on in most large networks. In the future it would seem that systems would create their own little networks ad-hoc as needed for the best efficiency. I know this is not all out there today but planning address allocation 10 years down the road might be an exercise in futility. I would suggest plan for today and build it so you can easily change it when your prediction invariably prove wrong or short-sighted. Steven Naslund Chicago IL

...

On Jul 9, 2015, at 09:16 , Matthew Huff <mhuff@ox.com> wrote:

When I see a car that needs a /56 subnet then I’ll take your use case seriously. Otherwise, it’s just plain laughable. Yes, I could theorize a use case for this, but then I could theorize that someday everyone will get to work >>using jetpacks.

When I see a reason not to give out /48s, I might start taking your argument seriously.

...

We have prefix delegation already via DHCP-PD, but some in the IPv6 world don’t even want to support DHCP, how does SLAAC do prefix delegation, or am I missing something else? I assume each car is going to be running as RA? Given quality of implementations of IPv6 in embedded devices so far, I found that pretty ludicrous.

Clearly the quality of IPv6 in embedded devices needs to improve. There’s clearly work being done on LWIP IPv6, but I don’t think it’s ready for prime time yet. (LWIP is one of the most popular embedded IP stacks. You’ll find it in a wide range of devices, including, but not limited to the ESP8266).

...

Seriously, the IPv6 world needs to get a clue. Creating new protocols and solutions at this point in the game is only making it more difficult for IPv6 deployment, not less. IPv6 needs to stabilize and get going.. instead it seems everyone is musing about theoretical world where users need 64k networks. I understand the idea of not wanting to not think things through, but IPv6 is how many years old, and we are still arguing about these things? Don’t let the prefect be the enemy of the good.

/48s for end sites are NOT new… They have been part of the IPv6 design criteria from about the same time 128-bit addresses were decided. It is these silly IPv4-think notions of /56 and /60 that are new changes to the protocol. The good news is that it’s very easy to deploy /48s and if it turns out we were wrong, virtually everyone currently advocating /48s will happily help you get more restrictive allocation policies when 2000::/3 runs out. (assuming any of us are still alive when that happens). Owen

On Jul 9, 2015, at 3:38 PM, Tyler Applebaum <applebaumt@ochin.org> wrote:

Do people actually use VLANs for security? It's nice to implement them for organizational purposes and to prevent broadcast propagation.

I would generally say yes. For example, if you are a wireless access point you may have an internal SSID and a Guest SSID on the same radio and hence same physical ethernet cable. - Jared

Yes, and that is a problem. Usually because it is not granular enough and there are a lot of ways to get onto another VLAN (physical access and packet trickery). It is a pretty weak form of security policy. Now, if we assume that VLAN based security is weak and that most homes do not generate enough broadcast traffic to be an issue, what exactly is the reason that a residential customer needs a lot of VLANs? Answer, they probably don't. A lot of residential users have a CPE device that does wireless, routing, and DHCP assignments all in one. No need to create a guest VLAN on that type of device. You simply assign an ACL that keeps the guest from reaching any internal IP. Why would your refrigerator (or car, toaster, TV, whatever) need to be on a separate subnet when the whole point is to create a network where all of your stuff communicates? Us engineers need to make sure we don't generalize that a lot of residential users do to their networks what we do to ours. We MIGHT have a reason for several subnets to simulate different stuff. I am still waiting for a valid example of a residential situation where VLANs are a useful addition. Oh, and don't even try the QoS argument. I will tell you that LLDP identification of the device and applying QoS policy based on the identification is much more effective and transparent to the end user. Steven Naslund Chicago IL

-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Tyler Applebaum Sent: Thursday, July 9, 2015 3:38 PM To: Naslund, Steve Cc: nanog@nanog.org Subject: RE: Dual stack IPv6 for IPv4 depletion

Do people actually use VLANs for security? It's nice to implement them for organizational purposes and to prevent broadcast propagation.

hum.. let me postulate. my lan, my kids, my guests, the drive-bys, … the LG stuff, the Apple stuff, the whitebox stuff, appliances … smart meters, switches, thermostats, toilets, water flow controls, … Microsoft can talk to the x-box, but i have no desire for them t see/know anything else on the entertainment lan at the house…. manning bmanning@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 9July2015Thursday, at 13:00, Naslund, Steve <SNaslund@medline.com> wrote:

Yes, and that is a problem. Usually because it is not granular enough and there are a lot of ways to get onto another VLAN (physical access and packet trickery). It is a pretty weak form of security policy.

Now, if we assume that VLAN based security is weak and that most homes do not generate enough broadcast traffic to be an issue, what exactly is the reason that a residential customer needs a lot of VLANs? Answer, they probably don't. A lot of residential users have a CPE device that does wireless, routing, and DHCP assignments all in one. No need to create a guest VLAN on that type of device. You simply assign an ACL that keeps the guest from reaching any internal IP. Why would your refrigerator (or car, toaster, TV, whatever) need to be on a separate subnet when the whole point is to create a network where all of your stuff communicates?

Us engineers need to make sure we don't generalize that a lot of residential users do to their networks what we do to ours. We MIGHT have a reason for several subnets to simulate different stuff. I am still waiting for a valid example of a residential situation where VLANs are a useful addition. Oh, and don't even try the QoS argument. I will tell you that LLDP identification of the device and applying QoS policy based on the identification is much more effective and transparent to the end user.

Steven Naslund Chicago IL

...

-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Tyler Applebaum Sent: Thursday, July 9, 2015 3:38 PM To: Naslund, Steve Cc: nanog@nanog.org Subject: RE: Dual stack IPv6 for IPv4 depletion

Do people actually use VLANs for security? It's nice to implement them for organizational purposes and to prevent broadcast propagation.

On 9/Jul/15 21:45, Matthew Huff wrote:

I've seen VLAN/subnet security used frequently in the financial world, even to the point of having full firewalls between vlans/subnets. Mostly for regulator purposes (Chinese firewall and all that). It's also common to allow outbound requests or redirect to different proxies based on source addresses within a corporate network.

In residential networks, it's mostly used for guest networks that can route out to the internet, but not to other local devices.

In the AN, you don't want residential neighbors viewing each others' Layer 2 domains. But using different VLAN's for that doesn't scale - so-called Split Horizons (Private VLAN's) are the answer. Mark.

In short, much of what you say below has been discussed before and with the general conclusion “geography != topology and no, geographic allocation would not improve summarization”. I’m not saying that assignments need to be static, but I am saying that we need to put the default size somewhere that doesn’t inhibit future development and close off options at the application level. That’s why I’m arguing for a default /48. Owen

On Jul 9, 2015, at 12:24 , Naslund, Steve <SNaslund@medline.com> wrote:

Seems to me that the problem might be thinking that the allocation toward the customer is a static thing. I think it is limiting to think that was going forward. Our industry created DHCP so we didn't have to deal with statically configured users who did not want to deal with IP addressing. Seems to me that a natural progression is to hand a network block to the CPE (DHCP-PD) and let it deal with it. No reason a CPE device cannot be created that will request more addresses when it needs them and dynamically receive a larger assignment.

When you think about it long term our network infrastructure is pretty archaic in that we have to do paperwork to get an block assignment from the regional numbering authority and then manually chop that up. I would expect that model to die over time and become more of a hierarchy whereby addresses are dynamically assigned top to bottom. Seems like the numbering authority could be a lot more effective if a network could tell them about its utilization and have additional addresses assignments happen automatically. The converse would be true as well, a network could reconfigure to free underutilized blocks on its own. If a customer CPE needs more addresses it will request them. If you add a pop to your network it should automatically get an allocation from an upstream device.

The only reason why anyone cares what their address is results from the fact that our name to address mapping via DNS is so slow to update. The end user does not care what addresses they get as long as everyone can reach what they need to. Your customers would not care about renumbering pain if there wasn't any. Today they could care less if it is V4 or V6 as long as everyone can see each other. My dad gets V6 on his cell phone and he can't even spell IP.

Another inefficient legacy is the assignment of address space on a service provider basis when geographic assignment would allow for better summarization. If that happened you could create a better model where less routers need to carry a "full table" view of the Internet. As long as I know how to get around my area and to regional routers that can reach out globally, that is all we need. Now you would not have the limitation that a wide variety of routers need to carry every route and the /64 routing limitation goes away. Today our routing is very much all or nothing. Either use defaults or get a whole table via are probably the two most common options (yeah, I know there are others but those are the main two).

The ideas on the reasons for building VLANs is pretty out of date too. It drives me nuts when I see the usual books giving you the usual example that "accounting and their server are on one VLAN and engineering and their server are on another VLAN" and that this is for performance and security reasons. Some of the biggest vendors in the business use examples like this (yes, Cisco, I'm looking at you) and it just does not work that way in the real world. Who gets to what server is most often decided by the server (AD membership or group policy of some type). If the accounting and engineering department are both going to a cloud service VLAN separation is pretty moot. In a world where my refrigerator wants to talk to the power company and send a shopping list to my car, VLAN based security is not really a solution. In the "Internet of things" we keep hearing about, everything is talking to everything. Security is highly dependent in that world on a device defending itself and not relying on a VLAN boundary. From what I am seeing out there today, there are usually far too many VLANs and too much layer three going on in most large networks.

In the future it would seem that systems would create their own little networks ad-hoc as needed for the best efficiency. I know this is not all out there today but planning address allocation 10 years down the road might be an exercise in futility. I would suggest plan for today and build it so you can easily change it when your prediction invariably prove wrong or short-sighted.

Steven Naslund Chicago IL

...

...

On Jul 9, 2015, at 09:16 , Matthew Huff <mhuff@ox.com> wrote:

When I see a car that needs a /56 subnet then I’ll take your use case seriously. Otherwise, it’s just plain laughable. Yes, I could theorize a use case for this, but then I could theorize that someday everyone will get to work >>using jetpacks.

...

When I see a reason not to give out /48s, I might start taking your argument seriously.

...

...

We have prefix delegation already via DHCP-PD, but some in the IPv6 world don’t even want to support DHCP, how does SLAAC do prefix delegation, or am I missing something else? I assume each car is going to be running as RA? Given quality of implementations of IPv6 in embedded devices so far, I found that pretty ludicrous.

Clearly the quality of IPv6 in embedded devices needs to improve. There’s clearly work being done on LWIP IPv6, but I don’t think it’s ready for prime time yet. (LWIP is one of the most popular embedded IP stacks. You’ll find it in a wide range of devices, including, but not limited to the ESP8266).

...

...

Seriously, the IPv6 world needs to get a clue. Creating new protocols and solutions at this point in the game is only making it more difficult for IPv6 deployment, not less. IPv6 needs to stabilize and get going.. instead it seems everyone is musing about theoretical world where users need 64k networks. I understand the idea of not wanting to not think things through, but IPv6 is how many years old, and we are still arguing about these things? Don’t let the prefect be the enemy of the good.

/48s for end sites are NOT new… They have been part of the IPv6 design criteria from about the same time 128-bit addresses were decided. It is these silly IPv4-think notions of /56 and /60 that are new changes to the protocol.

The good news is that it’s very easy to deploy /48s and if it turns out we were wrong, virtually everyone currently advocating /48s will happily help you get more restrictive allocation policies when 2000::/3 runs out. (assuming any of us are still alive when that happens).

Owen

----- On Jul 9, 2015, at 4:07 PM, Naslund, Steve SNaslund@medline.com wrote:

In short, I'm saying that you should set your default so it is easily changed on the fly and then it won't matter if you are wrong.

Absolutely. Also, since it won't matter if we are wrong, let's use /48 as the default, since it is much easier to deal with and is much less likely to be a case of "oops, too small" than /56 or, particularly, /60 or longer. -Randy

Huh, since when does ANY application care about what size address allocation you have? A V6 address is a 128 bit address period. Any IPv6 aware application will handle addresses as a 128 bit variable. Does any application running on IPv4 care if you have a /28 or a /29? In fact the application should not even be aware of what the net mask is because that is an OS function to handle the IP stack. This argument makes no sense at all since every application will be able to handle any allocation size since it is not even aware what that is. Any IPv6 compatible OS will not care either because they would be able to handle any number of masked bits. No app developer has ever been tied into the size of a subnet since CIDR was invented. Steven Naslund Chicago IL

Subject: Re: Dual stack IPv6 for IPv4 depletion

And I’m saying you’re ignoring an important part of reality.

Whatever ISPs default to deploying now will become the standard to which application developers develop.

Changing the ISP later is easy.

Changing the applications is hard.

Let’s not bake unnecessary limitations into applications by assuming that tomorrow’s networks in homes will necessarily be as simple as today’s.

Owen

...

Huh, since when does ANY application care about what size address allocation you have? A V6 address is a 128 bit address period. Any IPv6 aware application will handle addresses as a 128 bit variable.

The DHCPv6-PD server application on your router(s) might care.

Do you know of a DHCPv6-PD or router code that will accept a /56 and not a /48? If you do, I suggest you open a bug with that vendor and tell them that either is a legal prefix length.

...

Does any application running on IPv4 care if you have a /28 or a /29? In fact the application should not even be aware of what the net mask is because that is an OS function to handle the IP stack. This argument makes no sense at all since every application will be able to handle any allocation size since it is not even aware what that is. Any IPv6 compatible OS will not care either because they would be able to handle any number of masked bits. No app developer has ever been tied into the size of a subnet since CIDR was invented.

For an application that doesn't do anything with IP addresses (allocating, etc.), it shouldn't matter, but that does not mean that there aren't applications for which it does.

-Randy

One should demand that application that care about allocation size, routing, etc would not be "IPv6 compatible" if they cannot handle all mask length legal under the protocol specification. The reason there is a v6 standard is to define what is allowable or not, that is what a protocol IS. We do not need to decide by committee to limit those options. Steven Naslund Chicago IL

So, why not demand that firmware accepts ANY mask length just like VLSM v4. I don't see what possible difference it will make if it is a /56 or /48 and I don't think you should make ANY assumption based on either of those being correct for any particular application. An assumption you make today is only applicable to your network not mine, it has no certainty of permanence at all. If one of my software engineers came to me and asked I would tell them they need to handle all possible mask lengths...period. Even if they are not in common use today, if its legal under the v6 spec then you should expect to support it. Not engineering for change is how we end up with software that won't handle a 2xxx year or a leap second. If a vendor decides to code something like the ff02:: scoping into their systems in a way that can't easily change then it is at their own risk. Would it be very difficult to change that depending on the DHCP-PD response you got? Why do you want to be the guy to make the bad assumption instead of them? That's what you are doing in the /56 vs /48 argument is it not? A little early in the IPv6 game to be making permanent rules on allocation sizes for future generations and hard coding them don't you think? All of statements you make regarding "enable some development" and "reasonable end-site boundary" are the network equivalents of the "no one will need more that 640k of RAM" and "32 bits will be more addresses than we ever need" As far as opening up my mind a bit how about opening your mind and demanding that IPv6 compatibility means accepting ALL possible allocation lengths. Steven Naslund Chicago IL

Sigh…

Home gateways are an application in this context. How the firmware gets written in those things will be affected.

Further, applications do care about things like “Can I assume that every home is reachable in its entirety via a packet to ff02::<group>?” which is, for example, already baked into many products as the current mDNS default scope.

SSDPv6 also seems to default to ff02:: scoping.

Whether or not applications come into existence that can take advantage of diverse topology in the home will depend entirely on whether or not we make diverse topology possible going forward.

/56 will enable some development in this area, but it will hinder several potential areas of exploration.

/48 is a reasonable end-site boundary. It allows enough flexibility for dynamic topologies while still leaving enough prefix space to have lots of extra room for sparse allocations and everything else.

So, instead of focusing on the narrowest possible definition of “application” by todays terms, try opening your mind just a little bit and recognize that anything that requires software and interacts with the network in any way is a >better definition of application in this context.

Owen

Subject: Re: Dual stack IPv6 for IPv4 depletion

Because vendor pressure depends on a userbase that knows enough to demand fixes.

No vendor pressure is dependent on people buying their stuff. Don't send that CPE to your user if it does not meet your standards. If their stuff breaks because of shortsighted coding to bad for them. I am not going to be the guy to build in stupid limitations today to save a few minutes of coding for some lazy hardware vendor.

Simple fact is that if most ISPs deploy degraded services, vendors will code to the lowest common denominator of that degraded service and we’ll all be forced to live within those limitations in the products we receive.

Why would you think so? Did your IPv4 router not accept a /8 netmask even though there was very little chance you would get one? I know most of my programmers are trained to anticipate all of the possible options for an input. Sometimes this is hard to define but with IPv6 it is clearly in the specification. Would you consider an ISP that hands out /56s to be "degraded"? Most users wouldn't know the difference and if you offered the /48 on request (or even better automatically on depletion of the /56) what would be degraded?

This is already evident in the IPv4 world. Even though my TiVO is 100% reachable from the internet, I can’t use any of TiVO’s applications to access it directly, I have to work through their proxy servers that depend on periodic >polling from my devices to work because they assume everyone is stuck behind NAT.

That would be Tivo's fault wouldn't it. It would be trivially simple for them to know if they were behind a NAT so I am guessing they force you through their proxy for other purposes. Should we re-engineer the way IP works so that Tivo can write crap code? Should we limit all future v6 users today so that crap CPE works now?

Can you offer one valid reason not to give residential users /48s? Any benefit whatsoever?

I never said that there was a valid reason not to use /48s or /56s or whatever prefix you like. What I am saying is don't force that decision on anyone today. IPv6 does not force the use of any particular prefix length for an end user, why should you? Why do we all have to use the same length anyways?

Owen

Steven Naslund Chicago IL

On Jul 9, 2015, at 15:55 , Ricky Beam <jfbeam@gmail.com> wrote:

On Thu, 09 Jul 2015 18:23:29 -0400, Naslund, Steve <SNaslund@medline.com> wrote:

...

That would be Tivo's fault wouldn't it.

Partially, even mostly... it's based on Bonjour. That's why the shit doesn't work "over the internet".

(It's just http/https, so it will, in fact, work, but their apps aren't designed to work that way. Many 3rd party control apps have no problems.)

Correct… It _IS_ TiVO’s fault. However, the reality I’m trying to point out is that application developers make assumptions based on the commonly deployed environment that they expect in the world. If we create a limited environment, then that is what they will code to. If we deliver /48s, then they will come up with innovative ways to make use of those deployments. If we deliver /56s, then innovation will be constrained to what can be delivered to /56s, even for sites that have /48s. Owen

On Jul 9, 2015, at 16:28 , Ricky Beam <jfbeam@gmail.com> wrote:

On Thu, 09 Jul 2015 19:08:56 -0400, Owen DeLong <owen@delong.com> wrote:

...

the reality I’m trying to point out is that application developers make assumptions based on the commonly deployed environment that they expect in the world.

Partially. It's also a matter of the software guys not having any clue what-so-ever w.r.t. networking. In this case, APPLE designed Bonjour to not cross network boundaries. Idiotic, but it allows them to sell "servers" that do the cross-network routing.

Actually it’s not a design problem in IPv6. A simple tweak to the software to send to ff05::<group> instead of ff02::<group> or better yet, allow the user to edit the scope in System Preferences is all that is really needed. However, in IPv4, mDNS/Bonjour (and mDNS is uPNP’s fault, not Apple’s to the best of my knowledge) use broadcast packets and that’s a design flaw. However, hard to argue with the choice since multicast, especially cross-router multicast is pretty much busted in any sort of home gateway in IPv4 anyway.

...

If we create a limited environment, then that is what they will code to.

They will code to what they understand, what "works for them", and what their users report "works for me". We will always end up with "substandard" quality because they have little (or no) understanding of how networking does it's thing.

(And then marketing, and legal will step in and pooh on it even more.)

OK… Clearly you are determined to let cynicism and avoidance drive your ideas here. I can’t help that. Hopefully enough others will try to make the internet more useful as we move forward and hand out larger end-site prefixes. Owen

On Jul 9, 2015, at 18:19 , Laszlo Hanyecz <laszlo@heliacal.net> wrote:

On Jul 9, 2015, at 11:08 PM, Owen DeLong <owen@delong.com> wrote:

...

...

On Jul 9, 2015, at 15:55 , Ricky Beam <jfbeam@gmail.com> wrote:

On Thu, 09 Jul 2015 18:23:29 -0400, Naslund, Steve <SNaslund@medline.com> wrote:

...

That would be Tivo's fault wouldn't it.

Partially, even mostly... it's based on Bonjour. That's why the shit doesn't work "over the internet".

(It's just http/https, so it will, in fact, work, but their apps aren't designed to work that way. Many 3rd party control apps have no problems.)

Correct… It _IS_ TiVO’s fault. However, the reality I’m trying to point out is that application developers make assumptions based on the commonly deployed environment that they expect in the world.

If we create a limited environment, then that is what they will code to.

If we deliver /48s, then they will come up with innovative ways to make use of those deployments. If we deliver /56s, then innovation will be constrained to what can be delivered to /56s, even for sites that have /48s.

Owen

I would love to see things go Owen's way.. /48s everywhere, everyone agrees it's a good idea, and we can just assume that it will work. We can move on, this is one less thing to stress about.

On the other hand, I do wonder how this will work, even if most people are getting /48s. Perhaps in a few years we'll be past all this, and there will be a well accepted standard way. Maybe it will be RIPng. Maybe some thing that we haven't seen yet. Or maybe there will be 800 ways of doing it, because the protocol spec allows that, and so we should complicate our lives further by requiring everyone to support every possibility of combinations. This is the worst possible outcome because it means unnecessary complexity, more work for everyone involved, and less reliability.

If you're writing an application, do you bother supporting /48, /56, RA, DHCP, etc, while also supporting an https polling mechanism for the times when none of that stuff works? We can pretend that it doesn't matter and that software should 'just work' with any network, but that's simply not possible for many applications. I think as an application developer, you're much better off aiming for the least common denominator, accepting the limitations of that, and just moving on. This means polling, reflectors, NAT, proxyarp, etc. Things that you can control, to make your app work. Supporting a bunch of different ways is a waste of everyone's time and just makes your application less reliable and harder to test. Unless your specific application benefits greatly from a more capable network, it's probably not worth even thinking about, as long as you know that you will still have to support the 'bad' ones.

Which is why I’m arguing that we should try not to implement the bad ones in IPv6.

A music streaming application can use a hardcoded well known server name to access a centralized service. It can even communicate with other users by using that central server as a database or reflector. It would be 'nice' if it could ask the network for a prefix and use a different address for each peer it talks to, but what's the point in developing that, if you still have to support the other case?

Will you always have to support that case? Do you really want to say that the current state of IPv4 should drive all development decisions for all future products?

A wifi hotspot device would benefit from prefix delegation, but it could of course use NAT or proxying without the cooperation of the network. This is one application where it might be worth supporting all the different combinations, but it means that all those different methods need to be tested, and they can break in different ways, and there's no way to be sure it's right.

Choice is good, you can run your own network any way you want, etc, but it's not good when people are making choices just for the sake of being different and incompatible. After all, the point of the internet is to communicate with everyone else, which means we all need to agree on how we will communicate. How can we expect everyone to embrace IPv6 if we can't even provide a straightforward procedure to get connected to it?

This is all true. Seems to me DHCP-PD receiving a /48 from upstream is a pretty straightforward approach. Dynamic topologies inside the home still require some development work, but any router ought to be able to accept a /48 and assign /64s to the local-facing port(s) fairly easily. Owen

In message <9578293AE169674F9A048B2BC9A081B401C7097D2E@MUNPRDMBXA1.medline.com> , "Naslund, Steve" writes:

...

Subject: Re: Dual stack IPv6 for IPv4 depletion

Because vendor pressure depends on a userbase that knows enough to demand fixes.

No vendor pressure is dependent on people buying their stuff. Don't send that CPE to your user if it does not meet your standards. If their stuff breaks because of shortsighted coding to bad for them. I am not going to be the guy to build in stupid limitations today to save a few minutes of coding for some lazy hardware vendor.

...

Simple fact is that if most ISPs deploy degraded services, vendors will

code to the lowest common denominator of that degraded service and well all be forced to live within those limitations in the products we receive.

...

Why would you think so? Did your IPv4 router not accept a /8 netmask even though there was very little chance you would get one? I know most of my programmers are trained to anticipate all of the possible options for an input. Sometimes this is hard to define but with IPv6 it is clearly in the specification.

Would you consider an ISP that hands out /56s to be "degraded"? Most users wouldn't know the difference and if you offered the /48 on request (or even better automatically on depletion of the /56) what would be degraded?

Because ISP's have a track record of not listening to user requests. Getting IPv6 delivered is a prime example. Some of us have been requesting it from our ISP's for well over a decade now and they are still yet to deliver. Some of us have requested that SUBMIT be enabled on their outgoing mail server for just as long, a simple 1 line fix in the mail server config. No, webmail is not a acceptable alternative. It's likely to take as long to get them to increase the allocation from a /56 to a /48 despite it being a 1 word fix in a config. Getting that one word change will not be as easy as ring up customer support and saying "Can you please increase the number of subnets returned to a prefix delegation request?" and getting "Yes" as the answer.

...

This is already evident in the IPv4 world. Even though my TiVO is 100% reachable from the internet, I cant use any of TiVOs applications to access it directly, I have to work through their proxy servers that depend on periodic >polling from my devices to work because they assume everyone is stuck behind NAT.

That would be Tivo's fault wouldn't it. It would be trivially simple for them to know if they were behind a NAT so I am guessing they force you through their proxy for other purposes. Should we re-engineer the way IP works so that Tivo can write crap code? Should we limit all future v6 users today so that crap CPE works now?

No. It is ISP's and CPE vendors faults for stalling on IPv6 for well over a decade. If we all had IPv6 in the home a decade ago Tivo could have designed for a reachable device rather than one that had to polled due to there being no IPv6 in the home and IPv4 addresses changing all the time due to there not being enouhg of them and ISP's having to juggle them. Tivo added IP support in 2006. Windows XP already had IPv6 support when Tivo shipped their 2nd gen box. A Tivo box is a in-home server. That requires stable addressability which IPv6 (RFC 2460) can deliver, using address blocks assigned from the ISP using PD (RFC 3633). With IPv6 it could register its address in the global DNS using a TSIG (RFC 2845) signed UPDATE (RFC 2136) requests just the way your Mac can do today. All of these RFC's existed when the 2nd Gen Tivo was designed. What didn't exist was ISP's delivering IPv6 to the home customer. What Tivo had to work with was 99.9% of the user base behind a NAT with no address stablility. How would you design your Tivo?

...

Can you offer one valid reason not to give residential users /48s? Any benefit whatsoever?

I never said that there was a valid reason not to use /48s or /56s or whatever prefix you like. What I am saying is don't force that decision on anyone today. IPv6 does not force the use of any particular prefix length for an end user, why should you? Why do we all have to use the same length anyways?

...

Owen

Steven Naslund Chicago IL

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Thu, 09 Jul 2015 23:33:25 -0700, Matthew Kaufman said:

One of the hopeful outcomes of IPv6 adoption was that an ISP could get enough to last "forever" in a single transaction. But "forever" isn't very long at one /48 (or more) per customer.

How long does it take to blow through a /20 at /48 a customer?

On Jul 10, 2015, at 03:57 , Matthew Kaufman <matthew@matthew.at> wrote:

...

On Jul 9, 2015, at 11:53 PM, Valdis.Kletnieks@vt.edu wrote:

On Thu, 09 Jul 2015 23:33:25 -0700, Matthew Kaufman said:

...

One of the hopeful outcomes of IPv6 adoption was that an ISP could get enough to last "forever" in a single transaction. But "forever" isn't very long at one /48 (or more) per customer.

How long does it take to blow through a /20 at /48 a customer?

A while. But the more likely case is that the guy before you asked for and got a /32, because that's the minimum (and already two steps up the fee scale, I might add)

You want ISPs to start with /20s? I'll support that over on PPML if you propose it. But I'll also ask for /20 to have a fee category of "small".

Matthew Kaufman

(Sent from my iPhone)

According to https://www.arin.net/fees/fee_schedule.html ISP / ALLOCATIONS INITIAL REGISTRATION OR ANNUAL FEES Service Category Initial Registration or Annual Fee (US Dollars) IPv4 Block Size IPv6 Block Size XX-Small $500 /22 or smaller /40 or smaller X-Small $1,000 Larger than /22, up to and including /20 Larger than /40, up to and including /36 Small $2,000 Larger than /20, up to and including /18 Larger than /36, up to and including /32 Medium $4,000 Larger than /18, up to and including /16 Larger than /32, up to and including /28 Large $8,000 Larger than /16, up to and including /14 Larger than /28, up to and including /24 X-Large $16,000 Larger than /14, up to and including /12 Larger than /24, up to and including /20 XX-Large $32,000 Larger than /12 Larger than /20 If your IPv4 ISP fits in a /22 or smaller, you can hand out /48s from a /32 for a very long time. (maximum 1024 customer end-sites with no addresses reserved for your own infrastructure, /32 = 65535 customer end sites after reserving a /48 for your infrastructure) If your IPv4 ISP fits in a /20 or smaller, you can hand out /48s from a /32 for a pretty long time. (maximum 4096 customer end-sites with no addresses reserved for your own infrastructure, /32 = 65535 customer end sites after reserving a /48 for your infrastructure) If your IPv4 ISP fits in a /18 or smaller, you can hand out /48s from a /32 for quite a while. (maximum 16,384 customer end-sites with no addresses reserved for your own infrastructure, /32 = 65535 customer end sites after reserving a /48 for your infrastructure). At IPv6 /18 or smaller, you’re in the same fee category as an IPv6 /32. As you go up, the situation only gets better… If your ISP uses an IPv4 /16, then you have a maximum of 65,536 customers with no allowance for infrastructure. For free, you can get an IPv6 /28. This allows you 16,777,215 /48 end sites with a /48 reserved for your infrastructure. If your ISP uses an IPv4 /14, then you have a maximum of 262,144 customers with no allowance for infrastructure. For free, you can get an IPv6 /24 to support up to 268,435,455 /48 end sites after reserving a /48 for infrastructure. Sure, Matthew is going to point out that my maximum IPv4 customer numbers assume you aren’t doing CGN. That’s true. Let’s assume you get a ratio of 64 customers per address using CGN (the real numbers are more like 8-16 customers per address before stuff starts to degrade badly). 64 * 1024 = 65536 subscribers on a /22, assuming you have no infrastructure, no servers, and no customers that refuse to accept densely packed CGN. At this point, you can still hand out a /48 to every customer for all practical purposes if you have a /32 of IPv6. Yes, the ultra-tiniest of ISPs will have to pay an extra $1,500 per year for their address space. Everybody else will actually probably be able to pay less per year for address space once they can abandon IPv4, even if they give a /48 to every single end-site. Owen

This is a side issue, but I'm surprised ARIN is still advertising incorrect information in the table. A small ISP client of mine had just received their first /23 earlier this year, and I convinced them they should deploy IPv6 along with IPv4 in their new PoP. It would cost nothing, I argued, as they could request a /40 and would be in the same xx-small fee category. Money is an issue with small companies, and I was glad to see them agree. However, ARIN refused the request. Here's the dialog: ISP Requests a /40 IPv6 allocation to go along with xx-small /23 IPv4 allocation already issued. ARIN: The minimum size ARIN may allocate to an ISP is a /36, as stated by policy. https://www.arin.net/policy/nrpm.html#six52 Would you like us to proceed reviewing your request for a /36? ISP: From the Annual Fees table I read this: XX-Small $500 ipv6 /40 or smaller. Are you saying that there is no way to get an IPv6 allocation in the xx-small category? ARIN: Yes. The /36 prefix is the smallest size ARIN is permitted to allocate to ISPs according to community-created policy. https://www.arin.net/policy/nrpm.html#six52 ISP: OK thanks for the info. We are going to revisit deployment plans for IPV6 in the near future so can you cancel this IPV6 request for now? Also, ARIN might want to update its fee schedule labeled "ISP / ALLOCATIONS INITIAL REGISTRATION OR ANNUAL FEES", which specifically mentions a /40 allocation to ISPs. That's the source of our confusion on the matter. ARIN: Thank you for your response. I am closing this ticket, per your request. I have seen your feedback about the fee page, and will request it be updated to clarify the smallest block that can be allocated to an ISP. But ARIN still is advertising the /40 option months later! As a result we as a community lost the opportunity to get a new ISP off on the right foot by going dual-stacked. This is not good for IPv6 adoption. Hopefully ARIN reads this and addresses the issue - either correct the table or honor xx-small requests for a /40. -mel beckman On Jul 10, 2015, at 9:53 AM, Owen DeLong <owen@delong.com<mailto:owen@delong.com>> wrote: On Jul 10, 2015, at 03:57 , Matthew Kaufman <matthew@matthew.at<mailto:matthew@matthew.at>> wrote: On Jul 9, 2015, at 11:53 PM, Valdis.Kletnieks@vt.edu<mailto:Valdis.Kletnieks@vt.edu> wrote: On Thu, 09 Jul 2015 23:33:25 -0700, Matthew Kaufman said: One of the hopeful outcomes of IPv6 adoption was that an ISP could get enough to last "forever" in a single transaction. But "forever" isn't very long at one /48 (or more) per customer. How long does it take to blow through a /20 at /48 a customer? A while. But the more likely case is that the guy before you asked for and got a /32, because that's the minimum (and already two steps up the fee scale, I might add) You want ISPs to start with /20s? I'll support that over on PPML if you propose it. But I'll also ask for /20 to have a fee category of "small". Matthew Kaufman (Sent from my iPhone) According to https://www.arin.net/fees/fee_schedule.html ISP / ALLOCATIONS INITIAL REGISTRATION OR ANNUAL FEES Service Category Initial Registration or Annual Fee (US Dollars) IPv4 Block Size IPv6 Block Size XX-Small $500 /22 or smaller /40 or smaller X-Small $1,000 Larger than /22, up to and including /20 Larger than /40, up to and including /36 Small $2,000 Larger than /20, up to and including /18 Larger than /36, up to and including /32 Medium $4,000 Larger than /18, up to and including /16 Larger than /32, up to and including /28 Large $8,000 Larger than /16, up to and including /14 Larger than /28, up to and including /24 X-Large $16,000 Larger than /14, up to and including /12 Larger than /24, up to and including /20 XX-Large $32,000 Larger than /12 Larger than /20 If your IPv4 ISP fits in a /22 or smaller, you can hand out /48s from a /32 for a very long time. (maximum 1024 customer end-sites with no addresses reserved for your own infrastructure, /32 = 65535 customer end sites after reserving a /48 for your infrastructure) If your IPv4 ISP fits in a /20 or smaller, you can hand out /48s from a /32 for a pretty long time. (maximum 4096 customer end-sites with no addresses reserved for your own infrastructure, /32 = 65535 customer end sites after reserving a /48 for your infrastructure) If your IPv4 ISP fits in a /18 or smaller, you can hand out /48s from a /32 for quite a while. (maximum 16,384 customer end-sites with no addresses reserved for your own infrastructure, /32 = 65535 customer end sites after reserving a /48 for your infrastructure). At IPv6 /18 or smaller, you're in the same fee category as an IPv6 /32. As you go up, the situation only gets better... If your ISP uses an IPv4 /16, then you have a maximum of 65,536 customers with no allowance for infrastructure. For free, you can get an IPv6 /28. This allows you 16,777,215 /48 end sites with a /48 reserved for your infrastructure. If your ISP uses an IPv4 /14, then you have a maximum of 262,144 customers with no allowance for infrastructure. For free, you can get an IPv6 /24 to support up to 268,435,455 /48 end sites after reserving a /48 for infrastructure. Sure, Matthew is going to point out that my maximum IPv4 customer numbers assume you aren't doing CGN. That's true. Let's assume you get a ratio of 64 customers per address using CGN (the real numbers are more like 8-16 customers per address before stuff starts to degrade badly). 64 * 1024 = 65536 subscribers on a /22, assuming you have no infrastructure, no servers, and no customers that refuse to accept densely packed CGN. At this point, you can still hand out a /48 to every customer for all practical purposes if you have a /32 of IPv6. Yes, the ultra-tiniest of ISPs will have to pay an extra $1,500 per year for their address space. Everybody else will actually probably be able to pay less per year for address space once they can abandon IPv4, even if they give a /48 to every single end-site. Owen

John, Thanks for the clarification. I'm happy to abide by the original community decision, but I think it's important that the table be clarified, especially given that the ARIN specialist I worked with agreed that it needs clarification. It's like going to a Starbucks as a homeless person with just pocket change, and ordering the cheapest coffee on the menu, and being told "Oh, that's for off-planet visitors only. It says so on our website under "Terms and Conditions." Can I interest you in this giga-latte at only four times the price?" A simple asterisk, followed by "Not available to residents of Earth", would prevent the confusion, and resulting social awkwardness. [😊] -mel ________________________________ From: John Curran <jcurran@arin.net> Sent: Friday, July 10, 2015 12:50 PM To: Mel Beckman Cc: nanog@nanog.org Subject: Re: Dual stack IPv6 for IPv4 depletion On Jul 10, 2015, at 1:35 PM, Mel Beckman <mel@beckman.org<mailto:mel@beckman.org>> wrote: This is a side issue, but I'm surprised ARIN is still advertising incorrect information in the table. ... Are you saying that there is no way to get an IPv6 allocation in the xx-small category? ARIN: Yes. The /36 prefix is the smallest size ARIN is permitted to allocate to ISPs according to community-created policy. https://www.arin.net/policy/nrpm.html#six52 ... But ARIN still is advertising the /40 option months later! As a result we as a community lost the opportunity to get a new ISP off on the right foot by going dual-stacked. This is not good for IPv6 adoption. Hopefully ARIN reads this and addresses the issue - either correct the table or honor xx-small requests for a /40. Mel - The confusion is very understandable, but both the fee table and the policy are accurate. The fee table includes an XX-Small category which corresponds to those ISPs which have smaller than /20 IPv4 and smaller than a /36 IPv6 total holdings – the fact that such a category exists does not mean that any particular ISP is being billed in that category (or that a new ISP will necessarily end up in that category); it simply means that ISPs with those total resources are billed accordingly. The constraint that you experienced, i.e. that there is a minimum IPv6 ISP allocation size of /36 is actually not something that the staff can fix; i.e. it’s the result of the community-led policy development process, and if you feel it does need to change to a lower number, you should propose an appropriate change to policy on the ARIN public policy mailing list <arin-ppml@arin.net<mailto:arin-ppml@arin.net>>. We _are_ in the midst of considering changes to the fee table to lower and realign the IPv6 fees in general (which might be a better solution if the cost is issue) - see <https://www.arin.net/participate/meetings/reports/ARIN_35/PDF/wednesday/curran_fees.pdf> for the update provided in April at the ARIN 35 Members meeting, with specific options for community discussion at the ARIN Fall meeting taking place in Montreal this October (adjacent to the NANOG Fall meeting) Thanks! /John John Curran President and CEO ARIN

Thank you! -mel via cell On Jul 10, 2015, at 2:19 PM, John Curran <jcurran@arin.net<mailto:jcurran@arin.net>> wrote: On Jul 10, 2015, at 4:06 PM, Mel Beckman <mel@beckman.org<mailto:mel@beckman.org>> wrote: John, Thanks for the clarification. I'm happy to abide by the original community decision, but I think it's important that the table be clarified, especially given that the ARIN specialist I worked with agreed that it needs clarification. It's like going to a Starbucks as a homeless person with just pocket change, and ordering the cheapest coffee on the menu, and being told "Oh, that's for off-planet visitors only. It says so on our website under "Terms and Conditions." Can I interest you in this giga-latte at only four times the price?" A simple asterisk, followed by "Not available to residents of Earth", would prevent the confusion, and resulting social awkwardness. <OutlookEmoji-?.png> We made note of the IPv6 policy minimum of /36 in the linked FAQ that accompanies the Fee Table, but I'll admit it could be clearer (particularly for those obtaining number resources for the first time.) We'll do an update after the October meeting reflecting the final outcome with respect to the fee table, and will address at that time. Thanks! /John John Curran President and CEO ARIN

Ricky, I am always in favor of redundant clarity over technically correct confusion :) -mel beckman

On Jul 10, 2015, at 5:08 PM, Ricky Beam <jfbeam@gmail.com> wrote:

...

On Fri, 10 Jul 2015 16:06:03 -0400, Mel Beckman <mel@beckman.org> wrote: It's like going to a Starbucks as a homeless person with just pocket change, and ordering the cheapest coffee on the menu, and being told "Oh, that's for off-planet visitors only. It says so on our website under "Terms and Conditions." Can I interest you in this giga-latte at only four times the price?"

You are confusing the "price list" with the "menu". Yes, a simple note at the bottom of that table would fix this: Current minimum IPv6 allocation is /36. That schedule doesn't say you can get a /40, only what you will pay if you *HAVE* a /40.

(Did ARIN ever hand out /40's? If not, why is in the table?)

On Jul 9, 2015, at 23:33 , Matthew Kaufman <matthew@matthew.at> wrote:

On 7/9/2015 3:07 PM, Owen DeLong wrote:

...

Can you offer one valid reason not to give residential users /48s? Any benefit whatsoever?

Sure. To avoid having to go back and deal with ARIN yet again for more IPv6 space.

One of the hopeful outcomes of IPv6 adoption was that an ISP could get enough to last "forever" in a single transaction. But "forever" isn't very long at one /48 (or more) per customer.

Matthew Kaufman

I don’t understand how that shortens forever if you ask for the right size block the first time. I’ll be surprised if HE hands out enough /48s to empty their /24 any time short of something approximating forever. It’s been at least 3 years since I got that for them. They’re definitely handing out a /48 per end site with the exception of free end-sites that don’t bother to click the “give me a /48” checkbox. Getting IPv6 from ARIN is really easy. Getting more IPv6 from ARIN is really easy if you get anywhere near filling up your IPv6 block. MUCH MUCH easier than IPv4. As an example, I bet if they wanted to, Comcast could easily qualify for a /12 under current ARIN policy. The latest figures I could find show them at just over 22.4 million broadband subscribers. Let’s assume they have 40 million just to be conservative. If you packed those in, you could fit them in 3 /24s (actually, about 2.3 /24s technically). A /12 is 4096 /24s. Please tell me again how you can’t hand out /48s per end-site forever with a single ARIN allocation? Owen

On Jul 10, 2015, at 00:59 , Joe Maimon <jmaimon@ttec.com> wrote:

There has been tomes on this topic. There will continue to be many more.

That is because many of you continue in trying to defend the following concept.

customer subnet bits == isp customers bits

So now, the ISP is supposed to put some effort and gain more bits. Why not the customer?

Its inherently suspicious. Because its inherently wrong - for the ISP, and possibly for the address space as well.

Indulge me as I wax poetic.

I venture to say that proponents want to see everyone else have the service of their own dreams. When broadband rolled to the masses with a single ipv4 address per subscriber, forget about routing, their hearts broke. The new common denominator was a far cry from what their experience was. The division of internet into different classes of netizens a bitter pill to swallow. You are only one budget cut away from joining the ho-poloi. Its quite scary.

Hence the determination that no user should ever have to go without enough addresses ever again. A new common denominator, now is the time to get it accepted!

It will be like the old days, a class C with every leased line! Forever!

I will concur with most of this.

And the ISPs?

They have enough to get started and they can get more if they put the effort in.

Actually, as has been pointed out earlier by me and Valdis at least, they can get enough to last a good long time up front if they just do a little bit of napkin math before submitting their request. Here’s how it works: JimBob’s ISP and Bait shop serves their customers from 25 distinct wiring centers. They expect to deploy another 50 wiring centers over the next 5 years. Their largest wiring center supports 5,000,000 customers. Representing 5,000,000 requires 23 bits. Rounded up to a multiple of 4 becomes 24 bits. At 24 bits, 5,000,000 is < 75% of the available /48s. So 24 bits is a good number. Representing 75 wiring centers requires another 6 bits. Rounded up to a multiple of 4 becomes 8 bits. At 8 bits, 75 is < 75% of the 256 available numbers, so 8 is a good number. 24 + 8 is 32. 48 - 32 is 16. JimBob’s ISP can apply to ARIN for a /16. Other RIRs are a little different, but still usually not terribly hard to get a large allocation if it can be even remotely justified.

So all the rational and logical debate is pointless. Gut feelings, philosophy and emotions are what is at stake and those tend not to respond well to things like logic and reason.

Perhaps. Unfortunately, I think it is more the long-prefix crowd that is going on gut feelings. Unless you can show me how there’s harm to the ISPs from /48s per end site, or any other logic to support the need to retain the concept of second-class netizens, then I think logic is on the side of a more egalitarian internet. Owen

How so? There are 8192 /16s in the current /3. ISPs with that many pops at 5,000,000 end-sites per POP, even assuming 32 end-sites per person can’t really be all that many… 25 POPS at 5,000,000 end-sites each is 125,000,000 end-sites per ISP. 7,000,000,000 * 32 = 224,000,000,000 / 125,000,000 = 1,792 total /16s consumed. Really, if we burn through all 8,192 of them in less than 50 years and I’m still alive when we do, I’ll help you promote more restrictive policy to be enacted while we burn through the second /3. That’ll still leave us 75% of the address space to work with on that new policy. If you want to look at places where IPv6 is really getting wasted, let’s talk about an entire /9 reserved without an RFC to make it usable or it’s partner /9 with an RFC to make it mostly useless, but popular among those few remaining NAT fanboys. Together that constitutes 1/256th of the address space cast off to waste. Yeah, I’m not too worried about the ISPs that can legitimately justify a /16. Owen

On Jul 13, 2015, at 16:16 , Joe Maimon <jmaimon@ttec.com> wrote:

Owen DeLong wrote:

...

JimBob’s ISP can apply to ARIN for a /16

Like I said, very possibly not a good thing for the address space.

30 years ago, if you’d told anyone that EVERYONE would be using the internet 30 years ago, they would have looked at you like you were stark raving mad. If you asked anyone 30 years ago “will 4 billion internet addresses be enough if everyone ends up using the internet?”, they all would have told you “no way.”. I will again repeat… Let’s try liberal allocations until we use up the first /3. I bet we don’t finish that before we hit other scaling limits of IPv6. If I’m wrong and we burn through the first /3 while I am still alive, I will happily help you get more restrictive policy for the remaining 3/4 of the IPv6 address space while we continue to burn through the second /3 as the policy is developed. Owen

On Jul 14, 2015, at 06:23 , George Metz <george.metz@gmail.com> wrote:

That's all well and good Owen, and the math is compelling, but 30 years ago if you'd told anyone that we'd go through all four billion IPv4 addresses in anyone's lifetime, they'd have looked at you like you were stark raving mad. That's what's really got most of the people who want (dare I say more sane?) more restrictive allocations to be the default concerned; 30 years ago the math for how long IPv4 would last would have been compelling as well, which is why we have the entire Class E block just unusable and large blocks of IP address space that people were handed for no particular reason than it sounded like a good idea at the time.

It's always easier to be prudent from the get-go than it is to rein in the insanity at a later date. Just because we can't imagine a world where IPv6 depletion is possible doesn't mean it can't exist, and exist far sooner than one might expect.

On Tue, Jul 14, 2015 at 12:22 AM, Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote: How so?

There are 8192 /16s in the current /3.

ISPs with that many pops at 5,000,000 end-sites per POP, even assuming 32 end-sites per person can’t really be all that many…

25 POPS at 5,000,000 end-sites each is 125,000,000 end-sites per ISP.

7,000,000,000 * 32 = 224,000,000,000 / 125,000,000 = 1,792 total /16s consumed.

Really, if we burn through all 8,192 of them in less than 50 years and I’m still alive when we do, I’ll help you promote more restrictive policy to be enacted while we burn through the second /3. That’ll still leave us 75% of the address space to work with on that new policy.

If you want to look at places where IPv6 is really getting wasted, let’s talk about an entire /9 reserved without an RFC to make it usable or it’s partner /9 with an RFC to make it mostly useless, but popular among those few remaining NAT fanboys. Together that constitutes 1/256th of the address space cast off to waste.

Yeah, I’m not too worried about the ISPs that can legitimately justify a /16.

Owen

...

On Jul 13, 2015, at 16:16 , Joe Maimon <jmaimon@ttec.com <mailto:jmaimon@ttec.com>> wrote:

Owen DeLong wrote:

...

JimBob’s ISP can apply to ARIN for a /16

Like I said, very possibly not a good thing for the address space.

You don’t think holding nearly 7/8ths of the address space in reserve for a future addressing policy is adequate judiciuosness? The IPv4 /8s constituted 1/2 of the address space. The /16s another 1/4, and the /24s an additional 1/8th at the time. Overall, that was 7/8ths of the address space assigned to unicast and 9/16ths allocated if you included multicast. In IPv6, we have 1/8th set aside for unicast, 1/256th for multicast, 1/256th for ULA, 1/1024th for link-local, and a couple of infinitesimal fractions set aside for other things like localhost, IPV6_ADDR_ANY, etc. As I said, let’s be liberal as designed with the first /3. If I’m wrong and you can prove it in my remaining lifetime, I will happily help you develop more restrictive allocation policy for the remaining 3/4 while the second /3 is used to continue growing the IPv6 internet. Whatever unexpected thing causes us to finish off the first /3 likely won’t burn through the second /3 before we can respond with new policy. We still have almost 3/4 of the address space available for more restrictive allocations. Frankly, I bet about 1/8th of the IPv4 address space probably is in the hands of the top 64 organizations. Maybe more. In this case, 1/8th of the address space will more than cover the entire known need many many many times over, even with very liberal allocations. Owen

On Jul 14, 2015, at 10:13 , Mel Beckman <mel@beckman.org> wrote:

Owen,

By the same token, who 30 years ago would have said there was anything wrong with giving single companies very liberal /8 allocations? Companies that for the most part wasted that space, leading to a faster exhaustion of IPv4 addresses. History cuts both ways.

I think it's reasonable to be at least somewhat judicious with our spanking new IPv6 pool. That's not IPv4-think. That's just reasonable caution.

We can always be more generous later.

-mel beckman

...

On Jul 14, 2015, at 10:04 AM, Owen DeLong <owen@delong.com> wrote:

30 years ago, if you’d told anyone that EVERYONE would be using the internet 30 years ago, they would have looked at you like you were stark raving mad.

If you asked anyone 30 years ago “will 4 billion internet addresses be enough if everyone ends up using the internet?”, they all would have told you “no way.”.

I will again repeat… Let’s try liberal allocations until we use up the first /3. I bet we don’t finish that before we hit other scaling limits of IPv6.

If I’m wrong and we burn through the first /3 while I am still alive, I will happily help you get more restrictive policy for the remaining 3/4 of the IPv6 address space while we continue to burn through the second /3 as the policy is developed.

Owen

...

On Jul 14, 2015, at 06:23 , George Metz <george.metz@gmail.com> wrote:

That's all well and good Owen, and the math is compelling, but 30 years ago if you'd told anyone that we'd go through all four billion IPv4 addresses in anyone's lifetime, they'd have looked at you like you were stark raving mad. That's what's really got most of the people who want (dare I say more sane?) more restrictive allocations to be the default concerned; 30 years ago the math for how long IPv4 would last would have been compelling as well, which is why we have the entire Class E block just unusable and large blocks of IP address space that people were handed for no particular reason than it sounded like a good idea at the time.

It's always easier to be prudent from the get-go than it is to rein in the insanity at a later date. Just because we can't imagine a world where IPv6 depletion is possible doesn't mean it can't exist, and exist far sooner than one might expect.

On Tue, Jul 14, 2015 at 12:22 AM, Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote: How so?

There are 8192 /16s in the current /3.

ISPs with that many pops at 5,000,000 end-sites per POP, even assuming 32 end-sites per person can’t really be all that many…

25 POPS at 5,000,000 end-sites each is 125,000,000 end-sites per ISP.

7,000,000,000 * 32 = 224,000,000,000 / 125,000,000 = 1,792 total /16s consumed.

Really, if we burn through all 8,192 of them in less than 50 years and I’m still alive when we do, I’ll help you promote more restrictive policy to be enacted while we burn through the second /3. That’ll still leave us 75% of the address space to work with on that new policy.

If you want to look at places where IPv6 is really getting wasted, let’s talk about an entire /9 reserved without an RFC to make it usable or it’s partner /9 with an RFC to make it mostly useless, but popular among those few remaining NAT fanboys. Together that constitutes 1/256th of the address space cast off to waste.

Yeah, I’m not too worried about the ISPs that can legitimately justify a /16.

Owen

...

On Jul 13, 2015, at 16:16 , Joe Maimon <jmaimon@ttec.com <mailto:jmaimon@ttec.com>> wrote:

Owen DeLong wrote:

...

JimBob’s ISP can apply to ARIN for a /16

Like I said, very possibly not a good thing for the address space.

I expect to be actively involved at least 20 more years. If I'm not around, thats 160 years to runout. I'm betting the protocol can't live that long for other reasons. Owen

On Jul 14, 2015, at 12:35, Mel Beckman <mel@beckman.org> wrote:

I have no problems with ISPs giving out /48s to residential subscribers. Neither do I mind if they give out /56s. That still gives every residential customer 256 /64 subnets.

I don't see this as something that needs to become a standard. Those end-users who want more can ask for more fro their ISP whenever the need arises. If there is a market for selling those larger prefixes to end users, that's free enterprise, which I also support.

I don't think it's wise to delegate by rule or convention that the entire first 1/8th of IPv6 space should be delegated in /48s. You see this as not a huge deal. To me, 12.5% is a huge deal.

I appreciate your offer to give your services away for free to remedy any problems the /3 bolus creates. But as history has shown, neither of us is likely to be in circulation -- or even alive -- when a problem would occur.

-mel beckman

...

On Jul 14, 2015, at 10:30 AM, Owen DeLong <owen@delong.com> wrote:

You don’t think holding nearly 7/8ths of the address space in reserve for a future addressing policy is adequate judiciuosness?

The IPv4 /8s constituted 1/2 of the address space. The /16s another 1/4, and the /24s an additional 1/8th at the time. Overall, that was 7/8ths of the address space assigned to unicast and 9/16ths allocated if you included multicast.

In IPv6, we have 1/8th set aside for unicast, 1/256th for multicast, 1/256th for ULA, 1/1024th for link-local, and a couple of infinitesimal fractions set aside for other things like localhost, IPV6_ADDR_ANY, etc.

As I said, let’s be liberal as designed with the first /3. If I’m wrong and you can prove it in my remaining lifetime, I will happily help you develop more restrictive allocation policy for the remaining 3/4 while the second /3 is used to continue growing the IPv6 internet.

Whatever unexpected thing causes us to finish off the first /3 likely won’t burn through the second /3 before we can respond with new policy. We still have almost 3/4 of the address space available for more restrictive allocations.

Frankly, I bet about 1/8th of the IPv4 address space probably is in the hands of the top 64 organizations. Maybe more.

In this case, 1/8th of the address space will more than cover the entire known need many many many times over, even with very liberal allocations.

Owen

...

On Jul 14, 2015, at 10:13 , Mel Beckman <mel@beckman.org> wrote:

Owen,

By the same token, who 30 years ago would have said there was anything wrong with giving single companies very liberal /8 allocations? Companies that for the most part wasted that space, leading to a faster exhaustion of IPv4 addresses. History cuts both ways.

I think it's reasonable to be at least somewhat judicious with our spanking new IPv6 pool. That's not IPv4-think. That's just reasonable caution.

We can always be more generous later.

-mel beckman

...

On Jul 14, 2015, at 10:04 AM, Owen DeLong <owen@delong.com> wrote:

30 years ago, if you’d told anyone that EVERYONE would be using the internet 30 years ago, they would have looked at you like you were stark raving mad.

If you asked anyone 30 years ago “will 4 billion internet addresses be enough if everyone ends up using the internet?”, they all would have told you “no way.”.

I will again repeat… Let’s try liberal allocations until we use up the first /3. I bet we don’t finish that before we hit other scaling limits of IPv6.

If I’m wrong and we burn through the first /3 while I am still alive, I will happily help you get more restrictive policy for the remaining 3/4 of the IPv6 address space while we continue to burn through the second /3 as the policy is developed.

Owen

...

On Jul 14, 2015, at 06:23 , George Metz <george.metz@gmail.com> wrote:

That's all well and good Owen, and the math is compelling, but 30 years ago if you'd told anyone that we'd go through all four billion IPv4 addresses in anyone's lifetime, they'd have looked at you like you were stark raving mad. That's what's really got most of the people who want (dare I say more sane?) more restrictive allocations to be the default concerned; 30 years ago the math for how long IPv4 would last would have been compelling as well, which is why we have the entire Class E block just unusable and large blocks of IP address space that people were handed for no particular reason than it sounded like a good idea at the time.

It's always easier to be prudent from the get-go than it is to rein in the insanity at a later date. Just because we can't imagine a world where IPv6 depletion is possible doesn't mean it can't exist, and exist far sooner than one might expect.

On Tue, Jul 14, 2015 at 12:22 AM, Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote: How so?

There are 8192 /16s in the current /3.

ISPs with that many pops at 5,000,000 end-sites per POP, even assuming 32 end-sites per person can’t really be all that many…

25 POPS at 5,000,000 end-sites each is 125,000,000 end-sites per ISP.

7,000,000,000 * 32 = 224,000,000,000 / 125,000,000 = 1,792 total /16s consumed.

Really, if we burn through all 8,192 of them in less than 50 years and I’m still alive when we do, I’ll help you promote more restrictive policy to be enacted while we burn through the second /3. That’ll still leave us 75% of the address space to work with on that new policy.

If you want to look at places where IPv6 is really getting wasted, let’s talk about an entire /9 reserved without an RFC to make it usable or it’s partner /9 with an RFC to make it mostly useless, but popular among those few remaining NAT fanboys. Together that constitutes 1/256th of the address space cast off to waste.

Yeah, I’m not too worried about the ISPs that can legitimately justify a /16.

Owen

...

On Jul 13, 2015, at 16:16 , Joe Maimon <jmaimon@ttec.com <mailto:jmaimon@ttec.com>> wrote:

Owen DeLong wrote: > JimBob’s ISP can apply to ARIN for a /16

Like I said, very possibly not a good thing for the address space.

On 14 Jul 2015 18:44:25 -0000, "John Levine" said:

routers does not. The right way to allocate v6 space is the first time someone asks for some, give them as much as they'll ever need. If you give them less and they have to come back for more later, you've wasted a router slot.

Amen. Integers are cheap. FIB slots cost real money.

On Tue, 14 Jul 2015 19:45:42 -0000, Mel Beckman said:

We're talking about end user assignments made by ISPs, not ISP assignments.

Do the math for how big a chunk Comcast needs, assuming they give each residential customer a /60, or a /56, or a /48. If their first chunk was sized based on ubiquitous /56s and it turns out /48 would have been better, they may need another trip to the well.

What about dual-homed customers? Or are they all expected to have their own PI space? Chuck -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Mel Beckman Sent: Tuesday, July 14, 2015 4:33 PM To: Valdis.Kletnieks@vt.edu Cc: John Levine; nanog@nanog.org Subject: Re: Dual stack IPv6 for IPv4 depletion Ok. Two RIB entries for Comcast. Your argument doesn't scale. -mel via cell On Jul 14, 2015, at 12:53 PM, "Valdis.Kletnieks@vt.edu<mailto:Valdis.Kletnieks@vt.edu>" <Valdis.Kletnieks@vt.edu<mailto:Valdis.Kletnieks@vt.edu>> wrote: On Tue, 14 Jul 2015 19:45:42 -0000, Mel Beckman said: We're talking about end user assignments made by ISPs, not ISP assignments. Do the math for how big a chunk Comcast needs, assuming they give each residential customer a /60, or a /56, or a /48. If their first chunk was sized based on ubiquitous /56s and it turns out /48 would have been better, they may need another trip to the well.

Exactly. As a business entity and not a provider, we wouldn't have even contemplated deploying IPv6 without PI addresses. The myth of easy renumbering and/or having multiple prefixes/address per host for failover still shows up from time to time, but mostly gets ignored (at least in the corporate world). Remember SHIM? Any reasonable size organization that expects reliable internet connections is going to go BGP/PI. ---- Matthew Huff             | 1 Manhattanville Rd Director of Operations   | Purchase, NY 10577 OTA Management LLC       | Phone: 914-460-4039 aim: matthewbhuff        | Fax:   914-694-5669 -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of John R. Levine Sent: Tuesday, July 14, 2015 4:50 PM To: Chuck Church Cc: nanog@nanog.org Subject: RE: Dual stack IPv6 for IPv4 depletion

What about dual-homed customers? Or are they all expected to have their own PI space?

This is IPv6. Why shouldn't they have their own PI space? R's, John

-----Original Message----- From: John R. Levine [mailto:johnl@iecc.com] Sent: Tuesday, July 14, 2015 4:50 PM To: Chuck Church <chuckchurch@gmail.com> Cc: nanog@nanog.org Subject: RE: Dual stack IPv6 for IPv4 depletion

This is IPv6. Why shouldn't they have their own PI space?

Same way it happens today. Business starts out small, uses IP space from their single ISP. Couple years later, they're bigger and want to dual-home for better uptime or other reasons. Unless there is something stopping them from advertising their ISP 'A' space out to ISP 'B' in IPv6 land, we're probably going to see the same things we see with IPv4 no? Chuck

On 15 Jul 2015 15:25:05 -0000, "John Levine" said:

It would be nice if it were possible to implement BCP 38 in IPv6, since this is the reason it isn't in IPv4.

There isn't any technical reason that an organization can't fix its edge so it doesn't urinate bad IPv6 traffic all over the Internet.

On 7/15/15 9:10 AM, John R. Levine wrote:

...

...

It would be nice if it were possible to implement BCP 38 in IPv6, since this is the reason it isn't in IPv4.

There isn't any technical reason that an organization can't fix its edge so it doesn't urinate bad IPv6 traffic all over the Internet.

In IPv4 systems, the problem is (so I have been told by some largish ISPs) that a dual homed customer gets address ranges from ISPs A and B, and sends traffic with A addresses to the B interface. The ISPs have no practical way to tell legit dual homed traffic from malicious, particularly when there is a chain of resellers in between. If the ISP tells the customer to send the traffic over the right interface, the usual response is "if you don't want our business, I'm sure we can find another ISP that does."

Strict rpf has the super nice property that if you withdraw you prefix from a peer, that peer blackholes traffic. there are all sorts of fun cases like for example MLPE peering on exchange fabrics where you can't just tag the prefix no export and send it to your neighbor, which means it's all or nothing. The exigent reality is that the less control customers have over their own policy then the easier they are to filter. retail isp customers with prefixes delegated by their provider, easy so when ISPS practice good hygiene on their retail side, great.. some dude at an exchange point direct adjacency or no, quite a bit harder.

Like I said, it would be nice if ISPs could persuade their v6 customers to get their own PI space early on, because if they don't they'll have exactly the same problem.

R's, John

On 7/15/2015 8:25 AM, John Levine wrote:

It would be nice if it were possible to implement BCP 38 in IPv6, since this is the reason it isn't in IPv4.

Too bad the hazards of allowing people to use arbitrary source addresses weren't known when IPv6 was designed. Matthew Kaufman

We're talking about end user assignments made by ISPs, not ISP assignments. An ISP's /32 is likely the only entry one needs in the FIB.

In that case, why should anyone care how the ISP assigns space to its customers? R's, John

On 15 July 2015 at 01:34, Owen DeLong <owen@delong.com> wrote:

For one thing a /32 is nowhere near enough for anything bigger than a modest ISP today. Many will need /28, /24, or even larger. The biggest ones probably need /16 or even /12 in some cases.

What is the definition of a modest and a large ISP? In the RIPE region even the smallest ISP can get a /29 with no documentation necessary. But likely that is all they will ever get because policy requires that you use that /29 at about 30% efficiency if you do /48 allocations to end users. You would need more than a million users to get a /24. I do not think the RIPE region has an ISP large enough to apply for a /16 or anything near it. Therefore we can conclude that if ARIN manages to use up all the /3 address space currently reserved for allocation, we will still be able to get address space in Europe for the next thousands years :-). It is thought that RIPE will not use up the /12 that IANA allocated to RIPE - ever. Personally I believe the ARIN policy is the sane one. But we need to abide by the rules in the region we live in. Regards, Baldur

On Jul 15, 2015, at 03:43 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

On 15 July 2015 at 01:34, Owen DeLong <owen@delong.com> wrote:

...

For one thing a /32 is nowhere near enough for anything bigger than a modest ISP today. Many will need /28, /24, or even larger. The biggest ones probably need /16 or even /12 in some cases.

What is the definition of a modest and a large ISP?

In the RIPE region even the smallest ISP can get a /29 with no documentation necessary. But likely that is all they will ever get because policy requires that you use that /29 at about 30% efficiency if you do /48 allocations to end users.

Which is fine… 30% of a /29 at /48 is 524,288 end-sites served. For a residential provider, I’d say that’s a medium-sized provider. A large provider would be one that serves several million end-sites. There are at least a handful of providers in the US for example, that have 10,000,000+ customers. A /29 wouldn’t be enough for them. RIPEs policy ignores the inefficiencies created by topology and that’s kind of unfortunate in my opinion, but so far it doesn’t appear too egregious, so I haven’t taken the time to propose better policy.

You would need more than a million users to get a /24.

Sure. Many ISPs have more than a million end-sites (note end-sites != users). In many cases customer and end-site are synonymous, but in many cases, a single customer may have many end-sites. For example, a business which has several buildings in a campus may treat each building as an end-site. A multi-tenant building would likely treat each tenant as a separate end-site. etc.

I do not think the RIPE region has an ISP large enough to apply for a /16 or anything near it.

Perhaps. There are at least 2 ISPs in the US that I know of with 20,000,000+ customers. Since the NA in NANOG stands for North America, I kind of figured that the situation in North America ought to be considered somewhat relevant.

Therefore we can conclude that if ARIN manages to use up all the /3 address space currently reserved for allocation, we will still be able to get address space in Europe for the next thousands years :-). It is thought that RIPE will not use up the /12 that IANA allocated to RIPE - ever.

I doubt even with our current policy, ARIN is unlikely to use up the /12 in my lifetime or even in the lifetime of the IPv6 protocol. Even if we do, I doubt we will use more than 2 or 3 /12s ever.

Personally I believe the ARIN policy is the sane one. But we need to abide by the rules in the region we live in.

I agree with you, but as the author of the current ARIN ISP IPv6 policy, I may be biased. ;-) Owen

On Jul 14, 2015, at 11:56 AM, Tony Hain <alh-ietf@tndh.net> wrote:

IPv6 is not the last protocol known to mankind. IF it burns out in 400-500 years, something will have gone terribly wrong, because newer ideas about networking will have been squashed along the way. 64 bits for both hosts and routing was over 3 orders of magnitude more than sufficient to meet the design goals for the IPv4 replacement, but in the context of the dot-com bubble there was a vast outcry from the ops community that it would be insufficient for the needs of routing. So the entire 64 bits of the original proposal was given to routing, and the IETF spent another year arguing about how many bits more to add for hosts. Now, post bubble burst, we are left with 32,768x the already more than sufficient number of routing prefixes, but "IPv4-think" conservation believes we still need to be extremely conservative about allocations.

If you look at how the IoT model is evolving, the entire host+service (i.e. IP address + port number) model is rapidly disintegrating. Services are the end-points now. They need to be individually addressable, since they really have no affinity to physical hardware in the sense we currently think of "hosts," with IP and MAC addresses. Host hardware is fungible; services are mobile. The IPv6 address space conservatives are missing the entire point that IPv6, as a global addressing scheme, will collapse in the next couple of decades. Host+port endpoint identifiers are already done. We just haven't noticed yet. --lyndon

Reasonability, like beauty, is in the eye of the beholder, but I thank you for the compliment. :) The short answer is "yes, that constitutes being prudent". The longer answer is "it depends on what you consider the wildest dreams". There's a couple of factors playing in. First, look at every /64 that is assigned as an IPv4 /32 that someone is running NAT behind. This is flat out WRONG from a routing perspective, but from an allocation perspective, it's very much exactly what's happening because of SLAAC and the 48-bit MAC address basis for it. Since /64 is the minimum, that leaves us with less than half of the available bit mask in which to hand out that 1/8th the address space. Still oodles of addresses, but worth noting and is probably one reason why some of the "conservationists" react the way they do. Next, let's look at the wildest dreams aspect. The current "implementation" I'm thinking of in modern pop culture is Big Hero 6 (the movie, not the comics as I've never read them). Specifically, Hiro's "microbots". Each one needs an address to be able to communicate with the controller device. Even with the numbers of them, can probably be handled with a /64, but you'd also probably want them in separate "buckets" if you're doing separated tasks. Even so, a /48 could EASILY handle it. Now make them the size of a large-ish molecule. Or atom. Or protons. Nanotech or femtotech that's advanced enough gets into Clarke's Law - any sufficiently advanced technology is indistinguishable from magic - but in order to do that they need to communicate. If you think that won't be possible in the next 30 years, you probably haven't been paying attention. However, that's - barring a fundamental breakthrough - probably a decade or two off. Meanwhile we've got connected soda cans to worry about. I wrote my email as a way of pointing out that maybe the concerns (on both sides)- aren't baseless, but at the same time maybe there's a way to split the difference. It's not too much of a stretch to see that, soon, 256 subnets may not actually be enough to deal with the connected world and "Internet of Things" that's currently being developed. But would 1024? How about 4096? Is there any need in the next 10-15 years for EVERYONE to be getting handed 65,536 /64 subnets? Split the difference, go with a /52 and suddenly you've got FOUR THOUSAND subnets for individual users so that their soda cans can tell the suspension on their car that it's been opened and please smooth out the ride. Frankly, both sides seem intent on overkill in their preferred direction, and it's not particularly hard to meet in the middle. On Tue, Jul 14, 2015 at 8:38 PM, Doug Barton <dougb@dougbarton.us> wrote:

On 7/14/15 6:23 AM, George Metz wrote:

...

It's always easier to be prudent from the get-go than it is to rein in the insanity at a later date. Just because we can't imagine a world where IPv6 depletion is possible doesn't mean it can't exist, and exist far sooner than one might expect.

I've been trying to stay out of this Nth repetition of the same nonsensical debate, since neither side has anything new to add. However George makes a valid point, which is "learn from the mistakes of the past."

So let me ask George, who seems like a reasonable fellow ... do you think that creating an addressing plan that is more than adequate for even the wildest dreams of current users and future growth out of just 1/8 of the available space (meaning of course that we have 7/8 left to work with should we make a complete crap-show out of 2000::/3) constitutes being prudent, or not?

And please note, this is not a snark, I am genuinely interested in the answer. I used to be one of the people responsible for the prudent use of the integers (as the former IANA GM) so this is something I've put a lot of thought into, and care deeply about. If there is something we've missed in concocting the current plan, I definitely want to know about it.

Even taking into account some of the dubious decisions that were made 20 years ago, the numbers involved in IPv6 deployment are literally so overwhelming that the human brain has a hard time conceiving of them. Combine that with the conservation mindset that's been drilled into everyone regarding IPv4 resources, and a certain degree of over-enthusiasm for conserving IPv6 resources is understandable. But at the same time, because the volume of integers is so vast, it could be just as easy to slip into the early-days v4 mindset of "infinite," which is why I like to hear a good reality check now and again. :)

Doug

-- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks!