On Dec 17, 2017, at 14:33, Matt Hoppes <mattlists@rivervalleyinternet.net> wrote:

Had a previous employee or I discovered it on the network segment after we had some weird routing issues and had to get that cleaned up. I don't know why anyone would do that when there is tons of private IP space.

Unless there isn't.. I've worked at more than one company that had used up all the private space. Then you have the cases where some M&A causes overlapping IP space. In addition, you'd also be surprised how many people just assign the entire 10/8 space into a flat IP space. -j

Missent. Welcome to IPv6, where you have technically-reserved-for-future-use space that should never actually need to be used. Quite likely, you can use something like 440::/16 as your private space, but please don't do that unless you've exhausted the true private space. You're welcome. On 17/12/2017 14:57, James Downs wrote:

...

On Dec 17, 2017, at 14:33, Matt Hoppes <mattlists@rivervalleyinternet.net> wrote:

Had a previous employee or I discovered it on the network segment after we had some weird routing issues and had to get that cleaned up. I don't know why anyone would do that when there is tons of private IP space. Unless there isn't.. I've worked at more than one company that had used up all the private space. Then you have the cases where some M&A causes overlapping IP space. In addition, you'd also be surprised how many people just assign the entire 10/8 space into a flat IP space.

-j

My previous employer used 198.18/15 for CE links on IPVPN services. Walgreens used an American SP's space internally and couldn't talk to any users in that space as a result. On Sun, Dec 17, 2017 at 11:31 PM, Eric Kuhnke <eric.kuhnke@gmail.com> wrote:

some fun examples of the size of ipv6:

https://samsclass.info/ipv6/exhaustion-2016.htm

https://www.reddit.com/r/theydidthemath/comments/2qxgxw/self_just_how_big_is...

On Sun, Dec 17, 2017 at 7:05 PM, Large Hadron Collider < large.hadron.collider@gmx.com> wrote:

...

Missent.

Welcome to IPv6, where you have technically-reserved-for-future-use space that should never actually need to be used. Quite likely, you can use something like 440::/16 as your private space, but please don't do that unless you've exhausted the true private space.

You're welcome.

On 17/12/2017 14:57, James Downs wrote:

...

On Dec 17, 2017, at 14:33, Matt Hoppes <mattlists@rivervalleyinternet.net>

...

wrote:

Had a previous employee or I discovered it on the network segment after we had some weird routing issues and had to get that cleaned up. I don't know why anyone would do that when there is tons of private IP space.

Unless there isn't.. I've worked at more than one company that had used up all the private space. Then you have the cases where some M&A causes overlapping IP space. In addition, you'd also be surprised how many people just assign the entire 10/8 space into a flat IP space.

-j

In a message written on Mon, Dec 18, 2017 at 08:58:37AM -0500, Jason Iannone wrote:

My previous employer used 198.18/15 for CE links on IPVPN services.

This one is mostly legit: https://tools.ietf.org/html/rfc5735 -- Leo Bicknell - bicknell@ufp.org PGP keys at http://www.ufp.org/~bicknell/

While a single network gets at /64, isn't the practice suppose to be providers allocating a /56 or a /60 for home users (you know so your IOT, wired lan, wifi, guest network, gaming systems, bathroom, bedroom, etc. can all be on their own networks)? ----------------------------------------------------------------------------------------------- -ITG (ITechGeek) | ITG@ITechGeek.Com <https://itg.nu/> https://keybase.io/itechgeek | https://itg.nu/ Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: http://fb.me/Jbwa.Net On Mon, Dec 18, 2017 at 6:09 PM, William Herrin <bill@herrin.us> wrote:

On Sun, Dec 17, 2017 at 11:31 PM, Eric Kuhnke <eric.kuhnke@gmail.com> wrote:

...

some fun examples of the size of ipv6:

https://samsclass.info/ipv6/exhaustion-2016.htm

https://www.reddit.com/r/theydidthemath/comments/ 2qxgxw/self_just_how_big_is_ipv6/

Hi Eric,

Lies, damn lies and statistics. Both projections assume that IPv6 addresses are assigned the same way we assign IPv4 addresses. They are not.

There are several practices which consume IPv6 at a drastically higher rate than IPv4. The most notable is the assignment of a /64 to every LAN. Your /26 LAN that used to consume 2^6th IP addresses? Now it's 2^64th. Used to consume RFC1918 addresses? Now it's 2^64th of the global IPv6 addresses.

Why did we need a /64 for each LAN? So we could incorporate the Ethernet MAC address in to the IP address. Only we can't actually do that because it turns out to be crazy insecure. Nevertheless, the 3 computers in your basement will still consume 2^64th IPv6 addresses between them. But hey, what's 20 orders of magnitude between friends.

We have ISPs that have received allocations of entire /19s. A /19 in IPv6 is exactly the same percentage of the total address space as a /19 in IPv4. Before considering reserved addresses, it's 1/2^19th of the total address space. For a single ISP. Think about it.

Meanwhile the IETF has learned nothing from the gargantuan waste that is 224.0.0.0/4 ($2billion at current prices). They went and assigned FC00::/7. /7!! Almost 1% of the IPv6 address space gone in a single RFC.

I haven't attempted to compute the actual rate of IPv6 consumption but it's not inconceivable that we could exhaust them by the end of the century through sheer ineptitude.

On the plus side, we're mostly only screwing around with 2000::/3 right now. After we burn through that in the next 20 years, we can if we so desire change the rules for how (and how quickly) we use 4000::/3.

Regards, Bill Herrin

-- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>

On 2017-12-19 12:18 PM, UpTide . wrote:

If we allocate a /64 like we do single ipv4 addresses now the space gets 2^56 (16777216) times larger; but if we start doing something crazy like allocating a /48 or /56 that number plummets. (256 times larger, and 65536 times larger respectfully.)

But then again I'm bad with math, maybe not?

You most certainly are. There are (2^32)*(2^32) in 2^64, meaning everyone who has a /32 of IPv4 would get about 4 billion /64s if we chopped it all up the same way. Or 65536 /48s, or 16777216 /56s. I think the argument is not that there isn't enough address space to go around; more that profligate allocations to begin with may restrict future options on a century-scale timeline.

On Dec 19, 2017, at 18:22 , Valdis.Kletnieks@vt.edu wrote:

On Tue, 19 Dec 2017 20:18:57 +0000, "UpTide ." said:

...

If we allocate a /64 like we do single ipv4 addresses now the space gets 2^56 (16777216) times larger; but if we start doing something crazy like allocating a /48 or /56 that number plummets. (256 times larger, and 65536 times larger respectfully.)

You seem to have missed an entire octet's worth of bits, so off by a factor of 256…

That’s OK… You seem to have your directions reversed...

A /48 is 16 more bits than a /32, so 65536 times bigger.

You mean smaller.

A /56 is 24 more bits than a /32, so 16777216 times bigger.

You mean smaller.

And a /64 is 32 bits more than a /32... so....

Given that a /33 is just about enough to give everybody in the planet one, giving away 8 million times that many is going to be a challenge, unless somebody invents nanotech that wants a separate address for each nanomachine.

Not outside the realm of possibility, but they’d need to invent nonotech that resulted in 8+million * 18 quintillion machines per person to really cause a problem.

But I'd argue that if I have personal nanotech, I *really* want to use ULA addresses. They're *my* nanotech. :)

Feel free. Personally, I still see ULA as an absurdity. Owen

On Tue, Dec 19, 2017 at 2:56 PM, ITechGeek <ITG@itechgeek.com> wrote:

While a single network gets at /64, isn't the practice suppose to be providers allocating a /56 or a /60 for home users (you know so your IOT, wired lan, wifi, guest network, gaming systems, bathroom, bedroom, etc. can all be on their own networks)?

Yes, that's what it's _supposed_ to be. Anything from a /48 to a /60 is reasonable given the way IPv6 is intended to be used. My personal preference is /56 by default, /48 by request. Providers assigning a single /64 or a /128 to an always-on customer are doing it wrong. You know who you are. If this seems inconsistent with my last email, my key point there was not that we're using IPv6 in a crazy way (although to some extent we are) but rather that the IPv6 address space is by tens of orders of magnitude much smaller than you think. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>

Comcast, at least in my neck of the woods, hands out /56s. On 12/19/17 4:03 PM, Grant Taylor via NANOG wrote:

On 12/19/2017 01:55 PM, William Herrin wrote:

...

Providers assigning a single /64 or a /128 to an always-on customer are doing it wrong. You know who you are.

The cable ISP that I had (prior to moving) assigned a single /64 for the outside of the router.  I could also request provider delegation for something that I could use internally breaking into multiple /64s.  I just don't remember if it was a /56 or /60.

The point being that the outside of the SOHO router and the inside PD were two different DHCP processes, both of which needed to happen.

On Dec 18, 2017, at 15:09 , William Herrin <bill@herrin.us> wrote:

On Sun, Dec 17, 2017 at 11:31 PM, Eric Kuhnke <eric.kuhnke@gmail.com> wrote:

...

some fun examples of the size of ipv6:

https://samsclass.info/ipv6/exhaustion-2016.htm

https://www.reddit.com/r/theydidthemath/comments/ 2qxgxw/self_just_how_big_is_ipv6/

Hi Eric,

Lies, damn lies and statistics. Both projections assume that IPv6 addresses are assigned the same way we assign IPv4 addresses. They are not.

There are several practices which consume IPv6 at a drastically higher rate than IPv4. The most notable is the assignment of a /64 to every LAN. Your /26 LAN that used to consume 2^6th IP addresses? Now it's 2^64th. Used to consume RFC1918 addresses? Now it's 2^64th of the global IPv6 addresses.

Why did we need a /64 for each LAN? So we could incorporate the Ethernet MAC address in to the IP address. Only we can't actually do that because it turns out to be crazy insecure. Nevertheless, the 3 computers in your basement will still consume 2^64th IPv6 addresses between them. But hey, what's 20 orders of magnitude between friends.

We have ISPs that have received allocations of entire /19s. A /19 in IPv6 is exactly the same percentage of the total address space as a /19 in IPv4. Before considering reserved addresses, it's 1/2^19th of the total address space. For a single ISP. Think about it.

Sure… However, we have a few very large ISPs that have received /19s (~1/524,288 of the total space each). Unlike IPv4 where we have thousands and thousands of ISPs and even some end users that have more than a /19. Do you really think we’re anywhere near likely to have 500 ISPs world wide that get /19s, let alone 524,288? An IPv6 /19 provides enough addressing in IPv6 to give out 2^29 or roughly 536 million customers /48s. Even if we allow for pretty large overhead, there’s still plenty of address space there for ~100 million customer /48s. Let’s round up the 7 billion current population to 10 for the sake of conservatism, even still we only need roughly 100 ISPs that size to handle everyone on the planet. If we allow for some overlap and then quadruple the requirement to cover content-side needs in addition to eyeballs, that’s still less than 1,000 /19 sized allocations needed. So, even at that rate, we’ve still got 523,288 /19s left.

Meanwhile the IETF has learned nothing from the gargantuan waste that is 224.0.0.0/4 ($2billion at current prices). They went and assigned FC00::/7. /7!! Almost 1% of the IPv6 address space gone in a single RFC.

As much as I consider the fc00::/7 reservation to be ridiculous, the reality is that RFC-1918 wasn’t that much short of the 1% mark in IPv4, either. The reservation of fc00::/7 is much more analogous to RFC-1918 than to 224.0.0.0/4. In fact, fd00::/8 is analogous to 224.0.0.0/4 and I think that use makes sense in both cases. While multicast didn’t take off or work out well in IPv4, a smaller address space would only have made that worse. I think that your real target was 240.0.0.0/4, which was set aside for experimental and other undefined purposes and never really got used for much of anything. Unfortunately, if you want to claim the IETF didn’t lear the lesson there, it’s a bit harder since there’s no such reservation in IPv6,

I haven't attempted to compute the actual rate of IPv6 consumption but it's not inconceivable that we could exhaust them by the end of the century through sheer ineptitude.

Well, to the best of my knowledge, no RIR has yet requested a second /12. I’ll be surprised if we burn through the first /3 using current allocation practices within my lifetime. If we do, then I’ll join your quest to burden IPv6 with more restrictive allocation practices for the remaining 5 virgin /3s and the remaining space in the other 2.

On the plus side, we're mostly only screwing around with 2000::/3 right now. After we burn through that in the next 20 years, we can if we so desire change the rules for how (and how quickly) we use 4000::/3.

However, even if your prediction somehow comes true and we don’t change the rules, that gives us roughly a 120 year timeframe for running out of the existing /3 and the remaining 5 /3s that have not been touched, without even invading ::/3 or e000::/3 (the first and last /3s which each have some carve-outs, but remain mostly free space as well). If we don’t end up needing to fix other things and replace the codebase with something that would allow us to redo the address space in the next 120 years, I’ll be quite surprised. Owen

On 12/17/2017 08:31 PM, Eric Kuhnke wrote:

some fun examples of the size of ipv6:

https://samsclass.info/ipv6/exhaustion-2016.htm

https://www.reddit.com/r/theydidthemath/comments/2qxgxw/self_just_how_big_is...

Every time I see these "Look how many more addresses we have now with IPv6", I just shake my head.   Yes, the address space is very large. But, all of the protocols, all of the addressing guides, all of the operational 'best practices', ALL OF IT, increases by orders of magnitude the amount of waste along with it. Call this the 'shavings', in IPv4 for example, when you assign a P2P link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, due to ping-pong and just so many technical manuals and other advices, you are told to "just use a /64' for your point to points. So, the actual waste is dilutes the actual implementable size of the total ipv6 address space due to the waste component. And I have not yet seen any study or even proposed theory to explore what the IPv6 Internet would look like, if used in place of all IPv4 in all the places and ways that it's used. I think, in time, we will discover that we have only increased our usable ip space by no more than 2 orders of magnitude over that which is achieved in ipv4, and we will be looking again at a global ip protocol upgrade I bet within my lifetime. While we are at it, why is nobody thinking or talking about the looming exhaustion of ieee OUI addresses? Network cards made 15 years ago and since consigned to the electronics scrap heap in the sky, take with them their addresses never to be reused again (unless you are a freak like me and keep some for 'positively never assigned anywhere'). And old dead companies that were assigned OUIs, they get 24 bits of address space to take to their graves. We should be re-thinking mac addressing altogether too. (Please no hate mail, these opinions are strictly mine...) Mike-

On Wed, Dec 20, 2017 at 1:48 PM, Mel Beckman <mel@beckman.org> wrote:

I won’t do the math for you, but you’re circumcising the mosquito here. We didn’t just increase our usable space by 2 orders of magnitude. It’s increased more than 35 orders of magnitude.

Hi Mel, The gain is just shy of 29 orders of magnitude. 2^128 / 2^32 = 7.9*10^28. There are 2^128 = 3.4*10^38 IPv6 addresses, but that isn't 38 "orders of magnitude." Orders of magnitude describes a difference between one thing and another, in this case the IPv4 and IPv6 address spaces. Using a /64 for P2P links is no problem, really. Worrying about that is

like a scuba diver worrying about how many air molecules are surrounding the boat on the way out to sea.

It's not a problem, exactly, but it cuts the gain vs. IPv4 from ~29 orders of magnitude to just 9 orders of magnitude. Your link which needed at most 2 bits of IPv4 address space now consumes 64 bits of IPv6 address space. Then we do /48s from which the /64s are assigned and we lose another 3 or so orders of magnitude... Sparsely allocate those /48s for another order of magnitude. From sparsely allocated ISP blocks for another order of magnitude. It slips away faster than you might think. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>

And something in the message stream tried to convert my elegantly computed result into a phone number. Sigh. -mel

On Dec 20, 2017, at 1:39 PM, Mel Beckman <mel@beckman.org> wrote:

[This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]

Bill,

You are correct.

As a double check, I divided 340282366920938463463374607431768211456 by 4294967296, getting 79228162514264<tel:79%20228%20162%20514%20264>337593543950336<tel:337%20593%20543%20950%20336>, which is 28.8 orders of magnitude :)

-mel

On Dec 20, 2017, at 12:58 PM, William Herrin <bill@herrin.us<mailto:bill@herrin.us>> wrote:

On Wed, Dec 20, 2017 at 1:48 PM, Mel Beckman <mel@beckman.org<mailto:mel@beckman.org>> wrote: I won’t do the math for you, but you’re circumcising the mosquito here. We didn’t just increase our usable space by 2 orders of magnitude. It’s increased more than 35 orders of magnitude.

Hi Mel,

The gain is just shy of 29 orders of magnitude. 2^128 / 2^32 = 7.9*10^28.

There are 2^128 = 3.4*10^38 IPv6 addresses, but that isn't 38 "orders of magnitude." Orders of magnitude describes a difference between one thing and another, in this case the IPv4 and IPv6 address spaces.

Using a /64 for P2P links is no problem, really. Worrying about that is like a scuba diver worrying about how many air molecules are surrounding the boat on the way out to sea.

It's not a problem, exactly, but it cuts the gain vs. IPv4 from ~29 orders of magnitude to just 9 orders of magnitude. Your link which needed at most 2 bits of IPv4 address space now consumes 64 bits of IPv6 address space.

Then we do /48s from which the /64s are assigned and we lose another 3 or so orders of magnitude... Sparsely allocate those /48s for another order of magnitude. From sparsely allocated ISP blocks for another order of magnitude. It slips away faster than you might think.

Regards, Bill Herrin

-- William Herrin ................ herrin@dirtside.com<mailto:herrin@dirtside.com> bill@herrin.us<mailto:bill@herrin.us> Dirtside Systems ......... Web: <http://www.dirtside.com/>

When the IETF decided on 128 bit addresses it was taking into consideration /80 sized subnet. Prior to that it was looking at a 64 bit address size and allocating addresses the IPv4 way with lots of variable sized networks. This was changed to /64 subnets to accomodate 64 bit MAC. After that there was discussion about how many subnet should be enough for 99.99% of sites which gave /48 per site using /64 sized network. That 281474976710656 sites or 35184372088832 out of the /3 we are currently allocating from. Now there are very few sites that need 65536 subnets and those that do can request additional /48’s. Now if you assume the earth’s population will get to 25B, and every person is a site, that still leaves 35159372088832 sites. And if each of those people also has a home and a vehicle, that still leaves 35109372088832 sites. Handing out /48’s to homes was never ever going to cause us to run out of IPv6 space. Even if the homes are are connected to multiple providers there isn’t a issue. Mark

On 21 Dec 2017, at 7:57 am, William Herrin <bill@herrin.us> wrote:

On Wed, Dec 20, 2017 at 1:48 PM, Mel Beckman <mel@beckman.org> wrote:

...

I won’t do the math for you, but you’re circumcising the mosquito here. We didn’t just increase our usable space by 2 orders of magnitude. It’s increased more than 35 orders of magnitude.

Hi Mel,

The gain is just shy of 29 orders of magnitude. 2^128 / 2^32 = 7.9*10^28.

There are 2^128 = 3.4*10^38 IPv6 addresses, but that isn't 38 "orders of magnitude." Orders of magnitude describes a difference between one thing and another, in this case the IPv4 and IPv6 address spaces.

Using a /64 for P2P links is no problem, really. Worrying about that is

...

like a scuba diver worrying about how many air molecules are surrounding the boat on the way out to sea.

It's not a problem, exactly, but it cuts the gain vs. IPv4 from ~29 orders of magnitude to just 9 orders of magnitude. Your link which needed at most 2 bits of IPv4 address space now consumes 64 bits of IPv6 address space.

Then we do /48s from which the /64s are assigned and we lose another 3 or so orders of magnitude... Sparsely allocate those /48s for another order of magnitude. From sparsely allocated ISP blocks for another order of magnitude. It slips away faster than you might think.

Regards, Bill Herrin

-- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>

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

The RIR’s assignment to ISPs assume relatively dense assignment of /48 to customers. ISPs still have to justify the allocation based on the number of customers sites for shorter than a /32. RIR assignments to non ISPs are also relatively dense. If you have multiple sites you don’t need contiguous addresses. Automatic assignment in homenet does dense assignment.

On 21 Dec 2017, at 12:27 pm, William Herrin <bill@herrin.us> wrote:

On Wed, Dec 20, 2017 at 4:57 PM, Mark Andrews <marka@isc.org> wrote: Handing out /48’s to homes was never ever going to cause us to run out of IPv6 space. Even if the homes are are connected to multiple providers there isn’t a issue.

Hi Mark,

No single assignment practice would. Sadly no IPv6 addresses reach your computer directly from IANA. Multiple layers of assignment practices are happen along the way, each with it's own cumulative consumption. Most of those layers were designed with the independent assumption that "we have so many IPv6 addresses, let's just not worry about how many bits are consumed at this step." With a cumulative effect on the consumption of IPv6 space.

Regards, Bill Herrin

-- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>

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

A very familiar pattern. Pretty soon, our children will be going to intergalactic governance fora debating v6 exhaustion and dusting off Jim Fleming’s ipv9 -srs —srs On Thu, Dec 21, 2017 at 8:48 PM +0530, "Jason Iannone" <jason.iannone@gmail.com> wrote: M&A plays into this too. By my calculations, CenturyLink controls at least 17 million /48s. How many sites does CenturyLink provide service to? I'm gonna go out on a limb and say it's not 17 million. 3 acquisitions rolled up into AS209: as3549 2605:a300::/32 2001:450::/32 as4323 2604:6680::/32 2602:ff99::/36 2620:12e:6000::/40 2620:10e:8000::/40 2620:124:8000::/44 2001:506:8::/48 2620:75::/48 2620:f:4000::/48 2620:3b:4000::/48 2620:c5:4000::/48 as3356 2607:6e00::/32 2606:8a00::/32 2604:3a00::/32 2605:1280::/32 2605:4680::/32 2605:c680::/32 2604:24c0::/32 2602:ffeb::/36 2602:ffe1::/36 2620:109::/40 2620:123:d000::/40 2620:12d:c000::/44 2620:42:4000::/48 2620:87:4000::/48 2620:8d:c000::/48 2620:ba:c000::/48 2620:f8:c000::/48 2604:5200:1007::/48 2620:6:e000::/48 as209 2602::/24 2606:5000::/32 2605:c680::/32 2602:ff5f::/36 2620:123:3000::/40 2620:12e:6000::/40 2620:9c:4000::/44 2620:122:4000::/44 2620:123:b000::/44 2001:428:902::/48 2001:428:7001::/48 2001:428:7004::/48 2001:428:4004::/48 2001:428:3000::/48 2001:428:2403::/48 2001:428:7005::/48 2001:428:939::/48 2001:428:6803::/48 2001:428:5003::/48 2001:428:e203::/48 2001:428:3804::/48 2620:0:2280::/48 2620:0:2b20::/48 2001:428:4c04::/48 2001:428:4c05::/48 2001:428:5004::/48 2001:428:1403::/48 2001:428:1404::/48 2001:428:6804::/48 2001:428:2502::/48 2001:428:2501::/48 2001:428:200c::/48 2001:428:480a::/48 2620:d9:8000::/48 2001:428:5804::/48 2001:428:2406::/48 2001:428:1804::/48 2001:428:2405::/48 2001:428:2408::/48 2001:428:1c03::/48 2001:428:6403::/48 2001:428:1803::/48 2001:428:7009::/48 2001:428:5806::/48 2620:42:4000::/48 2001:428:1405::/48 2001:428:3c03::/48 2001:428:e204::/48 2001:428:e205::/48 2001:428:1806::/48 2001:428:6805::/48 2001:428:1808::/48 2001:428:1809::/48 2001:428:a403::/48 2001:428:4407::/48 2001:428:3807::/48 2001:428:c0c::/48 2001:428:4003::/48 2001:428:4803::/48 2001:428:1003::/48 2001:428:3808::/48 2001:428:30::/48 2620:ac:c000::/48 2001:428:700c::/48 2001:428:5803::/48 2001:428:380b::/48 2001:428:380c::/48 2001:428:380d::/48 2001:428:4403::/48 2001:428:aa03::/48 2001:428:4404::/48 2001:428:2407::/48 2001:428:240b::/48 2001:428:4c09::/48 2001:428:700a::/48 2001:428:c08::/48 2001:428:2004::/48 2001:428:2404::/48 2001:428:7007::/48 2001:428:7405::/48 2001:428:c0b::/48 2001:428:4406::/48 2001:428:c05::/48 2001:428:c06::/48 2001:428:3805::/48 2001:428:4c07::/48 2001:428:2003::/48 2001:428:2005::/48 2001:428:6404::/48 2001:428:7404::/48 2001:428:240a::/48 2001:428:4405::/48 2001:428:4c08::/48 2001:428:2002::/48 2001:428:c09::/48 2001:428:240e::/48 2001:428:4408::/48 2001:428:380e::/48 2001:428:4005::/48 2001:428:4409::/48 2001:428:a404::/48 2001:428:1004::/48 2001:428:8c03::/48 2001:428:9e03::/48 2001:428:3810::/48 2001:428:700d::/48 2001:428:2006::/48 2001:428:6405::/48 2001:428:a405::/48 2001:428:8c04::/48 2001:428:5805::/48 2620:74:c040::/48 2620:6:e000::/48 2001:428:1805::/48 2001:428:b003::/48 2001:428:3c04::/48 2001:428:6400::/48 2001:428:8c00::/48 2001:428:9e00::/48 2001:428:1c00::/48 2001:428:7006::/48 2001:428:4c00::/48 2001:428:2400::/48 2001:428:7008::/48 source: source: http://irrexplorer.nlnog.net/static/dumps/arin-whois-originas.json.bz2 Jason On Wed, Dec 20, 2017 at 8:47 PM, Mark Andrews wrote:

The RIR’s assignment to ISPs assume relatively dense assignment of /48 to customers. ISPs still have to justify the allocation based on the number of customers sites for shorter than a /32. RIR assignments to non ISPs are also relatively dense. If you have multiple sites you don’t need contiguous addresses.

Automatic assignment in homenet does dense assignment.

...

On 21 Dec 2017, at 12:27 pm, William Herrin wrote:

On Wed, Dec 20, 2017 at 4:57 PM, Mark Andrews wrote: Handing out /48’s to homes was never ever going to cause us to run out of IPv6 space. Even if the homes are are connected to multiple providers there isn’t a issue.

Hi Mark,

No single assignment practice would. Sadly no IPv6 addresses reach your computer directly from IANA. Multiple layers of assignment practices are happen along the way, each with it's own cumulative consumption. Most of those layers were designed with the independent assumption that "we have so many IPv6 addresses, let's just not worry about how many bits are consumed at this step." With a cumulative effect on the consumption of IPv6 space.

Regards, Bill Herrin

-- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web:

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

On 2017-12-21 08:58, Christopher Morrow wrote:

On Thu, Dec 21, 2017 at 10:16 AM, Jason Iannone <jason.iannone@gmail.com> wrote:

...

M&A plays into this too. By my calculations, CenturyLink controls at least 17 million /48s. How many sites does CenturyLink provide service to? I'm gonna go out on a limb and say it's not 17 million.

there are less than 17m households served by centurylink's residential product? really? each of those could be considered a site and then get a /48.

Speaking non-hypothetically, there's some shoddy network address management at play there. I can state for a fact that there's at least one /48 (and I imagine many more) in Jason's list that hasn't been valid for over three years. The IPv4 side of that circuit (a /25) is also still SWIP'd -- not that it's meaningfully usable in the DFZ. Therein lies a (minor, I hope) flaw in Job Snijders' proposal to use ARIN OriginAS data for determining routing authorization: ISPs have to not suck at cleaning up SWIP entries for dormant circuits. I (as a customer) tried to get my employer's entries removed three months ago, but no one cared enough to follow up. (Also, I doubt the vast majority of CenturyLink's residential customer base a) has non-tunneled IPv6 or b) receives a /48.) If anyone from AS209 wants to clean up those SWIPs, they're welcome to ping me off-list. :-) - Jima

William Herrin wrote:

It's not a problem, exactly, but it cuts the gain vs. IPv4 from ~29 orders of magnitude to just 9 orders of magnitude. Your link which needed at most 2 bits of IPv4 address space now consumes 64 bits of IPv6 address space.

Then we do /48s from which the /64s are assigned and we lose another 3 or so orders of magnitude... Sparsely allocate those /48s for another order of magnitude. From sparsely allocated ISP blocks for another order of magnitude. It slips away faster than you might think.

Regards, Bill Herrin

When you consider that the default starting ISP size is /32, and that is sufficient to address something less than 64k subscribers, purist style, in broadest possible theoretical terms the following emerges. a) ipv6 has one ISP per every 1.x human (enough?), IPv4 has one IP per every 1.x human (not enough) b) IPv4 has 64k ISP's capable of servicing 64k customers, IPv6 has 64k multiples of that. So that will be one paradigm shift and one order of magnitude (exponentially speaking) for your total. There is plenty more to wonder about, for example, will the rest of the unicast space get Class E'd? Joe

I think he's referring to all the Unicast IPv6 outside of 2000::/3 getting designated as "reserved", and therefore no gear will ever successfully route it... just like happened with the Class E space. You'd think we would know better than to let that happen, but there's a lot of things you'd think we would know better than to let happen, and yet it still happens, with dreary regularity. On Wed, Dec 20, 2017 at 7:14 PM, <valdis.kletnieks@vt.edu> wrote:

On Wed, 20 Dec 2017 18:15:44 -0500, Joe Maimon said:

...

There is plenty more to wonder about, for example, will the rest of the unicast space get Class E'd?

That's a non-starter, as pretty much all the gear out there has code that says 'Class E is reserved" (including gear that's *already* doing production IPv6). If you're going to upgrade everything *anyhow*, deploying IPv6 has better bang for the buck than Class E support.

On 20 December 2017 at 13:23, Mike <mike-nanog@tiedyenetworks.com> wrote:

in IPv4 for example, when you assign a P2P link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, due to ping-pong and just so many technical manuals and other advices, you are told to "just use a /64' for your point to points.

There are 2^64 *networks* available in IPv6. That's 2^32 times as many *networks* as there are IPv4 *addresses*. That doesn't mean twice as many; that means almost 4.3 BILLION times as many. Yeah, go ahead and use a /64 for your point-to-point networks. Or don't; there are ways to use /128s carved out of a single /64 (I do so on my private VPNs), and then route the whole /64 to my VPN concentrator). -- Harald

On 20 December 2017 at 21:01, Aaron Gould <aaron1@gvtc.com> wrote:

I wonder if the 20 bit mpls label will be re-thought down the road also ?

No comment to the IPv6 discussion. But size of MPLS label is consideration, and we do spend two labels for one thing, partly due to size limit, partly due to the lack of expressiveness of MPLS label wire-format. Examples of such things are ELI and Extension Label. There are more and more consumers for MPLS labels, and canonical implementation (label manager) gives each consumer own dedicated block, this alone makes 20b less than arbitrarily large. -- ++ytti

Maybe my analogy of "billion" doesn’t correctly compare to 2^128 ip addresses -Aaron

Lee Howard <lee@asgard.org> writes:

I’ve tried several times to come up with a scenario that leads to depletion in less than 200 years, and I haven’t managed it. Can you do it?

Self replicating nano bots. Which will be a good thing (probably): https://xkcd.com/865/ SCNR Jens -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@quux.de | --------------- | ----------------------------------------------------------------------------

On Wed, Dec 20, 2017 at 2:16 PM, Lee Howard <lee@asgard.org> wrote:

I’ve tried several times to come up with a scenario that leads to depletion in less than 200 years, and I haven’t managed it. Can you do it?

during some ARIN discussions that revolved around Transition Technologies and allocations to large ISPs, there were more than a few folk batting around the idea that they may need to allocate a /24 or a /20 even to a single provider. I believe DT has a /19 assigned to them currently? how many /19's are there in the v6 space? (524288-ish) That's only ~100x the current number of active ASN in the field. It's unclear (to me) how many of those could/would justify a /19 equivalent, and how fast the ASN field is growing over time. 200 years seems optomistic, 20 years seems easy to imagine surpassing though. What's the sweet spot?

On Thu, Dec 21, 2017 at 11:20 AM, Lee Howard <lee@asgard.org> wrote:

From: <christopher.morrow@gmail.com> on behalf of Christopher Morrow < morrowc.lists@gmail.com> Date: Wednesday, December 20, 2017 at 6:07 PM To: Lee Howard <lee@asgard.org> Cc: Mike <mike-nanog@tiedyenetworks.com>, nanog list <nanog@nanog.org> Subject: Re: Waste will kill ipv6 too

On Wed, Dec 20, 2017 at 2:16 PM, Lee Howard <lee@asgard.org> wrote:

...

I’ve tried several times to come up with a scenario that leads to depletion in less than 200 years, and I haven’t managed it. Can you do it?

during some ARIN discussions that revolved around Transition Technologies and allocations to large ISPs, there were more than a few folk batting around the idea that they may need to allocate a /24 or a /20 even to a single provider.

I believe DT has a /19 assigned to them currently? how many /19's are there in the v6 space? (524288-ish) That's only ~100x the current number of active ASN in the field. It's unclear (to me) how many of those could/would justify a /19 equivalent, and how fast the ASN field is growing over time.

DT is one of the largest ISPs in the world, isn’t it?

it's large, but really it's going to hit the same number of homes (about) as att/verizon/comcast/embarq ... and I'm sure ntt, 'russian cableco', the 5 china-cablecos etc. Right? germany is ~83m people... 100x that is about 1.2x world population, so ... it seems conceivable that there are ~100 isps (one per country) about the same size, right?

Can you devise a scenario in which there are 524,288 ISPs the size of DT?

I think I did something in my reply which I should not have done, I conflated the DT issue and the transition technology discussion...splitting those up: 1) For DT, my understanding is that their allocation is this size due to part of their deployment plan/technology. (multiple /48's per site, one per particular technology in use - video, voice, intertubes, on-demand-video, something...7/site I believe was their target) 2) For the transition technology discussion I believe it centered around attempting to get a /48 to each 'site' (home/customer) and doing ds-lite as the transition technology in use. (map the customer to not a /128 in the ds-lite, but a /48)

Or one where every currently active ASN, times 100X, needs/justifies a /19?

200 years seems optomistic, 20 years seems easy to imagine surpassing though. What's the sweet spot?

200 years seems pessimistic to me. Every scenario I run uses ridiculously profligate assumptions, and usually multiplies those by a few orders of magnitude. Even extrapolating from your math above, I don’t get less than 2222CE.

ok. I think a bunch of the analysis so far in this thread has basically assumed dense packing at teh ISP and RIR level.. which really won't happen, in practice anyway. I was simply stating that if we follow some of the examples today it's no where near as certain (I think) that '200' is ok to assume. A larger point is: "so what?" we've run a number conversion / renumbering once... we can do it again, better the second time, right? :) Maybe this next time we'll even plan based on lessons learned in the v4 -> v6 slog?

Lee

Owen DeLong wrote:

200 might be optimistic, agreed. I think 100 is pretty well assured absent something much more profligate than current policies.

Profligacy based on the assumption of exhaustion impossibility needs to be avoided. Agreed.

...

we've run a number conversion / renumbering once... we can do it again, better the second time, right? :) Maybe this next time we'll even plan based on lessons learned in the v4 -> v6 slog? Technically, we’ve run one, we’re running a second one now, and yeah, hopefully lessons learned can play a part.

Of course this also ignores the third transition which included a numbering transition as enterprises went from running everything else (x.25, vines, IPX, DECNET, AppleTalk, etc.) to IP.

Owen

The lesson we are still learning is that the longer entrenched and successful a numbering scheme is, the more monumental the conversion effort becomes. And that therefore we should never again do one, as we have every intention of this scheme vastly exceeding the old one. Joe

On Thu, Dec 21, 2017 at 3:21 PM, Mark Andrews <marka@isc.org> wrote:

...

On 22 Dec 2017, at 3:48 am, Christopher Morrow <morrowc.lists@gmail.com> wrote:

2) For the transition technology discussion I believe it centered around attempting to get a /48 to each 'site' (home/customer) and doing ds-lite as the transition technology in use. (map the customer to not a /128 in the ds-lite, but a /48)

I think you mean 6rd. DS-Lite doesn’t use any extra IPv6 addresses.

yes, sure, it was some time ago that the discussion happened :(

6rd can be poorly done by embedding the entire IPv4 address in the IPv6 address. Doing that does waste space.

6rd deployment should not require much more IPv6 /48’s than a native IPv6 deployment would. That does require properly configuring your DHCPv4 servers with DIFFERENT 6rd DHCPv4 Option values on a per IPv4 DHCP pool basis which I’m sure every ISP here is capable of doing as there is nothing really new here to do. You have all carved up IPv4 assignments into IPv4 pools. This is no different. You carve up a IPv6 assignments into similar sized pools of /48’s then set the 6rd DHCPv4 Option to the appropriate values for that IPv4 to IPv6 pool mapping. Add the mapping to the BRs and you are done.

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

This may be helpful: https://www.ripe.net/publications/docs/ripe-690/ Regards, Jordi -----Mensaje original----- De: NANOG <nanog-bounces@nanog.org> en nombre de Mike <mike-nanog@tiedyenetworks.com> Responder a: <mike-nanog@tiedyenetworks.com> Fecha: miércoles, 20 de diciembre de 2017, 19:26 Para: <nanog@nanog.org> Asunto: Waste will kill ipv6 too On 12/17/2017 08:31 PM, Eric Kuhnke wrote: > some fun examples of the size of ipv6: > > https://samsclass.info/ipv6/exhaustion-2016.htm > > https://www.reddit.com/r/theydidthemath/comments/2qxgxw/self_just_how_big_is... > Every time I see these "Look how many more addresses we have now with IPv6", I just shake my head. Yes, the address space is very large. But, all of the protocols, all of the addressing guides, all of the operational 'best practices', ALL OF IT, increases by orders of magnitude the amount of waste along with it. Call this the 'shavings', in IPv4 for example, when you assign a P2P link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, due to ping-pong and just so many technical manuals and other advices, you are told to "just use a /64' for your point to points. So, the actual waste is dilutes the actual implementable size of the total ipv6 address space due to the waste component. And I have not yet seen any study or even proposed theory to explore what the IPv6 Internet would look like, if used in place of all IPv4 in all the places and ways that it's used. I think, in time, we will discover that we have only increased our usable ip space by no more than 2 orders of magnitude over that which is achieved in ipv4, and we will be looking again at a global ip protocol upgrade I bet within my lifetime. While we are at it, why is nobody thinking or talking about the looming exhaustion of ieee OUI addresses? Network cards made 15 years ago and since consigned to the electronics scrap heap in the sky, take with them their addresses never to be reused again (unless you are a freak like me and keep some for 'positively never assigned anywhere'). And old dead companies that were assigned OUIs, they get 24 bits of address space to take to their graves. We should be re-thinking mac addressing altogether too. (Please no hate mail, these opinions are strictly mine...) Mike- ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

On 12/20/2017 12:23 PM, Mike wrote:

On 12/17/2017 08:31 PM, Eric Kuhnke wrote: Call this the 'shavings', in IPv4 for example, when you assign a P2P link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, due to ping-pong and just so many technical manuals and other advices, you are told to "just use a /64' for your point to points.

Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the exception would be if a router does not support it. Best regards, Octavio.

Yes, let's talk about waste, Lets waste 2^64 addresses for a ptp. If that was ipv4 you could recreate the entire internet with that many addresses. On 28 December 2017 at 10:39, Owen DeLong <owen@delong.com> wrote:

...

On Dec 28, 2017, at 09:23 , Octavio Alvarez <octalnanog@alvarezp.org> wrote:

On 12/20/2017 12:23 PM, Mike wrote:

...

On 12/17/2017 08:31 PM, Eric Kuhnke wrote: Call this the 'shavings', in IPv4 for example, when you assign a P2P link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, due to ping-pong and just so many technical manuals and other advices, you are told to "just use a /64' for your point to points.

Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the exception would be if a router does not support it.

Best regards, Octavio.

Best practice used most places is to assign a /64 and put a /127 on the interfaces.

Owen

[Deliberate top post] All this fear about “waste” killing IPv6 is unwarranted. It is about time to look at the business aspect of wasting human resources fiddling with micro-optimization. We seem to have have two choices: A. Keep arguing and complicating management of the IPv6 Internet and wasting human resources ==> more cost. B. Deploy IPv6 to end users using the RA/DHCP-PD and the like with the simplest possible templates, e.g., /64+/48 to every edge host/router, no questions asked, thus requiring fewer human resources ==> less cost. Some major networks have long since adopted choice B. The pace of technology change makes likely that "Waste will kill ipv6 too” will be a moot issue by any of the time estimates discussed previously. Any prudent business will choose “B”. Any other choice from this list would be a waste of time and money. See also “Human Use of Human Beings” by Norbert Weiner. Cutler

On Dec 28, 2017, at 12:12 PM, Laszlo Hanyecz <laszlo@heliacal.net> wrote:

On 2017-12-28 17:55, Michael Crapse wrote:

...

Yes, let's talk about waste, Lets waste 2^64 addresses for a ptp. If that was ipv4 you could recreate the entire internet with that many addresses.

After all these years people still don't understand IPv6 and that's why we're back to having to do NAT again, even though we now have a practically endless supply of integers. If we could have all agreed to just do /64+/48 to every edge host/router, no questions asked, we'd never have to talk about this again. Playing tetris with addresses had to be done with IPv4 but it's not even remotely a concern with IPv6 - the idea of waste and sizing networks is a chore that doesn't need to be thought about anymore. As you say, if you have a /64, you could run the entire internet with it, if you really wanted to do the kinds of hacks we've been doing with v4, but the idea is that you don't need to do any of that.

-Laszlo

...

On 28 December 2017 at 10:39, Owen DeLong <owen@delong.com> wrote:

...

...

On Dec 28, 2017, at 09:23 , Octavio Alvarez <octalnanog@alvarezp.org> wrote: On 12/20/2017 12:23 PM, Mike wrote:

...

On 12/17/2017 08:31 PM, Eric Kuhnke wrote: Call this the 'shavings', in IPv4 for example, when you assign a P2P link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, due to ping-pong and just so many technical manuals and other advices, you are told to "just use a /64' for your point to points. Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the exception would be if a router does not support it.

Best regards, Octavio. Best practice used most places is to assign a /64 and put a /127 on the interfaces.

Owen

Sigh… Let’s stop with the IPv4-think. Wasting 2^64 addresses was intentional because the original plan was for a 64-bit total address and the additional 64 bits was added to make universal 64-bit subnets a no-brainer. Owen

On Dec 28, 2017, at 09:55 , Michael Crapse <michael@wi-fiber.io> wrote:

Yes, let's talk about waste, Lets waste 2^64 addresses for a ptp. If that was ipv4 you could recreate the entire internet with that many addresses.

On 28 December 2017 at 10:39, Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote:

...

On Dec 28, 2017, at 09:23 , Octavio Alvarez <octalnanog@alvarezp.org <mailto:octalnanog@alvarezp.org>> wrote:

On 12/20/2017 12:23 PM, Mike wrote:

...

On 12/17/2017 08:31 PM, Eric Kuhnke wrote: Call this the 'shavings', in IPv4 for example, when you assign a P2P link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, due to ping-pong and just so many technical manuals and other advices, you are told to "just use a /64' for your point to points.

Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the exception would be if a router does not support it.

Best regards, Octavio.

Best practice used most places is to assign a /64 and put a /127 on the interfaces.

Owen

On Thu, 28 Dec 2017 16:35:08 -0500, Owen DeLong <owen@delong.com> wrote:

Wasting 2^64 addresses was intentional because the original plan was for a 64-bit total address and the additional 64 bits was added to make universal 64-bit subnets a no-brainer.

Incorrect. The original 128 address space was split 80+48. That *LATER* became 64+64 to support EUI-64 (vs. 48bit ethernet MACs) A 64bit LAN is, and always will be, an infinitely stupid idea. The reason for that over-optimization in SLAAC never materialized -- the 8bit micro-controlers from the 80s will never run IPv6, so the ability to form your address in 4 lines of ASM is meaningless, even more so when IPSec was bolted on. (later marked optional, but was originally required) SLAAC is still, to this day, THE. ONLY. THING. demanding your LANs be 64bits. I've run LANs with longer prefixes for decades. And they work. (the original intent was to keep android devices from using IPv6, as there's no f'ing way to turn it off, or even see it anywhere.) Yes, there are various RFCs saying you need to use /64's, but they're all bunk. SLAAC is the only thing that REQUIRES a /64, and few modifications to your IPv6 source and privacy extensions function just fine with longer prefixes. (don't go nuts and use /120's, unless you like seeing address collisions; DAD is designed to handle that -- and does, but it can take a few rounds to find a free address. I've used /96 on a LAN with ~100 machines without issue.) Back to the main theme... artificially cutting the address space in half, just makes the point even stronger. IPv6 address space is, in fact, half as big as people think it is, because we've drawn a line at /64 -- and the catastrophic part is people *ARE* wiring that into hardware. Every example I've seen people bat around about just how big 2^128 is, ignores the reality of Real World Networking(tm). They ignore infrastructure. The ignore route table size. They ignore the sparse nature of hierarchical address assignment. In the "10B people === 10B /48's" example, that's a dense PI allocation scheme that will lead to a global routing table approaching 10B routes -- you can't aggregate a random selection of /48s -- with zero consideration for how those 10B networks will interconnect. The simple truth is, we're doing the exact same thing with IPv6 that we did with IPv4: "The address space is so mind alteringly large we'll never use even a fraction of it." *pause* "Umm, wait a minute, we're carving this turkey up alarmingly fast." Will we use up the entire thing? Of course we will; it's not, in fact, *infinite*, so we *will* eventually assign all of it. It's going to happen a lot faster than most people think, as we're so cavalier with handing out vast amounts of space for which most people will never use more than (a) one LAN, and (b) a few dozen addresses within that single LAN. Will it happen in 5, 10, 100 years? The later is a safer bet. (not that I'll be around to collect) But just like IPv4, some decades down the road, people will see how stupid our allocation scheme really is, and begin a new "classless" era for IPv6. The short of it is, we got here first, so we don't have to give a shit about being efficient or frugal.

On 29 Dec 2017, at 11:24 am, Ricky Beam <jfbeam@gmail.com> wrote:

On Thu, 28 Dec 2017 16:35:08 -0500, Owen DeLong <owen@delong.com> wrote:

...

Wasting 2^64 addresses was intentional because the original plan was for a 64-bit total address and the additional 64 bits was added to make universal 64-bit subnets a no-brainer.

Incorrect. The original 128 address space was split 80+48. That *LATER* became 64+64 to support EUI-64 (vs. 48bit ethernet MACs)

A 64bit LAN is, and always will be, an infinitely stupid idea. The reason for that over-optimization in SLAAC never materialized -- the 8bit micro-controlers from the 80s will never run IPv6, so the ability to form your address in 4 lines of ASM is meaningless, even more so when IPSec was bolted on. (later marked optional, but was originally required)

SLAAC is still, to this day, THE. ONLY. THING. demanding your LANs be 64bits. I've run LANs with longer prefixes for decades. And they work. (the original intent was to keep android devices from using IPv6, as there's no f'ing way to turn it off, or even see it anywhere.) Yes, there are various RFCs saying you need to use /64's, but they're all bunk. SLAAC is the only thing that REQUIRES a /64, and few modifications to your IPv6 source and privacy extensions function just fine with longer prefixes. (don't go nuts and use /120's, unless you like seeing address collisions; DAD is designed to handle that -- and does, but it can take a few rounds to find a free address. I've used /96 on a LAN with ~100 machines without issue.)

Back to the main theme... artificially cutting the address space in half, just makes the point even stronger. IPv6 address space is, in fact, half as big as people think it is, because we've drawn a line at /64 -- and the catastrophic part is people *ARE* wiring that into hardware. Every example I've seen people bat around about just how big 2^128 is, ignores the reality of Real World Networking(tm). They ignore infrastructure. The ignore route table size. They ignore the sparse nature of hierarchical address assignment. In the "10B people === 10B /48's" example, that's a dense PI allocation scheme that will lead to a global routing table approaching 10B routes -- you can't aggregate a random selection of /48s -- with zero consideration for how those 10B networks will interconnect.

The simple truth is, we're doing the exact same thing with IPv6 that we did with IPv4: "The address space is so mind alteringly large we'll never use even a fraction of it." *pause* "Umm, wait a minute, we're carving this turkey up alarmingly fast." Will we use up the entire thing? Of course we will; it's not, in fact, *infinite*, so we *will* eventually assign all of it. It's going to happen a lot faster than most people think, as we're so cavalier with handing out vast amounts of space for which most people will never use more than (a) one LAN, and (b) a few dozen addresses within that single LAN. Will it happen in 5, 10, 100 years? The later is a safer bet. (not that I'll be around to collect) But just like IPv4, some decades down the road, people will see how stupid our allocation scheme really is, and begin a new "classless" era for IPv6. The short of it is, we got here first, so we don't have to give a shit about being efficient or frugal.

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

On Thu, 28 Dec 2017 21:05:33 -0500, Owen DeLong <owen@delong.com> wrote:

If you want to make that argument, that we shouldn’t have SLAAC and we should use /96 prefixes, that wouldn’t double the space, it would multiply it by roughly 4 billion.

I'm saying I should be able to use whatever size LAN I want.

The routing problem might be real if everyone goes to PI, but I think that’s an unlikely scenario.

Every scenario everyone has come up with is "unlikely". Home networks with multiple LANs??? Never going to happen; people don't know how to set them up, and there's little technical need for it.

Your definition of “amazingly fast is pretty odd... we’ve allocated tiny fractions of 2 /3 prefixes to special uses (multicast, ULA, loopback, unknown, etc.). Beyond that, there’s a /3 delegated to IANA as unicast space for distribution to the RIRs. Of that /3, IANA has delegated a little more than 5 /12s to RIRs. That’s the total of 20 years worth of turkey carving and constitutes well under 1/8th of the address space. Issued. By that measure, we’ve got well over 160 years to worry about runout.

After 20 years of not using IPv6, that's actually A LOT of carving. And if you look at what's been assigned vs. what's being announced vs. what's actually being used, there's a fantastic amount of waste. But nobody cares because there's plenty of space, and "we'll never use it all." (history says otherwise.)

On 29 Dec 2017, at 1:54 pm, Ricky Beam <jfbeam@gmail.com> wrote:

On Thu, 28 Dec 2017 21:05:33 -0500, Owen DeLong <owen@delong.com> wrote:

...

If you want to make that argument, that we shouldn’t have SLAAC and we should use /96 prefixes, that wouldn’t double the space, it would multiply it by roughly 4 billion.

I'm saying I should be able to use whatever size LAN I want.

Go ahead and do it. No one is stopping you. Just don’t force it on other including your customers.

...

The routing problem might be real if everyone goes to PI, but I think that’s an unlikely scenario.

Every scenario everyone has come up with is "unlikely". Home networks with multiple LANs??? Never going to happen; people don't know how to set them up, and there's little technical need for it.

It already happens and it isn’t just geeks that have such home networks. People do daisy chain routers today and have been for years. HOMENET routers will auto configure if you just plug them together.

...

Your definition of “amazingly fast is pretty odd... we’ve allocated tiny fractions of 2 /3 prefixes to special uses (multicast, ULA, loopback, unknown, etc.). Beyond that, there’s a /3 delegated to IANA as unicast space for distribution to the RIRs. Of that /3, IANA has delegated a little more than 5 /12s to RIRs. That’s the total of 20 years worth of turkey carving and constitutes well under 1/8th of the address space. Issued. By that measure, we’ve got well over 160 years to worry about runout.

After 20 years of not using IPv6, that's actually A LOT of carving. And if you look at what's been assigned vs. what's being announced vs. what's actually being used, there's a fantastic amount of waste. But nobody cares because there's plenty of space, and "we'll never use it all." (history says otherwise.)

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

I think its time you all had a bit of a holiday break and stopped thinking of IP networking for a little while, Just saying.......

-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Ricky Beam Sent: Thursday, December 28, 2017 9:55 PM To: Owen DeLong <owen@delong.com> Cc: NANOG list <nanog@nanog.org> Subject: Re: Waste will kill ipv6 too

Every scenario everyone has come up with is "unlikely". Home networks with multiple LANs??? Never going to happen; people don't know how to set them up, and there's little technical need for it.

I couldn't agree more. We're spending so much time with new RFCs to handle all these prefix delegation ways in order to accommodate 'power users' who are used to chaining one NATing IPv4 router off of another one and having it sort of work. If we'd just put a stake in the ground and say residences can have one router and bridge everything below that we'd be further ahead. I just can't see 99.999% of users being interested in subnetting their homes and writing firewall rules so their light bulbs can't talking to their DVRs. Chuck

On Thu, 28 Dec 2017 22:41:57 -0500, "Chuck Church" said:

If we'd just put a stake in the ground and say residences can have one router and bridge everything below that we'd be further ahead. I just can't see 99.999% of users being interested in subnetting their homes and writing firewall rules so their light bulbs can't talking to their DVRs.

So you'd rather write firewall rules so that people using your "guest" side of the *bridged* network stay out of the *other* side of the *bridged* network? (Hint: What does "bridged" mean for where packets go?) If you have the ability to set up multiple subnets, it's easy: Subnet 0 is wired local ports on the back of the router Subnet 1 is your local 2.4ghz wireless Subnet 2 is your local 5ghz Subnet 3 is your guest 2.4 Subnet 4 is your guest 5ghz. Subnets 0 1 and 2 can talk to each other, Subnets 3 and 4 can only talk to the outside world. Probably want a few more subnets for all the crapware that's shipping as part of the Internet of Pwned Things. Or you can try to do all this in one bridged subnet. Have fun with your nervous breakdown. :)

On Dec 28, 2017, at 7:50 PM, valdis.kletnieks@vt.edu wrote:

Comcast is passing out CPE that provides a subnet for the actual subscriber, and another one for *other* Comcast roaming customers. And somehow this works for a company the size of Comcast without the customers needing to know how to set them up.

This sounds like the Shaw "Wifi to Go" routers they (Shaw) push out. Agree to make your Shaw internet connection "shared" and they drop in a hotspot that provides a 2nd wifi network that subscribers can connect to. In exchange for a discount on your local internet bill. (Separate subnet.) Of course, Shaw STILL doesn't do IPv6 ... ;-P

Excuse the top post, but this seems to be an argument between people who understand big numbers and those who don't. IPv4 has 2^32 addresses, IPv6 has 2^128, which means 79 octillion people can each have their own internet. I think Owen is being modest when he says no one alive will be around for the exhaustion of IPv6, I think we're debating whether it will run out in a thousand years or a million. On 12/29/17, 10:44 AM, "NANOG on behalf of Owen DeLong" <nanog-bounces@nanog.org on behalf of owen@delong.com> wrote: > On Dec 28, 2017, at 18:54, Ricky Beam <jfbeam@gmail.com> wrote: > >> On Thu, 28 Dec 2017 21:05:33 -0500, Owen DeLong <owen@delong.com> wrote: >> If you want to make that argument, that we shouldn’t have SLAAC and we should use /96 prefixes, that wouldn’t double the space, it would multiply it by roughly 4 billion. > > I'm saying I should be able to use whatever size LAN I want. Sounds like you already are and nobody is telling you that you can’t. It’s a rather silly way to over-complicate your life, but if you want to be on the wrong side of a direcTV commercial, nobody’s trying to stop you. > >> The routing problem might be real if everyone goes to PI, but I think that’s an unlikely scenario. > > Every scenario everyone has come up with is "unlikely". Home networks with multiple LANs??? Never going to happen; people don't know how to set them up, and there's little technical need for it. Lots of home networks have multiple LANs today, so you’re patently wrong there already. > >> Your definition of “amazingly fast is pretty odd... we’ve allocated tiny fractions of 2 /3 prefixes to special uses (multicast, ULA, loopback, unknown, etc.). Beyond that, there’s a /3 delegated to IANA as unicast space for distribution to the RIRs. Of that /3, IANA has delegated a little more than 5 /12s to RIRs. That’s the total of 20 years worth of turkey carving and constitutes well under 1/8th of the address space. Issued. By that measure, we’ve got well over 160 years to worry about runout. > > After 20 years of not using IPv6, that's actually A LOT of carving. And if you look at what's been assigned vs. what's being announced vs. what's actually being used, there's a fantastic amount of waste. But nobody cares because there's plenty of space, and "we'll never use it all." (history says otherwise.) Given that more than 50% of US mobile traffic is now IPv6, I find it hard to give credence to a claim of “not using”. It’s also north of 40% for US fixed wire line traffic. As I said, I don’t doubt that we may eventually run out. However, I doubt anyone alive today will still be alive when we do. Owen

On 12/28/2017 11:39 AM, Owen DeLong wrote:

...

On Dec 28, 2017, at 09:23 , Octavio Alvarez <octalnanog@alvarezp.org> wrote:

On 12/20/2017 12:23 PM, Mike wrote:

...

On 12/17/2017 08:31 PM, Eric Kuhnke wrote: Call this the 'shavings', in IPv4 for example, when you assign a P2P link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, due to ping-pong and just so many technical manuals and other advices, you are told to "just use a /64' for your point to points.

Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the exception would be if a router does not support it.

Best practice used most places is to assign a /64 and put a /127 on the interfaces.

Thanks for the info. Is this documented somewhere? Is there a disadvantage in letting many P2P links use different /127 networks within the same /64? Best regards, Octavio.

On Dec 28, 2017, at 10:34 , JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:

This may be useful:

https://www.ripe.net/publications/docs/ripe-690/

Regards, Jordi

-----Mensaje original----- De: NANOG <nanog-bounces@nanog.org> en nombre de Octavio Alvarez <octalnanog@alvarezp.org> Responder a: <octalnanog@alvarezp.org> Fecha: jueves, 28 de diciembre de 2017, 19:31 Para: Owen DeLong <owen@delong.com> CC: <nanog@nanog.org> Asunto: Re: Assigning /64 but using /127 (was Re: Waste will kill ipv6 too)

On 12/28/2017 11:39 AM, Owen DeLong wrote:

...

...

On Dec 28, 2017, at 09:23 , Octavio Alvarez <octalnanog@alvarezp.org> wrote:

On 12/20/2017 12:23 PM, Mike wrote:

...

On 12/17/2017 08:31 PM, Eric Kuhnke wrote: Call this the 'shavings', in IPv4 for example, when you assign a P2P link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, due to ping-pong and just so many technical manuals and other advices, you are told to "just use a /64' for your point to points.

Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the exception would be if a router does not support it.

Best practice used most places is to assign a /64 and put a /127 on the interfaces.

Thanks for the info. Is this documented somewhere? Is there a disadvantage in letting many P2P links use different /127 networks within the same /64?

Primarily human factors. Owen

Best regards, Octavio.

********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Just an interjection but the problem with this "waste" issue often comes down to those who see 128 bits of address vs those who see 2^128 addresses. It's not like there were ever anything close to 4 billion (2^32) usable addresses with IPv4. We have entire /8s which are sparsely populated so even if they're 24M addrs that's of no use to everyone else. Plus other dedicated uses like multicast. So the problem is segmentation of that 128 bits which makes it look a lot scarier because 128 is easy to think about, policy-wise, while 2^128 isn't. My wild guess is if we'd just waited a little bit longer to formalize IPng we'd've more seriously considered variable length addressing with a byte indicating how many octets in the address even if only 2 lengths were immediately implemented (4 and 16.) And some scheme to store those addresses in the packet header, possibly IPv4 backwards compatible (I know, I know, but here we are!) And we'd've been all set, up to 256 bytes (2K bits) of address. If wishes were horses...but I think what I'm saying here will be said again and again. Too many people answering every concern with "do you have any idea how many addresses 2^N is?!?!" while drowning out "do you have any idea how small that N is? -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

On December 28, 2017 at 19:23 mel@beckman.org (Mel Beckman) wrote:

IPng was discussed to death and found not workable. The history is there for you to read. In the meantime, it's not helpful claiming IPng until you understand that background.

By "IPng" I only meant whatever would follow IPv4, IP next generation, not any specific proposal which may've called itself "ipng". But more importantly the difference between thinking in terms of 128 bits vs 2^128 addresses which seem to be conflated in these discussions, repeatedly. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

On December 28, 2017 at 19:47 mel@beckman.org (Mel Beckman) wrote:

the difference between thinking in terms of 128 bits vs 2^128 addresses which seem to be conflated in these discussions

I think you're wrong. Show me where anyone made a case in this thread at all for 2^128 addresses mitigating the problem. Everyone has been discussing structured assignments with 128 bits, and several people here have proven to a mathematical certainty that no technology here today nor on the horizon can exhaust this address space undertake the current allocation rules, *INCLUDING* using /64s for point-to-point circuit.

I think you just did with that paragraph, at least a little. Allocation rules change over time, or they are "abused" (for some value of "abused") typically via very sparsely populated block allocations. Is the ITU still lobbying for their own large block allocations for resale/redistribution? That is, to become in effect an RIR (albeit global not regional)? Or if not currently might they again? https://www.linx.net/public-affairs/itu-wants-to-control-ip-address-allocati... The article is a few years old but it's been in the air. But we shall know in the fullness of time. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

On Dec 28, 2017, at 11:14 , bzs@theworld.com wrote:

Just an interjection but the problem with this "waste" issue often comes down to those who see 128 bits of address vs those who see 2^128 addresses. It's not like there were ever anything close to 4 billion (2^32) usable addresses with IPv4.

Part of this is correct (the last sentence). There were closer to 3.2 billion usable IPv4 unicast addresses.

We have entire /8s which are sparsely populated so even if they're 24M addrs that's of no use to everyone else. Plus other dedicated uses like multicast.

Well, a /8 is actually only 16.7 million, not 24M, but I’m not sure that matters much to your argument.

So the problem is segmentation of that 128 bits which makes it look a lot scarier because 128 is easy to think about, policy-wise, while 2^128 isn’t.

Sure, but that’s intended in the design of IPv6. There’s really no need to think beyond 2^64 because the intent is that a /64 is a single subnet no matter how many or how few machines you want to put on it. Before anyone rolls out the argument about the waste of a /64 for a point to point link with two hosts on it, please consider that the relative difference in waste between a /64 with 10,000 hosts on it and a /64 with 2 hosts on it is less than the rounding error in claiming that a /64 is roughly 18 quintillion addresses. In fact, it’s orders of magnitude less.

My wild guess is if we'd just waited a little bit longer to formalize IPng we'd've more seriously considered variable length addressing with a byte indicating how many octets in the address even if only 2 lengths were immediately implemented (4 and 16.) And some scheme to store those addresses in the packet header, possibly IPv4 backwards compatible (I know, I know, but here we are!)

Unlikely. Variable length addressing in fast switching hardware is “difficult” at best. Further, if you only use an octet (which is what I presume you meant by byte) to set the length of the variable length address, you have a fixed maximum length address of somewhere between 255 and 256 inclusive unless you create other reserved values for that byte and depending on whether you interpret 0 to be 256 or invalid. I think that 256 octet addressing would be pretty unworkable in modern hardware, so you’d have to find some way of defining and then over time changing what the maximum allowed value in that field could be. Now you’ve got all kinds of tables and datastructures in all kinds of software that either need to pre-configure for the maximum size or somehow dynamically allocate memory on the fly for each session and possibly more frequently than that. You don’t have to dig very deep into the implementation details of variable length addressing to see that there’s still, even today, 20 years after the decision was made, it’s not a particularly useful answer.

And we'd've been all set, up to 256 bytes (2K bits) of address.

Not really. There’s a lot of implementation detail in there and I don’t think you’re going to handle 2Kbit addresses very well on a machine with 32K of RAM and 2MB of flash. (e.g. ESP8266 based devices and many other iOT platforms).

If wishes were horses...but I think what I'm saying here will be said again and again.

Not likely… At least not by anyone with credibility.

Too many people answering every concern with "do you have any idea how many addresses 2^N is?!?!" while drowning out "do you have any idea how small that N is?

We may, someday, wish we had gone to some value of N larger than 128, but I seriously doubt it will occur in my lifetime. Owen

On Dec 28, 2017, at 4:31 PM, Thomas Bellman <bellman@nsc.liu.se> wrote:

On 2017-12-28 22:31, Owen DeLong wrote:

...

Sure, but that’s intended in the design of IPv6. There’s really no need to think beyond 2^64 because the intent is that a /64 is a single subnet no matter how many or how few machines you want to put on it.

...

Before anyone rolls out the argument about the waste of a /64 for a point to point link with two hosts on it, please consider that the relative difference in waste between a /64 with 10,000 hosts on it and a /64 with 2 hosts on it is less than the rounding error in claiming that a /64 is roughly 18 quintillion addresses. In fact, it’s orders of magnitude less.

[...]

...

We may, someday, wish we had gone to some value of N larger than 128, but I seriously doubt it will occur in my lifetime.

My problem with the IPv6 addressing scheme is not the waste of 64 bits for the interface identifier, but the lack of bits for the subnet id. 16 bits (as you normally get a /48) is not much for a semi-large organi- zation, and will force many to have a dense address plan, handing out just one or a few subnets at a time, resulting in a patch-work of allocations. 24 bits for subnet id would be more usable.

There is no prohibition of requesting an allocation which matches your network. That is, simply request what is needed with suitable data for justification and get your /40 or whatever. So, you really have no problem with a default /48 site allocation, just with the fact you must do actual work to justify whatever request you make for a network with many sites, or large sites, or both. It should be obvious that this is actually less work than continually fiddling with “dense address plans”. This is why IPv6 should be less costly to deploy and maintain, using standard templates, than IPv4 ever dreamed of being. Please let it be so,

Consider e.g. a university or company campus. There are probably at least 16 departments, so I would like to use 8 bits as department id. Several departments are likely to have offices on more than one floor, or in more than one building, so I would like to let them have 4 bits to specify location, and then 8 bits to specify office/workplace within each location. And allow them to hand out 16 subnets per workplace. That adds up to 24 bits. So a /40 would be nice, not a /48.

Similarly, an ISP that wants a structured address plan, e.g. to encode prefecture, city and part of city in the address, will quickly use up bits in the customer id part of the address.

/Bellman

On 12/28/2017 03:44 PM, James R Cutler wrote:

There is no prohibition of requesting an allocation which matches your network. That is, simply request what is needed with suitable data for justification and get your /40 or whatever.

We are currently handing out /52s to customers. Based on a reasonable sparse allocation scheme that would account for future growth that seemed like the best option. I can't really see how /52 is too small for a residential customer. I know originally it was supposed to be /48 but after doing a bit of reading I think many people have admitted there is room for nuance. Do you think I could go to ARIN and say, well, we haven't used hardly any of this but based on such-and-such allocation scheme, it would be much better if you gave us a /32 instead of a /36? Also, does anyone know whether ARIN is using sparse allocation, such that if we go back later and ask for more they will just increase the size of our allocation starting from the same point? --Brock

the good thing about these long threads, which have ZERO new information, is having a KillThread command in one's mail user agent. get a life!

On Dec 28, 2017, at 3:28 PM, Brock Tice <brock@bmwl.co> wrote:

We are currently handing out /52s to customers. Based on a reasonable sparse allocation scheme that would account for future growth that seemed like the best option.

Could you detail the reasoning behind your allocation scheme? I.e., what are the assumptions you're making about customers deploying hardware? How will they need those devices isolated? What data fed the model you used to come up with those numbers? I ask because I have seen many ISPs advocate for smaller than /48 customer allocations, but I haven't seen anyone present the model they used to come up with those numbers. I really am curious to know the assumptions and rationale behind the various allocation schemes ISPs are coming up with.

I can't really see how /52 is too small for a residential customer. I know originally it was supposed to be /48 but after doing a bit of reading I think many people have admitted there is room for nuance.

What reading? Can you provide pointers to the documents you were reading? Again, I'm curious to understand how and why ISPs are making these decisions. Also, the fact that you "can't see it" doesn't mean they (or someone else) can't or won't. An ISP's job is to shovel packets around. No more, no less.

Do you think I could go to ARIN and say, well, we haven't used hardly any of this but based on such-and-such allocation scheme, it would be much better if you gave us a /32 instead of a /36?

Hardly used any of what? Are you talking about density of the customer hosts inside each of these /64 subnets? This is where I think the biggest misunderstandings of the IPv6 allocation strategy comes from. Ask yourself this: do you think the intention was to have 2^64 hosts on a single LAN segment? Can you imagine any practical switch fabric that could handle that? (I'd be curious to know the size of the largest - in the number of hosts sense - 10-Gig Ethernet LAN anyone has deployed.) The number of hosts per /64 will always be limited by the associated switch hardware. This will be true until the universe collapses, I suspect.

Also, does anyone know whether ARIN is using sparse allocation, such that if we go back later and ask for more they will just increase the size of our allocation starting from the same point?

You could just ask them. But the policies for ISP allocations (last time I read them) makes it pretty straight forward for you to get a block that fits your growth needs for the foreseeable future.† But really, if you are worried about having to advertise, say, eight IPv6 prefixes to the DFZ for all your allocations, haven't you just argued against the fragmented /52 allocations to your downstream customers? You need to treat IPv6 addresses as being 64 bits long. Those extra 64 bits on the right are just noise – ignore them. Instead, think about how we can carve up a 2^61 address space (based on the current /3 active global allocation pool) between 2^32 people (Earth's current population), each having 2^16 devices, needing their own network. That makes for a densely allocated /48 for each person on the planet. (Coincidence?) But when we get to the point of filling up that /3, we still have five more /3s to work with. Now think about scaling. If the population doubles, we're now down to four spare /3s. If that doubled population doubles the number of devices, we're down to two spare /3s. If the population doubles again, there will be no civilization left, let alone an Internet. Etc. So realistically, the current address space allocation policies can handle a doubling of the planet's population, with each person having a quarter of a million addressable nodes. Each node having its own /64 to address individual endpoints within whatever that 'node' represents. Just think, 2^64 port-443 HTTPS servers per "thing." Isn't this the utopia we've been seeking out? I'm pretty confident IPv6 as a protocol (and, really, IP as a networking concept) will be dead *long* before we run out of address space. Not because we run out the numbers of bits allocated to hosts, or subnets, or ports; but because the current topology of routed networks won't fit with what we want or need to do in the future. (My prediction is that everything will move to adhoc meshes, with no control planes at all. But that's completely out of scope for this discussion.) --lyndon † https://www.arin.net/resources/ipv6_planning.html states that ISP allocations for > /32 block sizes is based on a /48 per customer site allocation policy.

Hi Lyndon, thanks for taking the time to address my questions. Responses below. On 2017-12-28 17:57, Lyndon Nerenberg wrote:

...

On Dec 28, 2017, at 3:28 PM, Brock Tice <brock@bmwl.co> wrote: We are currently handing out /52s to customers. Based on a reasonable sparse allocation scheme that would account for future growth that seemed like the best option. Could you detail the reasoning behind your allocation scheme? I.e., what are the assumptions you're making about customers deploying hardware? How will they need those devices isolated? What data fed the model you used to come up with those numbers?

I am going to address a bunch of these together below.

I ask because I have seen many ISPs advocate for smaller than /48 customer allocations, but I haven't seen anyone present the model they used to come up with those numbers. I really am curious to know the assumptions and rationale behind the various allocation schemes ISPs are coming up with.

...

I can't really see how /52 is too small for a residential customer. I know originally it was supposed to be /48 but after doing a bit of reading I think many people have admitted there is room for nuance. What reading? Can you provide pointers to the documents you were reading? Again, I'm curious to understand how and why ISPs are making these decisions.

Also, the fact that you "can't see it" doesn't mean they (or someone else) can't or won't. An ISP's job is to shovel packets around. No more, no less.

I think with a little more nuance, an ISP's job is to manage resources properly in order to shovel packets around as well as possible. In this case, IP address space.

...

Do you think I could go to ARIN and say, well, we haven't used hardly any of this but based on such-and-such allocation scheme, it would be much better if you gave us a /32 instead of a /36? Hardly used any of what? Are you talking about density of the customer hosts inside each of these /64 subnets? This is where I think the biggest misunderstandings of the IPv6 allocation strategy comes from.

No, see below. I'm talking about the fact that we've got a sparse allocation scheme and even within that most of the subnets we've allocated for towers don't have towers attached to them. They certainly could in the next decade, though.

Ask yourself this: do you think the intention was to have 2^64 hosts on a single LAN segment?

No

...

Also, does anyone know whether ARIN is using sparse allocation, such that if we go back later and ask for more they will just increase the size of our allocation starting from the same point? You could just ask them. But the policies for ISP allocations (last time I read them) makes it pretty straight forward for you to get a block that fits your growth needs for the foreseeable future.†

But really, if you are worried about having to advertise, say, eight IPv6 prefixes to the DFZ for all your allocations, haven't you just argued against the fragmented /52 allocations to your downstream customers?

I'm just wondering if I'm likely to have to renumber just to go to a more generous allocation scheme. I guess better now than in 5 years if so.

You need to treat IPv6 addresses as being 64 bits long. Those extra 64 bits on the right are just noise – ignore them. Instead, think about how we can carve up a 2^61 address space (based on the current /3 active global allocation pool) between 2^32 people (Earth's current population), each having 2^16 devices, needing their own network. That makes for a densely allocated /48 for each person on the planet. (Coincidence?) But when we get to the point of filling up that /3, we still have five more /3s to work with.

OK addressing all of the rest of this here. I'm admittedly no expert on IPv6, I've been forced to learn it in a hurry. I did read most of "Migrating to IPv6" by Marc Blanchet and "IPv6 Address Planning" by Tom Coffeen. I believe I read quite a few things about deciding on subnet sizing there.

From those books I basically learned to think in /64s (generally one per router interface). I'm not very concerned with the number of hosts in a /64 for obvious reasons.

Most of our customers only have 2-5 devices. I know this is not the case in most of America but we are quite rural and for many people they've never had better than 1.5Mbps DSL until we install service at their location. Most of them have no idea what a subnet is. Let us say that over the next ten years they get quite savvy and decide to isolate their wireless clients, some public servers, their IoT devices, and their security cameras. We have given them a /52 which contains 4096 /64s. So, most likely, they will use one of those for their LAN and be done. In case they decide to make several VLANs or whatever they have used 4 /64s and they have 4092 left. Well, maybe, you say, they want to do something more hierarchical. Ok, they have 16 /56s they can split into 16 /60s and they can split those into 16 /64s. So now for my customers that have expanded to like 10 devices they can give them their own /56 each. I will again say I am indeed no expert, I am happy to get feedback. Is there some kind of allocation scheme where a residential user or even a small or medium business will have any chance of using 4096 /64s?

Now think about scaling. If the population doubles, we're now down to four spare /3s. If that doubled population doubles the number of devices, we're down to two spare /3s. If the population doubles again, there will be no civilization left, let alone an Internet. Etc. So realistically, the current address space allocation policies can handle a doubling of the planet's population, with each person having a quarter of a million addressable nodes. Each node having its own /64 to address individual endpoints within whatever that 'node' represents. Just think, 2^64 port-443 HTTPS servers per "thing." Isn't this the utopia we've been seeking out?

I'm pretty confident IPv6 as a protocol (and, really, IP as a networking concept) will be dead *long* before we run out of address space.

If the correct answer is just "ask for more space", which is the sense I'm getting, then I should probably just do that. I do really appreciate the feedback. --Brock

On Thu, 28 Dec 2017 20:26:46 -0700, Brock Tice said:

I will again say I am indeed no expert, I am happy to get feedback. Is there some kind of allocation scheme where a residential user or even a small or medium business will have any chance of using 4096 /64s?

They won't burn 4096 consecutive addresses. They'll do what you said - your gear supplies their head-end router a /52. That then starts handing out a half-dozen or so /64s for hardware interfaces, and hands a DHCP-PD /56 to the expansion router at the other end of the house, which then hands out a half-dozen /64s for subnets at that end, and *it* then hands a /60 PD to the garage and barn routers, so they can each set up a half-dozen /64s. So yeah, they need a /52, even though we've only burned through 2 or 3 dozen /64s. But this is the way it's *supposed* to work - note that careful choice of subnet numbers for the PD and local subnets means that even if other stuff shows up and starts asking for a PD, there will be plenty left for them to use.

On Fri, 29 Dec 2017 15:36:51 +1100, Mark Andrews said:

PD is designed so that a device (router) can request multiple PD requests upstream. The interior router just needs to make a upstream request on behalf of the downstream device and any prefixes it will be allocating itself.

OK, I obviously missed that part of the RFC, I was under the impression that a "middle" router would be carving out of its own PD, rather than relaying the downstream request upstream.

On Dec 28, 2017, at 15:28, Brock Tice <brock@bmwl.co> wrote:

...

On 12/28/2017 03:44 PM, James R Cutler wrote: There is no prohibition of requesting an allocation which matches your network. That is, simply request what is needed with suitable data for justification and get your /40 or whatever.

We are currently handing out /52s to customers. Based on a reasonable sparse allocation scheme that would account for future growth that seemed like the best option.

I can't really see how /52 is too small for a residential customer. I know originally it was supposed to be /48 but after doing a bit of reading I think many people have admitted there is room for nuance.

Do you think I could go to ARIN and say, well, we haven't used hardly any of this but based on such-and-such allocation scheme, it would be much better if you gave us a /32 instead of a /36?

Yes. In fact, having authored the policy that allows this, I know you can.

Also, does anyone know whether ARIN is using sparse allocation, such that if we go back later and ask for more they will just increase the size of our allocation starting from the same point?

Yes. They are. Likely you would have no trouble with this. Owen DeLong Member, ARIN AC Speaking only for myself

--Brock

On Thu, 28 Dec 2017 17:50:54 -0500, Lyndon Nerenberg <lyndon@orthanc.ca> wrote:

IPv6 prefixes are not databases. Coding this sort of thing into your address space is silly.

And a 2^64 LAN, or ptp link, isn't? People have been doing this for decades. They did it before NAT! NAT just made it that much easier. This practice, no matter how silly, is not going to die.

On Dec 28, 2017, at 14:31, Thomas Bellman <bellman@nsc.liu.se> wrote:

...

On 2017-12-28 22:31, Owen DeLong wrote:

Sure, but that’s intended in the design of IPv6. There’s really no need to think beyond 2^64 because the intent is that a /64 is a single subnet no matter how many or how few machines you want to put on it.

...

Before anyone rolls out the argument about the waste of a /64 for a point to point link with two hosts on it, please consider that the relative difference in waste between a /64 with 10,000 hosts on it and a /64 with 2 hosts on it is less than the rounding error in claiming that a /64 is roughly 18 quintillion addresses. In fact, it’s orders of magnitude less.

[...]

...

We may, someday, wish we had gone to some value of N larger than 128, but I seriously doubt it will occur in my lifetime.

My problem with the IPv6 addressing scheme is not the waste of 64 bits for the interface identifier, but the lack of bits for the subnet id. 16 bits (as you normally get a /48) is not much for a semi-large organi- zation, and will force many to have a dense address plan, handing out just one or a few subnets at a time, resulting in a patch-work of allocations. 24 bits for subnet id would be more usable.

That’s absurd. The intent is a /48 per end SITE. Not per organization. According to ARIN policies, the definition of an end site is a single building or structure or a single tenant within a multi-tenant building or structure. With nibble boundary round-up in policy, an organization with more than one site can get at least 16 /48s. Further, a university could (technically) get a /48 for every dorm room.

Consider e.g. a university or company campus. There are probably at least 16 departments, so I would like to use 8 bits as department id. Several departments are likely to have offices on more than one floor, or in more than one building, so I would like to let them have 4 bits to specify location, and then 8 bits to specify office/workplace within each location. And allow them to hand out 16 subnets per workplace. That adds up to 24 bits. So a /40 would be nice, not a /48.

A campus is, by definition multiple end sites.

Similarly, an ISP that wants a structured address plan, e.g. to encode prefecture, city and part of city in the address, will quickly use up bits in the customer id part of the address.

An ISP can qualify for up to a /12 in a single allocation. They get two levels of hierarchy at which they can aggregate and do a nibble-boundary round-up. As such, I’m not sure how many bits you want for that that you feel you can’t have. Remember, /32 is just the default no questions asked minimum v6 isp allocation. Not the maximum. I know of at least three isps that have /24s or more of ipv6 space.

/Bellman

Owen

...

My worry is when pieces of those /64s get allocated for some specific use or non-allocation. For example hey, ITU, here's half our /64s, it's only fair...and their allocations aren't generally available (e.g., only to national-level providers as is their mission.)

Why would anyone give the ITU such an allocation? Worst I could imagine would be giving them a /3 same as IANA, but more likely IANA would issue them /12s like any other RIR. Even with that, since that would relieve the RIRs of responsibility for national providers, I think it still works out ok.

So the problem isn't for someone who holds a /64 any more than people who are ok w/ whatever IPv4 space they currently hold.

It's how one manages to run out of new /64s to allocate, just as we have with, say, IPv4 /16s. If you have one or more /16s and that's enough space for your operation then not a problem. If you need a /16 (again IPv4) right now, that's likely a problem.

There’s quite a bit of difference between 65536 /16s and 18 quintillion /64s.

That's where 128 bits starts to feel smaller and 2^128 addresses a little superfluous if you can't get /bits.

Again, even you haven’t presented a credible scenario in which we deplete the /64 inventory at IANA, let alone the inventory IETF holds in reserve that hasn’t been released to IANA. (IANA Holds most of a /3 of which they have issued a little more than 5 of the 512 /12s it contains, IETF is holding all of 5 and most of another 2 /3 blocks that haven’t been designated yet as unicast).

...

...

My wild guess is if we'd just waited a little bit longer to formalize IPng we'd've more seriously considered variable length addressing with a byte indicating how many octets in the address even if only 2 lengths were immediately implemented (4 and 16.) And some scheme to store those addresses in the packet header, possibly IPv4 backwards compatible (I know, I know, but here we are!)

Unlikely. Variable length addressing in fast switching hardware is “difficult” at best. Further, if you only use an octet (which is what I presume you meant by byte) to set the length of the variable length address, you have a fixed maximum length address of somewhere between 255 and 256 inclusive unless you create other reserved values for that byte and depending on whether you interpret 0 to be 256 or invalid.

I was thinking 256 (255, 254 probably at most) octets of address, not bits.

One could effect sub-octet (e.g., 63 bits) addresses in other ways when needed, as we do now, inside a 128 bit (anything larger than 63) address field.

...

I think that 256 octet addressing would be pretty unworkable in modern hardware, so you’d have to find some way of defining and then over time changing what the maximum allowed value in that field could be.

Yes, it would be space to grow. For now we might say that a core router is only obliged to route 4 or 16 octets.

But if the day came when we needed 32 octets it wouldn't require a packet redesign, only throwing some "switch" that says ok we're now routing 4/16/32 octet addresses for example.

Probably a single router command or two on a capable router.

This reflects a gross misunderstanding of how fast switching hardware works today.

...

Now you’ve got all kinds of tables and datastructures in all kinds of software that either need to pre-configure for the maximum size or somehow dynamically allocate memory on the fly for each session and possibly more frequently than that.

That's life in the fast lane! What can I say, the other choice is we run out of address space. One would hope there would be some lead-in time to any expansion, probably years of warning that it's coming.

Well... I’m betting the first /3 lasts at least 50-100 years. If that’s true, the other 5+ should provide plenty of lead time for that so long as we get cracking once we exhaust the first /3.

Or we have to implement IPvN (N > 6) with new packet designs which is almost certainly even more painful.

Meh. Not necessarily. It would, for example, be nice to have a destination ASN field in the packet header or some other provision for locator/ID split.

At least that variable length field would be a warning that one day it might be larger than 16 octets and it won't take 20+ years next time.

That’s very optimistic to say the least.

...

You don’t have to dig very deep into the implementation details of variable length addressing to see that there’s still, even today, 20 years after the decision was made, it’s not a particularly useful answer.

It's only important if one tends to agree that the day may come in the foreseeable future when 16 octets is not sufficient.

Nope. If you make variable part of the spec, then you require responsible manufacturers to implement variable even if it’s unlikely that the variable will change within the life of the hardware.

One only gets choices not ideals: a) run out of address space? b) Redesign the packet format entirely? c) Use a variable length address which might well be sufficient for 100 years?

If we run out of ipv6 addresses in less than 100 years, I will be very surprised. Can you provide a credible scenario under which that happens?

Each would have their trade-offs.

...

...

And we'd've been all set, up to 256 bytes (2K bits) of address.

Not really. There’s a lot of implementation detail in there and I don’t think you’re going to handle 2Kbit addresses very well on a machine with 32K of RAM and 2MB of flash. (e.g. ESP8266 based devices and many other iOT platforms).

Today's smart phones are roughly as powerful as ~20 year old multi-million dollar supercomputers. No one thought that would happen either.

Not entirely true.

But as I said it comes down to choices. Running out of address space is not very attractive either as we have seen.

Meh... I think actually running out will be an improvement over where we are today. Owen

...

...

If wishes were horses...but I think what I'm saying here will be said again and again.

Not likely… At least not by anyone with credibility.

...

Too many people answering every concern with "do you have any idea how many addresses 2^N is?!?!" while drowning out "do you have any idea how small that N is?

We may, someday, wish we had gone to some value of N larger than 128, but I seriously doubt it will occur in my lifetime.

I'll hang onto that comment :-)

...

Owen

-- -Barry Shein

Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

IPv6 space is being wasted. We know that much. No one needs more than 8 bits for site-local global addresses in the upper 64 (2/3xxx:xxxx:xxxx:xxxx::/64) of the address. I'm about to propose the most harebrained idea NANOG has ever seen. I feel like supersites are getting more addresses than they really need. For this purpose, an address is an upper 56, not a full 128-bit address (that's a device address, for this purpose...) A supersite is an ISP, or some other autonomous system fragment. The current system I've seen, where Sprint's address group appears to literally be 2600:0::/29... Sure that anticipates future growth of Sprint's network, but it doesn't take into account the needs of other supersites. My proposal is that all addresses be assigned in groups of /48s or even /52s (xxxx:xxxx:xxxx:yy00:) for supersites that don't anticipate much growth, and that supersites should have to forfeit all upper 56 or something addresses they haven't had one routable device address on for over 6 months. On 28/12/2017 15:35, bzs@theworld.com wrote:

On December 28, 2017 at 13:31 owen@delong.com (Owen DeLong) wrote:

...

...

On Dec 28, 2017, at 11:14 , bzs@theworld.com wrote:

Just an interjection but the problem with this "waste" issue often comes down to those who see 128 bits of address vs those who see 2^128 addresses. It's not like there were ever anything close to 4 billion (2^32) usable addresses with IPv4.

Part of this is correct (the last sentence). There were closer to 3.2 billion usable IPv4 unicast addresses.

Maybe "usable" doesn't quite express the problem. If someone grabs a /8 and makes little use of it (as happened I believe several times) the issue wasn't only usable but available to anyone but the /8 holder.

Whatever, not sure where that goes other than noting that address space allocations are often sparsely utilized.

...

...

We have entire /8s which are sparsely populated so even if they're 24M addrs that's of no use to everyone else. Plus other dedicated uses like multicast.

Well, a /8 is actually only 16.7 million, not 24M, but I’m not sure that matters much to your argument.

Oops, right, 24 bits, 16M.

...

...

So the problem is segmentation of that 128 bits which makes it look a lot scarier because 128 is easy to think about, policy-wise, while 2^128 isn’t.

Sure, but that’s intended in the design of IPv6. There’s really no need to think beyond 2^64 because the intent is that a /64 is a single subnet no matter how many or how few machines you want to put on it.

Before anyone rolls out the argument about the waste of a /64 for a point to point link with two hosts on it, please consider that the relative difference in waste between a /64 with 10,000 hosts on it and a /64 with 2 hosts on it is less than the rounding error in claiming that a /64 is roughly 18 quintillion addresses. In fact, it’s orders of magnitude less.

My worry is when pieces of those /64s get allocated for some specific use or non-allocation. For example hey, ITU, here's half our /64s, it's only fair...and their allocations aren't generally available (e.g., only to national-level providers as is their mission.)

So the problem isn't for someone who holds a /64 any more than people who are ok w/ whatever IPv4 space they currently hold.

It's how one manages to run out of new /64s to allocate, just as we have with, say, IPv4 /16s. If you have one or more /16s and that's enough space for your operation then not a problem. If you need a /16 (again IPv4) right now, that's likely a problem.

That's where 128 bits starts to feel smaller and 2^128 addresses a little superfluous if you can't get /bits.

...

...

My wild guess is if we'd just waited a little bit longer to formalize IPng we'd've more seriously considered variable length addressing with a byte indicating how many octets in the address even if only 2 lengths were immediately implemented (4 and 16.) And some scheme to store those addresses in the packet header, possibly IPv4 backwards compatible (I know, I know, but here we are!)

Unlikely. Variable length addressing in fast switching hardware is “difficult” at best. Further, if you only use an octet (which is what I presume you meant by byte) to set the length of the variable length address, you have a fixed maximum length address of somewhere between 255 and 256 inclusive unless you create other reserved values for that byte and depending on whether you interpret 0 to be 256 or invalid.

I was thinking 256 (255, 254 probably at most) octets of address, not bits.

One could effect sub-octet (e.g., 63 bits) addresses in other ways when needed, as we do now, inside a 128 bit (anything larger than 63) address field.

...

I think that 256 octet addressing would be pretty unworkable in modern hardware, so you’d have to find some way of defining and then over time changing what the maximum allowed value in that field could be.

Yes, it would be space to grow. For now we might say that a core router is only obliged to route 4 or 16 octets.

But if the day came when we needed 32 octets it wouldn't require a packet redesign, only throwing some "switch" that says ok we're now routing 4/16/32 octet addresses for example.

Probably a single router command or two on a capable router.

...

Now you’ve got all kinds of tables and datastructures in all kinds of software that either need to pre-configure for the maximum size or somehow dynamically allocate memory on the fly for each session and possibly more frequently than that.

That's life in the fast lane! What can I say, the other choice is we run out of address space. One would hope there would be some lead-in time to any expansion, probably years of warning that it's coming.

Or we have to implement IPvN (N > 6) with new packet designs which is almost certainly even more painful.

At least that variable length field would be a warning that one day it might be larger than 16 octets and it won't take 20+ years next time.

...

You don’t have to dig very deep into the implementation details of variable length addressing to see that there’s still, even today, 20 years after the decision was made, it’s not a particularly useful answer.

It's only important if one tends to agree that the day may come in the foreseeable future when 16 octets is not sufficient.

One only gets choices not ideals: a) run out of address space? b) Redesign the packet format entirely? c) Use a variable length address which might well be sufficient for 100 years?

Each would have their trade-offs.

...

...

And we'd've been all set, up to 256 bytes (2K bits) of address.

Not really. There’s a lot of implementation detail in there and I don’t think you’re going to handle 2Kbit addresses very well on a machine with 32K of RAM and 2MB of flash. (e.g. ESP8266 based devices and many other iOT platforms).

Today's smart phones are roughly as powerful as ~20 year old multi-million dollar supercomputers. No one thought that would happen either.

But as I said it comes down to choices. Running out of address space is not very attractive either as we have seen.

...

...

If wishes were horses...but I think what I'm saying here will be said again and again.

Not likely… At least not by anyone with credibility.

...

Too many people answering every concern with "do you have any idea how many addresses 2^N is?!?!" while drowning out "do you have any idea how small that N is?

We may, someday, wish we had gone to some value of N larger than 128, but I seriously doubt it will occur in my lifetime.

I'll hang onto that comment :-)

...

Owen

...

My wild guess is if we'd just waited a little bit longer to formalize IPng we'd've more seriously considered variable length addressing with a byte indicating how many octets in the address even if only 2 lengths were immediately implemented (4 and 16.)

Actually, that got heaved over the side fairly early in the IPng discussion, because nobody who was building silicon last century wanted to deal with arbitrary-length addresses. The IPv4 header had source and destination addresses on 4-byte boundaries for good reasons which still held true when we did the IPv6 headers.

It's rather interesting how parsing of variable length addresses was thought to be way too complicated - while parsing of IPv6 extension header chains of unknown length was okay. Steinar Haug, Nethelp consulting, sthaug@nethelp.no

...

...

My wild guess is if we'd just waited a little bit longer to formalize IPng we'd've more seriously considered variable length addressing with a byte indicating how many octets in the address even if only 2 lengths were immediately implemented (4 and 16.) Actually, that got heaved over the side fairly early in the IPng discussion, because nobody who was building silicon last century wanted to deal with arbitrary-length addresses. The IPv4 header had source and destination addresses on 4-byte boundaries for good reasons which still held true when we did the IPv6 headers.

It's rather interesting how parsing of variable length addresses was thought to be way too complicated - while parsing of IPv6 extension header chains of unknown length was okay.

variable length addressing was thrown out at the time because the OSI model showed that it created a good deal of trouble for no overriding benefit. Processing variable length addresses was found to be as difficult as processing the longest length allowed. In practice, NSAP addresses were limited to 20 octets, but in theory they could be up to 255. IPv6 extension headers, on the other hand, weren't considered a major imposition at the time because almost all routers in the mid 1990s were cpu switched rather than handled on asics. Walking through TLVs is relatively straightforward to handle from an algorithmic point of view, but it creates pain when dealing with forwarding lookup engines because extension headers means inspecting more header data when calculating the next-hop when you're dealing with ECMP / LAGs. This is harder when dealing with hardware/offloaded lookup engines because more header information needs to be copied from the interface to the lookup engine, which has a cost. It's not insurmountable, just more expensive from a hardware point of view, which means that lots of cheaper kit doesn't do this well, or in some cases, at all. Nick

Owen DeLong wrote:

fast routers mostly don’t parse those chains.

...unless they need to access the L4 header information in order to create useful hashes to load balance over LAG or ECMP bundles, or implement any sort of filtering, or RE / control plane policing. But outside these corner cases, definitely a minority requirement :-) Nick

Matt Hoppes <mattlists@rivervalleyinternet.net> writes:

Had a previous employee or I discovered it on the network segment after we had some weird routing issues and had to get that cleaned up. I don't know why anyone would do that when there is tons of private IP space.

Excuse 1: "We'll never connect to the internet!" Excuse 2: "It's only temporary!" Excuse 3: Typo (At some customers customer I found 192.!168 address which where apparently a typo but in use for years so nobody wanted to change it.) I also know one company who is using (has used?) 2001:8db::/48. I suggested to get v6 PI an properly implement IPv6 but never heard from them again. Excuse 4: "We used the addresses from out training material." - I heard this story some time ago: A large German government agency wanted to implement IP(v4) and the people attended a course about this new TCP/IP stuff at $Vendor. The training material was prepared by a student who was using his university's /16 as an example. BTW: Is the Cisco WLC 1.1.1.1 as default address for DHCP? Jens -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@quux.de | --------------- | ----------------------------------------------------------------------------

On 17 December 2017 at 17:48, Tom Carter <m1enrage@gmail.com> wrote:

RFC1918 isn't big enough to cover all use cases. Think about a large internet service providers. If you have ten million customers, 10.0.0.0/8 would be enough to number modems, but what happens when you need to number video set top boxes and voice end points? I don't think anyone goes out and says "Lets go use someone else's space, because I don't want to use this perfectly good private space".

:cough: They could use IPv6. I mean, if the mobile phone companies can figure it out, surely an ISP can... -- Harald

I’m pretty sure Comcast, along with most other MSOs in NA, use squat space for various endpoints because they have run out of public and private IPv4 space. Everyone obviously wants to get to all IPv6 but there are millions of end devices and other gear they speak to which do not support it. For the most part I think they try to re-use space and use the transition space when they can, but some deployed squat space before that came about or it’s simply not enough. Phil On 12/18/17, 3:36 PM, "NANOG on behalf of Mark Andrews" <nanog-bounces@nanog.org on behalf of marka@isc.org> wrote: Companies like COMCAST did. They manage the modems over IPv6. They also supported DS-Lite’s development as a transition mechanism so they wouldn’t have to run IPv4 to their customers. They wanted to be able to go IPv6 only. That meant having IPv4 as a service available. -- Mark Andrews > On 19 Dec 2017, at 06:34, Harald Koch <chk@pobox.com> wrote: > >> On 17 December 2017 at 17:48, Tom Carter <m1enrage@gmail.com> wrote: >> >> RFC1918 isn't big enough to cover all use cases. Think about a large >> internet service providers. If you have ten million customers, 10.0.0.0/8 >> would be enough to number modems, but what happens when you need to number >> video set top boxes and voice end points? I don't think anyone goes out and >> says "Lets go use someone else's space, because I don't want to use this >> perfectly good private space". >> > > :cough: > > They could use IPv6. I mean, if the mobile phone companies can figure it > out, surely an ISP can... > > -- > Harald

On Dec 19, 2017, at 07:39 , Livingood, Jason <Jason_Livingood@comcast.com> wrote:

On 12/18/17, 2:36 PM, "NANOG on behalf of Harald Koch" <nanog-bounces@nanog.org on behalf of chk@pobox.com> wrote:

...

They could use IPv6. I mean, if the mobile phone companies can figure it out, surely an ISP can...

Except for cases when it is impossible or impractical to update software on a great number of legacy devices…

JL

Yeah, in those cases, they should use IPv6 + NAT64 or similar mechanism. Owen

Agreed. There now. We need cheap, open source, options for widespread adoption. Oliver On Dec 20, 2017 12:51, "Michael Crapse" <michael@wi-fiber.io> wrote:

+1 for Nat64. dual stack is just keeping ipv4 around longer than it needs to be

On 19 December 2017 at 18:50, Owen DeLong <owen@delong.com> wrote:

...

...

On Dec 19, 2017, at 07:39 , Livingood, Jason < Jason_Livingood@comcast.com> wrote:

On 12/18/17, 2:36 PM, "NANOG on behalf of Harald Koch" < nanog-bounces@nanog.org on behalf of chk@pobox.com> wrote:

...

They could use IPv6. I mean, if the mobile phone companies can figure it out, surely an ISP can...

Except for cases when it is impossible or impractical to update

software

...

on a great number of legacy devices…

...

JL

Yeah, in those cases, they should use IPv6 + NAT64 or similar mechanism.

Owen

Excellent, thanks! Will dig into it. Oliver On Wed, Dec 20, 2017 at 4:17 PM, Ca By <cb.list6@gmail.com> wrote:

On Wed, Dec 20, 2017 at 1:01 PM Oliver O'Boyle <oliver.oboyle@gmail.com> wrote:

...

Agreed. There now. We need cheap, open source, options for widespread adoption.

http://jool.mx/en/index.html

Free open source nat64

...

Oliver

On Dec 20, 2017 12:51, "Michael Crapse" <michael@wi-fiber.io> wrote:

...

+1 for Nat64. dual stack is just keeping ipv4 around longer than it needs to be

On 19 December 2017 at 18:50, Owen DeLong <owen@delong.com> wrote:

...

...

On Dec 19, 2017, at 07:39 , Livingood, Jason < Jason_Livingood@comcast.com> wrote:

On 12/18/17, 2:36 PM, "NANOG on behalf of Harald Koch" < nanog-bounces@nanog.org on behalf of chk@pobox.com> wrote:

...

They could use IPv6. I mean, if the mobile phone companies can

figure

...

it out, surely an ISP can...

...

Except for cases when it is impossible or impractical to update

software on a great number of legacy devices…

...

JL

Yeah, in those cases, they should use IPv6 + NAT64 or similar mechanism.

Owen

-- :o@>

As someone who has written a DNS64 implementation - DO NOT USE DNS64. DNS64 breaks stuff. Use MAP-T. For those of you using DNS64 on the cellar side MAP-T can use the NAT64 you already have. Mark

On 21 Dec 2017, at 9:33 am, Jens Link <lists@quux.de> wrote:

Ca By <cb.list6@gmail.com> writes:

...

http://jool.mx/en/index.html

Free open source nat64

And the DNS64 part can be done with powerdns (recursor), unbound, bind, ... All OpenSource

Jens -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@quux.de | --------------- | ----------------------------------------------------------------------------

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

DNS64 “works” if you ignore what it breaks. MAP-T does NAT46 to the NAT64 and doesn’t have the side effects of DNS64. Why people insist that DNS64 is a “good" way to direct traffic to the NAT 64 I don’t understand. MAP-T directs the traffic to the NAT64 without the side effects. DNS64 was only ever a stop gap mechanism with lots of know side effects. Mark

On 21 Dec 2017, at 10:01 am, Ca By <cb.list6@gmail.com> wrote:

On Wed, Dec 20, 2017 at 5:54 PM Mark Andrews <marka@isc.org> wrote: As someone who has written a DNS64 implementation - DO NOT USE DNS64. DNS64 breaks stuff.

Use MAP-T. For those of you using DNS64 on the cellar side MAP-T can use the NAT64 you already have.

Mark

That’s just your opinion, man. Works for me and my 70 million customers.

Anything that is broken by DNS64 can be properly fixed by eliminating the need for it — by deploying ipv6. DNS64 only appears when the far end resource is single stacked (!)

We won’t be held hostage by folks who refuse to deploy ipv6, those days are over

Happy holidays!

...

On 21 Dec 2017, at 9:33 am, Jens Link <lists@quux.de> wrote:

Ca By <cb.list6@gmail.com> writes:

...

http://jool.mx/en/index.html

Free open source nat64

And the DNS64 part can be done with powerdns (recursor), unbound, bind, ... All OpenSource

Jens -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@quux.de | --------------- | ----------------------------------------------------------------------------

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

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

On 20 Dec 2017, at 2:39 am, Livingood, Jason <Jason_Livingood@comcast.com> wrote:

On 12/18/17, 2:36 PM, "NANOG on behalf of Harald Koch" <nanog-bounces@nanog.org on behalf of chk@pobox.com> wrote:

...

They could use IPv6. I mean, if the mobile phone companies can figure it out, surely an ISP can...

Except for cases when it is impossible or impractical to update software on a great number of legacy devices…

JL

You mean devices where the manufacture ignore IPv6 and shipped you a dud. Even devices with a 15 year life cycle should be IPv6 capable today. Microsoft shipped IPv6 capable versions of Windows in 2001. If they could see the writing on the wall back then *every* other device manufacture should have also been able to see this. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Hi, I know of some enterprise IT equipment that does this. It was reserved space at the time it was picked. It does not leak from the box, but every once in a while one of these IPs show up in a customer visible log, and causes confusion. In ways it is better then rfc 1918 space as it has less chance of conflicting with a management network. Harry On December 17, 2017 3:42:48 PM MST, Richard <rgolodner@infratection.com> wrote:

...

Will anyone comment on the practice of large enterprises using non RFC1918 IP space that other entities are assigned by ARIN for internal routing?

Just curious as to how wide spread this might be. I just heard of

On 12/17/2017 04:30 PM, Robert Webb wrote: this happening with a large ISP and never really thought about it until now.

...

Robert

    It is more common than you would think. Why use public IP's when you can have many rfc1918 options. Always amazes me after the initial confusion.     Richard

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

I worked alongside a company that used addresses assigned to the Syrian govt for their "guest" network. They were a pretty large org, presumably this was done to reduce risk - firewall rules, accidentally leaking guest prefixes to their internal nets, or just straight-up simplicity. They were in a pretty heavily regulated industry with restrictions on what companies they could do business with, so there probably wasn't a huge risk of reachability issues. On Sunday, December 17, 2017, joel jaeggli <joelja@bogus.com> wrote:

On 12/17/17 14:30, Robert Webb wrote:

...

Will anyone comment on the practice of large enterprises using non RFC1918 IP space that other entities are assigned by ARIN for internal routing?

Just curious as to how wide spread this might be. I just heard of this happening with a large ISP and never really thought about it until now. every time I seen a traceroute with 11/8 22/8 26/8 in it I am duly impressed. Robert

On 18 Dec 2017, at 1:20 pm, Robert Webb <rwebb@ropeguru.com> wrote:

Apologies for not responding sooner.

This came to light with me on a forum where someone posted that they thought it strange that their MTA received an IP that is assigned to the DoD DNIC.

Where I work I have the opposite issue. They have a lot of public IPv4 space and only use it internally never be advertised to the internet. Something I have never agreed With doing.

Robert

Why? This is a perfectly legitimate use of the IP addresses. The purpose of assigning addresses is so that they are unique WORLD WIDE in whatever context you wish to use them in. Mark

-----Original Message----- From: Richard Porter [mailto:richard@pedantictheory.com] Sent: Sunday, December 17, 2017 8:25 PM To: Robert Webb <rwebb@ropeguru.com> Cc: nanog@nanog.org Subject: Re: Companies using public IP space owned by others for internal routing

Robert, I’ve heard of two cases recently, large companies (non carrier/ISP). One company looking to solve challenge with IPv6 and 6to4 and DNS.

Also curious how wide-spread this is? Maybe just the kick in the butt for catching the elusive IPv6 unicorn?

~Richard

...

On Dec 17, 2017, at 3:30 PM, Robert Webb <rwebb@ropeguru.com> wrote:

Will anyone comment on the practice of large enterprises using non RFC1918 IP space that other entities are assigned by ARIN for internal routing?

Just curious as to how wide spread this might be. I just heard of this happening with a large ISP and never really thought about it until now.

Robert

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

On Sun, Dec 17, 2017 at 8:49 PM, Robert Webb <rwebb@ropeguru.com> wrote:

...

From: Mark Andrews [mailto:marka@isc.org]

...

On 18 Dec 2017, at 1:20 pm, Robert Webb <rwebb@ropeguru.com> wrote:

Where I work I have the opposite issue. They have a lot of public IPv4 space and only use it internally never be advertised to the internet. Something I have never agreed With doing.

Why? This is a perfectly legitimate use of the IP addresses. The purpose of assigning addresses is so that they are unique WORLD WIDE in whatever context you wish to use them in.

I going to guess you were talking about the use internally of public IP addresses..

But there are rules governing what to use where. So it is OK to hoard publicly addressable IPv4 IP's for internal use that will never reach the outside world? No the way I have been taught.

Maybe I just lack that big picture..

I think the big picture here is that they helped fund the development of IP and received large enough v4 allocations at the outset that they haven't had to use kludges like RFC1918 as much as most others have. It's not "hoarding" IPs if you're using them, whether or not you choose to advertise and make them accessible to other networks. It's the world everyone gets to live in with the current version of IP. Scott

On Mon, Dec 18, 2017 at 4:09 PM, Scott Morizot <tmorizot@gmail.com> wrote:

I think the big picture here is that they helped fund the development of IP and received large enough v4 allocations at the outset that they haven't had to use kludges like RFC1918

Um, sorry but as an old timer and a former employee of the company that owned 10/8 and returned it back to the address pool...who is it you are claiming "helped fund the development of IP?" -- Fletcher Kittredge GWI 207-602-1134 www.gwi.net