> On Jul 19, 2021, at 06:04 , Stephen Satchell <l...@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
