Re: A crazy idea

[Owen DeLong via NANOG <nanog () nanog org>]

> On Jul 19, 2021, at 06:04 , Stephen Satchell <list () satchell net> wrote:
>
> On 7/19/21 5:41 AM, Feldman, Mark wrote:
> > What you propose is not outlandish; some ISPs have been dual stack
> > and providing some combination of these services for years.  They
> > already provide IPv6 ip6.arpa delegations should their business
> > customers want them.  Some even provide at least a /56 so customers
> > can have multiple /64 subnets.  And we, I mean they, can also provide
> > RFC2317 in-addr.arpa delegations for those smaller IPv4 blocks.
>
> The part that is missing isn't the "some ISPs", it's "all ISPs".  Also, I don't know of any DNS service provider that 
> offers a product to handle delegations from the IN-ADDR.ARPA and IP6.ARPA trees.

I believe he.net does.

https://dns.he.net

To the best of my knowledge, so does Cloudflare.

Finally, it’s really not rocket science to stand up an authoritative server these days.

> I'm focusing on the SOHO customer market with my proposal.
>
> The allocation of IPv6 space with prefixes shorter than /64 is indeed a consideration for bigger administrative 
> domains like country governments, but on the other end, SOHO customers would be happy with /96, /104 or even /112 
> allocations if they could get them.  (Just how many light bulbs, fridges, toasters, doorbells, phones, &c does SOHOs 
> have?)  I would *not* like to see "us" make the same mistake with IPv6 that was made with IPv4, handing out large 
> blocks of space like so many pieces of M&M or Skittles candy.

SOHO customers should be getting PD for /48s too. The most egregiously backward providers that I know of are still 
issuing at least /60. It’s utterly and completely illogical to issue anything longer than /64 and reflects fundamental 
misunderstanding of the design and intended deployment of IPv6. Yes, you can technically do it, but it remains a really 
bad idea.

The point in IPv6 is to stop worrying about host counts. Let’s talk about your Candy analogy for a moment.

If you took every almond M&M ever manufactured, you probably couldn’t fill the great lakes.

If you converted every IPv6 /64 prefix in the entire ::/0 to almond M&Ms, you would, in fact, fill the great lakes.

And that’s the number of /64 sized subnets. You don’t have to count hosts because with a /64 subnet, you run out of 
table space in your devices well before you run out of host numbers.

There are enough /48s to give 1,000 to every single person on the planet today and still have 4,000 per person left 
over in the first /3 (Technically, there are more than 5026 IPv6 /48s in 2000::/3 for each person currently living).

We’re simply NOT going to run out of /48s by issuing them to SOHO users, no matter how hard we try.

Consider this… I discussed this topic at length with JJB (COMCAST at the time) and pushed hard on why they don’t give 
/48s to their residential customers. His answer was that if they did so, they would need to get a /12 from their RIR 
(ARIN). My question to him in response to that was “so?”.

COMCAST is one of the largest providers in North America and serves more than 31 million subscribers. There are maybe 
50 residential ISPs of this size worldwide. Giving each of them a /12 would leave us with a remaining 462 /12s in 
2000:/3.

Even if I’m absolutely wrong about all of this, consider that if we use a profligate allocation policy in the beginning 
of IPv6 to speed and simplify deployment and maintenance and we do run out of 2000::/3, then we can implement a more 
restrictive set of policies for the next 6 tries and still have a safety net when we’re forced to start allocating out 
of blocks with odd reservations (::/3 and e000::/3).

Fear of the “IPv4” mistake is utter nonsense. The error in IPv4 wasn’t issuing large blocks. The error in IPv4 was 
making the integer too few bits.

Owen