Re: A crazy idea

[james.cut...@consultant.com]

Thank you, Tim.

I have often suggested that clear business purposes should drive implementation 
of technology. Every cogent analysis of IPv6 shows that there are enough 
addresses that we need not worry about running out of addresses for many 
decades. Even swarms of devices should not seriously impact global IPv6 usage 
as they will have their own collision domain (/64, I presume). Norbert Weiner’s 
book Science and Cyphernetics (The Human Use of Human Beings) suggests than one 
should optimize human productivity and let the technology handle the grunt 
work. The human cost of micro-managing IPv6 assignments would be obscenely 
prohibitive. 

In well over 15 years on this topic, I have yet to find a reason for making 
every customer encounter and configuration more complicated than as described 
by Tim. It just does not make economic sense.
-
James R. Cutler 
Top posted because Apple keeps changing Mail and I am Lazy an engineer at heart.
james.cut...@consultant.com 

> On Jul 19, 2021, at 11:12 AM, t...@pelican.org wrote:
> 
> On Monday, 19 July, 2021 14:04, "Stephen Satchell"  said:
> 
>> 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,  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 or Skittles candy.
> 
> Nay, nay, and thrice nay.  Don't think in terms of addresses for IPv6, think 
> in terms of subnets.  I can't stress this enough, it's the big v4 to v6 
> paradigm shift - don't think about "how many hosts on this net", think about 
> "how many nets".
> 
> It's potentially useful for SOHO users to have multiple subnets, particularly 
> as they stick multiple devices in their home network that try to do PD from 
> the upstream for each downstream function.  /56 for every SOHO is a 
> fire-and-forget, you don't have to dick about with right-sizing anything, you 
> don't have to evaluate requirements with the customer, you don't have to do 
> all kinds of management system stuff to track who has what size, and it gives 
> you some room for a couple of levels of hierarchy within the house.
> 
> Make all of the subnets /64s, and SLAAC etc Just Work too.
> 
> Wikipedia suggests a little short of 200M households in the US.  That's 28 
> bits of space to give a /56 to every household.  Let's assume ISPs are really 
> bad at aggregation, so those bits are spread across multiple PoPs, multiple 
> ISPs, etc, and we take 36 bits of space to actually allocate those.  (That's 
> only in /56 in every 256 used, *lots* of room for sparse PoPs, sparse ISPs, 
> etc).  Shift back 36 bits from a /56, we've used a /20 to number the entire 
> US.
> 
> Same again for India.  3 of those for China.  It's all smaller from there for 
> the rest of the world.  Maybe 100 or so /20s to number the entire world on 
> the same plan.  There are a million /20s in the IPv6 address space.
> 
> We've got room to be sensible about assignments without repeating the IPv4 
> scarcity problem.
> 
> Cheers,
> Tim.
> 
> 

Re: A crazy idea

[Joe Maimon]

Owen DeLong wrote:



On Jul 29, 2021, at 14:06 , Joe Maimon  wrote:



t...@pelican.org wrote:

On Monday, 19 July, 2021 14:04, "Stephen Satchell"  said:


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,  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 or Skittles candy.

Nay, nay, and thrice nay.  Don't think in terms of addresses for IPv6, think in terms of subnets.  
I can't stress this enough, it's the big v4 to v6 paradigm shift - don't think about "how many 
hosts on this net", think about "how many nets".

Think of how many large ISP's a /3 of ipv6 effectively holds, assuming that /48 
per customer is the norm, and /24 up to /12 assignments for those ISP's is also.

In those terms IPv6 isnt that much bigger.


Let’s say an average “large” ISP burns a /11 of IPv4 serving their ~2M 
customers with a single IPv4 address each.
IPv4 supports a maximum of 2,048 such ISPs without regard to space for 
multicast, class E, etc. (which reduce this number).

Let’s say that we give each of them enough space to issue 16M /48s (an IPv6 
/24).

That means we have 2^21 IPv6 large ISPs serving 8x as many customers with /48s.

That’s 2 million large ISPs covered in the first /3.

Since each of them is serving around 2M customers, that’s 4,000,000,000,000 
customers.
For comparison, the world population is less than8,000,000,000.

Tell me again how IPv6 is not that much larger, Joe?

Owen


I will simply point out that even by this measurement, we have reduced 
IPv6 scarcity-free longevity from mind boggingly larger into only a 2-3 
thousand times larger. Thats enough of an accomplishment that I dont 
even have to delve into the discussions and proposals, some you were 
even a part of that could have resulted in even larger allocations to 
mega ISP's being acceptable, and still might.


Continuing to operate under the belief that there isnt any way we can 
use ipv6 that can result in some form of scarcity may very well cause 
that scarcity to become a serious possibility much sooner than might 
have ever been expected, with much larger and entrenched consequences 
than we can predict today.


So lets stop saying IPv6 is infinite. We can cede enough bits to cause 
scarcity to an upcoming generation who wont thank us.


I propose that any way we decide to use IPv6 today we should be able to 
say confidently will continue to operate under any imaginable scenarios 
for the next century, minimally.


Thats a conservative number considering that it would have been nice had 
they done a quarter of that for IPv4 back when it was where ipv6 is now.


Joe

Re: A crazy idea

[Owen DeLong via NANOG]

> On Jul 29, 2021, at 14:14 , Daniel Corbe  wrote:
> 
> 
> 
>> On Jul 29, 2021, at 16:06, Joe Maimon  wrote:
>> 
>> 
>> 
>> t...@pelican.org wrote:
>>> On Monday, 19 July, 2021 14:04, "Stephen Satchell"  said:
>>> 
 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,  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 or Skittles candy.
>>> Nay, nay, and thrice nay.  Don't think in terms of addresses for IPv6, 
>>> think in terms of subnets.  I can't stress this enough, it's the big v4 to 
>>> v6 paradigm shift - don't think about "how many hosts on this net", think 
>>> about "how many nets".
>> 
>> Think of how many large ISP's a /3 of ipv6 effectively holds, assuming that 
>> /48 per customer is the norm, and /24 up to /12 assignments for those ISP's 
>> is also.
>> 
>> In those terms IPv6 isnt that much bigger.
> 
> I haven’t seen evidence that any RIR has allocated an entire /12 to an ISP.  
> Even a large one.  

I haven’t seen any evidence that an ISP has requested a /12 from an RIR. How 
would an RIR issue a block that hasn’t been requested?

Owen

Re: A crazy idea

[Owen DeLong via NANOG]

> On Jul 29, 2021, at 14:06 , Joe Maimon  wrote:
> 
> 
> 
> t...@pelican.org wrote:
>> On Monday, 19 July, 2021 14:04, "Stephen Satchell"  said:
>> 
>>> 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,  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 or Skittles candy.
>> Nay, nay, and thrice nay.  Don't think in terms of addresses for IPv6, think 
>> in terms of subnets.  I can't stress this enough, it's the big v4 to v6 
>> paradigm shift - don't think about "how many hosts on this net", think about 
>> "how many nets".
> 
> Think of how many large ISP's a /3 of ipv6 effectively holds, assuming that 
> /48 per customer is the norm, and /24 up to /12 assignments for those ISP's 
> is also.
> 
> In those terms IPv6 isnt that much bigger.


Let’s say an average “large” ISP burns a /11 of IPv4 serving their ~2M 
customers with a single IPv4 address each.
IPv4 supports a maximum of 2,048 such ISPs without regard to space for 
multicast, class E, etc. (which reduce this number).

Let’s say that we give each of them enough space to issue 16M /48s (an IPv6 
/24).

That means we have 2^21 IPv6 large ISPs serving 8x as many customers with /48s.

That’s 2 million large ISPs covered in the first /3.

Since each of them is serving around 2M customers, that’s 4,000,000,000,000 
customers.
For comparison, the world population is less than8,000,000,000.

Tell me again how IPv6 is not that much larger, Joe?

Owen

Re: A crazy idea

[Owen DeLong via NANOG]

> On Jul 29, 2021, at 22:23, Frank Habicht  wrote:
> 
> Hi,
> 
> On 30/07/2021 07:58, Owen DeLong via NANOG wrote:> ...
>> 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?”.
> 
> 
> I recently got this "so?" question asked [1] and I believe I follow you
> and see the point.
> 
> My response was along the line:
> - today (at least here in AfriNIC-land - sorry to get out of "NA")
>  the RIR charges membership fee depending on size of IPv4 allocations.
> - Will the RIR charge membership fee depending on IPv6 allocation size
>  in 5 years from now?
> 

I believe all RIRs charge by size for LIRs in some form or other. ARIN is by 
max_fee(IPv4,IPv6). 

In the case in question (COMCAST), they are already in the maximum fee 
category, so expanding their v6 allocation to /12 would not increase their 
fees. 

I would argue that since (at least in ARIN), you get 16x as much address space 
for 2x the fee, revenues from the expanded customer base should easily dwarf 
the cost of additional addresses to issue proper /48s to every customer. 

> And it's a genuine question.
> Does anyone know what the intentions or likelihood of options are?

I think COMCAST intends to continue subjugating their customers with limited 
address blocks for the foreseeable future. 

I am hoping that other IPSs will be more rational and eventually market 
pressure will bring about ubiquitous /48s. 

Owen

> Really interested.
> 
> Thanks,
> Frank
> 
> [1]
> by staff member asking why we don't replace the existing v6 /32 with
> something bigger.

Re: A crazy idea

[Frank Habicht]

Hi,

On 30/07/2021 07:58, Owen DeLong via NANOG wrote:> ...
> 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?”.


I recently got this "so?" question asked [1] and I believe I follow you
and see the point.

My response was along the line:
- today (at least here in AfriNIC-land - sorry to get out of "NA")
  the RIR charges membership fee depending on size of IPv4 allocations.
- Will the RIR charge membership fee depending on IPv6 allocation size
  in 5 years from now?

And it's a genuine question.
Does anyone know what the intentions or likelihood of options are?
Really interested.

Thanks,
Frank

[1]
by staff member asking why we don't replace the existing v6 /32 with
something bigger.

Re: A crazy idea

[Owen DeLong via NANOG]

> On Jul 19, 2021, at 06:04 , Stephen Satchell  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,  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 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 ever manufactured, you probably couldn’t fill the 
great lakes.

If you converted every IPv6 /64 prefix in the entire ::/0 to almond M, 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

Re: A crazy idea

[Daniel Corbe]

> On Jul 29, 2021, at 16:06, Joe Maimon  wrote:
> 
> 
> 
> t...@pelican.org wrote:
>> On Monday, 19 July, 2021 14:04, "Stephen Satchell"  said:
>> 
>>> 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,  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 or Skittles candy.
>> Nay, nay, and thrice nay.  Don't think in terms of addresses for IPv6, think 
>> in terms of subnets.  I can't stress this enough, it's the big v4 to v6 
>> paradigm shift - don't think about "how many hosts on this net", think about 
>> "how many nets".
> 
> Think of how many large ISP's a /3 of ipv6 effectively holds, assuming that 
> /48 per customer is the norm, and /24 up to /12 assignments for those ISP's 
> is also.
> 
> In those terms IPv6 isnt that much bigger.

I haven’t seen evidence that any RIR has allocated an entire /12 to an ISP.  
Even a large one.  

Re: A crazy idea

[Joe Maimon]

t...@pelican.org wrote:

On Monday, 19 July, 2021 14:04, "Stephen Satchell"  said:


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,  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 or Skittles candy.

Nay, nay, and thrice nay.  Don't think in terms of addresses for IPv6, think in terms of subnets.  
I can't stress this enough, it's the big v4 to v6 paradigm shift - don't think about "how many 
hosts on this net", think about "how many nets".


Think of how many large ISP's a /3 of ipv6 effectively holds, assuming 
that /48 per customer is the norm, and /24 up to /12 assignments for 
those ISP's is also.


In those terms IPv6 isnt that much bigger.

Re: A crazy idea

[Chriztoffer Hansen]

On Tue, 20 Jul 2021 at 17:41, Bryan Fields  wrote:
> On 7/20/21 10:01 AM, Michael Loftis wrote:
> > My apologies to everyone using an HTML mail client.
>
> No reason to apologize for that.  If someone is careless enough to use an HTML
> client on a mailing list, they deserve what they get :-D

Enable the setting in Mailman to enforce plain-text E-mail delivery
from the list address?

Re: A crazy idea

[Bryan Fields]

On 7/20/21 10:01 AM, Michael Loftis wrote:
> My apologies to everyone using an HTML mail client.

No reason to apologize for that.  If someone is careless enough to use an HTML
client on a mailing list, they deserve what they get :-D

-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: A crazy idea

[Michael Loftis]

On Tue, Jul 20, 2021 at 7:48 AM Michael Loftis  wrote:
>
> (Reply in-line)

My apologies to everyone using an HTML mail client.  Don't try in-line
replies with Google's iOS app.  *sigh*  Really, it's not a blank
reply...

The gist of my reply was.   Don't complain about DNS services when
you're not paying for DNS services.  register.com, godaddy, those are
registrars.  Go look for a managed DNS/authoritative DNS service
provider and almost any of them will happily accept a reverse DNS zone
delegation.  And for IPv4 less-than-boundary (well..I guess you could
use it for v6, but v6 should NEVER be on a less than boundary) see
RFC2317.

Again.  Apologies.  Honestly, it was my mail client that did it! :)

Re: A crazy idea

[Michael Loftis]

(Reply in-line)

On Mon, Jul 19, 2021 at 06:11 Stephen Satchell  wrote:

> First, I know this isn't the right place to propose this; need a pointer
> to where to propose an outlandish idea.
>
> PROBLEM:  IPv6 support is still in its birthing pangs.  I see a problem
> that limits deployment of IPv6 fully:  reverse PTR records in the
> ".in6.arpa." zones.
>
> (Now that I think about it, this may very well be a network operator
> issue.  Who maintains the ".in.arpa." zones delegated by IANA now?)
>
> I've been going 'round and 'round with AT about "static" IPv6
> addresses.  In particular, I can't get a PTR record in the ip6.arpa.
> zone to save my life.  Now, the problem is not really ripe yet, because
> the big reason for PTR records is for mail servers -- best practice
> calls for /PTR agreement, just like for IPv4 the best practice is
> for A/PTR agreement.
>
> The existing DNS providers can support delegation domains, so that I
> don't have to have DNS servers of my own if I don't want to.  It could
> be that one would need to "buy" the delegation domain, but that's a
> front-office consideration.  Personally, I use register.com for my
> domain DNS zones.  I believe strongly that other registrars that offer
> customer zone editing, plus DNS service providers, can support reverse
> delegation zones with a minimum of hassle, and without charging an arm
> and a leg for the service.


They’re not a DNS service provider. That is a registrar. Providing
authoritative DNS is incidental to their business and not their focus. Go
look for managed DNS or authoritative DNS services. There’s still the
problem of getting the  delegation which is largely unsupported for
consumer IP services. And honestly…I don’t really expect consumer (dynamic)
IP services to provide reverse delegation.  Business (definitely needs to)
and static IP services (really should) should provide either delegation of
the reverse zone or PTRs for non boundary ipv4 space per RFC2317.


 From the customers' viewpoint, a GUI would make the maintenance
> relatively painless.
>
> (Keying the information below took a long time.  Any rational DNS admin
> and DNS service provider would have automation in place to take out the
> painful work.)




>
>  > 96-103.194.65.99.in-addr.arpa. NS my-DNS-server-1
>  > 96-103.194.65.99.in-addr.arpa. NS my-DNS-server-2> $GENERATE 96-102 $
> IN CNAME $.96-103.194.65.99.in-addr.arpa.
>
> In my BIND9 zone file, it would look something like this:
>
> > $ORIGIN 96-103.194.65.99.in-addr.arpa.
> > @ SOA ...
> > @ NS my-dns-server-1.
> > @ NS my-dns-server-2.
> > 96 IN PTR server1.example.com.
> > 97 IN PTR server2.example.com.
>

See RFC2317.

>
> The advantage to this system to the number providers is they would have
> one administrative record per customer, instead of having to deal with
> each PTR record individually.  The advantage to customers is they don't
> have to beg and snivel to get PTR records, just beg and snivel once to
> get the delegation.  The advantage to DNS server providers is they have
> something else to sell.
>
> Want to encourage IPv6 adoption?  This would help.




> --

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler

Re: A crazy idea

[Mark Andrews]

It is theoretically possible to completely automate reverse DNS provisioning.
It just requires will to do it.  Enterprises have been doing automated reverse
DNS provisioning for decades now using DNS UPDATE requests from DHCP servers
using TSIG or GSS-TSIG.

This method does it as part of prefix delegation and provides support for
cryptographically secure updates by passing the public key as part of the
prefix delegation request.

https://www.ietf.org/archive/id/draft-andrews-dnsop-pd-reverse-02.txt

You could also just allow DNS UPDATE requests over TCP/IPv6 to add/delete NS
and DS records at the /48 level of reverse tree matching the TCP source address.
BIND has supported this for over a decade now as it was developed to provide a
mechanism to populate the 6to4 reverse zone (2.0.0.2.ip6.arpa).  It didn’t get
taken up as Geoff Huston decide to go the HTTP route.  I would have the DHCPv6
server delete the records when the prefix delegation expires.

key DHCP-SERVER {
...
};

zone 8.B.D.0.1.0.0.2.ip6.arpa {
...
update-policy {
  // limit to 10 NS records and 5 DS records.
  grant * 6to4-self . NS(10) DS(5);
  grant DHCP-SERVER subdomain *;
};
};

In both cases the customer populates the delegation and adds DS records as
required.

This is just bolting together existing technologies.

This will not take off unless ISPs buy into the mechanisms.

Mark

> On 20 Jul 2021, at 03:01, Bryan Fields  wrote:
> 
> On 7/19/21 8:09 AM, Stephen Satchell wrote:
>> First, I know this isn't the right place to propose this; need a pointer 
>> to where to propose an outlandish idea.
> 
>> What would the domain names look like?  Let's take my current IP/IPv6 
>> assignments from AT:
>> 
>>   2600:1700:79b0:ddc0::/64
>>   99.65.194.96/29
>> 
>> The IPv6 delegation would be easy:
>> 
>>> 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-1.
>>> 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-2.
> 
> Yup, simple, I do this for my customers (and DS records).
> 
> However that reverse zone has DNSSEC on it.  You'd need a DS record to tie
> my-DNS-server-1. to the ATT DNS server and your server would need to support
> DNSSEC.  ATT may want to enforce DNSSEC on that zone, but not want to sign
> stuff they can't control.
> 
> Just playing devils advocate.
> 
> -- 
> Bryan Fields
> 
> 727-409-1194 - Voice
> http://bryanfields.net

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

Re: A crazy idea

[Bryan Fields]

On 7/19/21 8:09 AM, Stephen Satchell wrote:
> First, I know this isn't the right place to propose this; need a pointer 
> to where to propose an outlandish idea.

> What would the domain names look like?  Let's take my current IP/IPv6 
> assignments from AT:
> 
>2600:1700:79b0:ddc0::/64
>99.65.194.96/29
> 
> The IPv6 delegation would be easy:
> 
>> 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-1.
>> 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-2.

Yup, simple, I do this for my customers (and DS records).

However that reverse zone has DNSSEC on it.  You'd need a DS record to tie
my-DNS-server-1. to the ATT DNS server and your server would need to support
DNSSEC.  ATT may want to enforce DNSSEC on that zone, but not want to sign
stuff they can't control.

Just playing devils advocate.

-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: A crazy idea

[John Waters via NANOG]

I'm with Tim on this.  I'm unsure if you've kept a mental note of just how big 
IPv6 is, but it's 340,282,366,920,938,000,000,000,000,000,000,000,000 IP 
addresses in IPv6

IPv4 on the other hand has 4,294,967,296 total IP addresses. 

I understand the issuance and total use leading to exhaustion concern, but at 
the same time, so long as we're somewhat sane with our using of IPv6, we will 
end up fine.
Thanks Much,
John Waters
President and Chief Architect
Capitol Hosting Solutions

//Dance like nobody is watching, Encrypt like everyone is.

\\This message was sent from my mobile device, please forgive any typos or 
brevity.

Jul 19, 2021 8:16:02 AM t...@pelican.org:

> On Monday, 19 July, 2021 14:04, "Stephen Satchell"  said:
> 
>> 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,  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 or Skittles candy.
> 
> Nay, nay, and thrice nay.  Don't think in terms of addresses for IPv6, think 
> in terms of subnets.  I can't stress this enough, it's the big v4 to v6 
> paradigm shift - don't think about "how many hosts on this net", think about 
> "how many nets".
> 
> It's potentially useful for SOHO users to have multiple subnets, particularly 
> as they stick multiple devices in their home network that try to do PD from 
> the upstream for each downstream function.  /56 for every SOHO is a 
> fire-and-forget, you don't have to dick about with right-sizing anything, you 
> don't have to evaluate requirements with the customer, you don't have to do 
> all kinds of management system stuff to track who has what size, and it gives 
> you some room for a couple of levels of hierarchy within the house.
> 
> Make all of the subnets /64s, and SLAAC etc Just Work too.
> 
> Wikipedia suggests a little short of 200M households in the US.  That's 28 
> bits of space to give a /56 to every household.  Let's assume ISPs are really 
> bad at aggregation, so those bits are spread across multiple PoPs, multiple 
> ISPs, etc, and we take 36 bits of space to actually allocate those.  (That's 
> only in /56 in every 256 used, *lots* of room for sparse PoPs, sparse ISPs, 
> etc).  Shift back 36 bits from a /56, we've used a /20 to number the entire 
> US.
> 
> Same again for India.  3 of those for China.  It's all smaller from there for 
> the rest of the world.  Maybe 100 or so /20s to number the entire world on 
> the same plan.  There are a million /20s in the IPv6 address space.
> 
> We've got room to be sensible about assignments without repeating the IPv4 
> scarcity problem.
> 
> Cheers,
> Tim.

Re: A crazy idea

[Randy Bush]

On Mon, 19 Jul 2021 09:27:13 -0700,
Nathan Angelacos wrote:
> 
> On Mon, 2021-07-19 at 08:51 -0700, Randy Bush wrote:
> > > Well, for SLAAC you need a /64
> > 
> > this is not true
> > 
> > randy
> 
> 
> That is cool!   Can you point me to the correct RFC please?
> 

from the war zone, draft-classless6/draft-nbourbaki-6man-classless-ipv6
said

   The length of the Interface Identifier in Stateless Address
   Autoconfiguration [RFC4862] is a parameter; its length SHOULD be
   sufficient for effective randomization for privacy reasons.  For
   example, 48 bits might be sufficient.  But operationally we
   recommend, barring strong considerations to the contrary, using
   64-bits for SLAAC in order not to discover bugs where 64 was hard-
   coded, and to favor portability of devices and operating systems.

   Note that OpenBSD ships with SLAAC for lengths longer than /64.

   Nonetheless, there is no reason in theory why an IPv6 node should not
   operate with different interface identifier lengths on different
   physical interfaces.  Thus, a correct implementation of SLAAC must in
   fact allow for any prefix length, with the value being a parameter
   per interface.  For instance, the Interface Identifier length in the
   recommended (see [RFC8064]) algorithm for selecting stable interface
   identifiers [RFC7217] is a parameter, rather than a hard-coded value.

Re: A crazy idea

[Nathan Angelacos]

On Mon, 2021-07-19 at 08:51 -0700, Randy Bush wrote:
> > Well, for SLAAC you need a /64
> 
> this is not true
> 
> randy


That is cool!   Can you point me to the correct RFC please?

Re: A crazy idea

[Randy Bush]

> Well, for SLAAC you need a /64

this is not true

randy

---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header butchery

Re: A crazy idea

[t...@pelican.org]

On Monday, 19 July, 2021 14:04, "Stephen Satchell"  said:

> 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,  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 or Skittles candy.

Nay, nay, and thrice nay.  Don't think in terms of addresses for IPv6, think in 
terms of subnets.  I can't stress this enough, it's the big v4 to v6 paradigm 
shift - don't think about "how many hosts on this net", think about "how many 
nets".

It's potentially useful for SOHO users to have multiple subnets, particularly 
as they stick multiple devices in their home network that try to do PD from the 
upstream for each downstream function.  /56 for every SOHO is a 
fire-and-forget, you don't have to dick about with right-sizing anything, you 
don't have to evaluate requirements with the customer, you don't have to do all 
kinds of management system stuff to track who has what size, and it gives you 
some room for a couple of levels of hierarchy within the house.

Make all of the subnets /64s, and SLAAC etc Just Work too.

Wikipedia suggests a little short of 200M households in the US.  That's 28 bits 
of space to give a /56 to every household.  Let's assume ISPs are really bad at 
aggregation, so those bits are spread across multiple PoPs, multiple ISPs, etc, 
and we take 36 bits of space to actually allocate those.  (That's only in /56 
in every 256 used, *lots* of room for sparse PoPs, sparse ISPs, etc).  Shift 
back 36 bits from a /56, we've used a /20 to number the entire US.

Same again for India.  3 of those for China.  It's all smaller from there for 
the rest of the world.  Maybe 100 or so /20s to number the entire world on the 
same plan.  There are a million /20s in the IPv6 address space.

We've got room to be sensible about assignments without repeating the IPv4 
scarcity problem.

Cheers,
Tim.

Re: A crazy idea

[Lukas Tribus]

Hello,

On Mon, 19 Jul 2021 at 15:04, Stephen Satchell  wrote:
> 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.

Well, for SLAAC you need a /64, so if you want to be able to use
multiple subnets in your environment, you need a prefix shorter than
/64.

RIPE's recommendation is /56 for residential customers:
https://www.ripe.net/publications/docs/ripe-690#4-2-2---48-for-business-customers-and--56-for-residential-customers

and *strongly discourages* to assign prefixes longer than /56
https://www.ripe.net/publications/docs/ripe-690#4-2-3--prefixes--longer-than--56


cheers,
lukas

Re: [EXTERNAL] Re: A crazy idea

[Feldman, Mark via NANOG]

On 7/19/21, 9:04 AM, "Stephen Satchell"  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".

It's true that not all ISPs do IPv6.  There are those that do support it and 
those that will.  At some point the pain associated with the lack of IPv4 
address space will outweigh the pain of IPv6 deployment.   Those that do IPv6 
should support all of the service that I described.

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.

Any DNS service provider should be able to host an in-addr.arpa or ip6.arpa 
zone.  If they don't do "reverse/PTR" zones, they're really not a full service 
provider.  Zones are zones.

I'm focusing on the SOHO customer market with my proposal.

My standard residential service has my router getting a /64 that allows my 
hosts to self-generate public, routable /128 IPv6 addresses using EUI64 and 
other mechanisms when I don't bother setting the RHS of the address.   I also 
get a single IPv4 address which gets NAT'd.   There's no reason for a SOHO 
customer to have less than that and there are reasons to have more.

Every modern device in my house preferes IPv6 when the service to which it is 
connecting is dual stack.  It all just works as-is.  When things break, it's 
usually an antiquated piece of equipment  that doesn't grok IPv6 itself or 
there's one in the way.

Most of our residential customers don't pay attention the underlying protocols. 
 They just plug things in and use them.  Well over half of the DNS queries 
coming from our customers come in over IPv6.

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,  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 or Skittles candy.

The standard for an IPv6 subnet is a /64.  It's what makes EUI64  and other 
useful addressing techniques possible.  You can't think of IPv6 with an IPv4 
scarcity mindset -- that will cause you to cripple IPv6.  And, no, even with 
/64 subnets, you won't run out of IPv6 addresses -- there are still billions of 
times more subnets available with IPv6  than there are host addresses in IPv4.

Making the standard subnet a /64 and having IPv6 delegations fall on nibble 
boundaries means a clean mapping to DNS without RFC2317 games.

We used to have someone with the title, IPv6 Evangelist.  He got us far.  Now 
it's everyone's job.

  Mark

Re: A crazy idea

[Jared Mauch]

> On Jul 19, 2021, at 9:04 AM, Stephen Satchell  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'm focusing on the SOHO customer market with my proposal.

Most are regional carriers w/ monopoly and no incentive to offer anything else. 
 This is especially the case with AT in my area.  The same applies to other 
regional providers like Frontier and even services like Verizon FIOS that do 
not offer IPv6 at all.

You really want a SMB connection w/ dedicated IP space, and they may not be 
able to sell that to you on their consumer network.

- Jared

Re: A crazy idea

[Stephen Satchell]

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'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,  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 or Skittles candy.

Re: A crazy idea

[Feldman, Mark via NANOG]

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.

  Mark


On 7/19/21, 8:13 AM, "NANOG on behalf of Stephen Satchell" 
 wrote:

First, I know this isn't the right place to propose this; need a pointer
to where to propose an outlandish idea.

PROBLEM:  IPv6 support is still in its birthing pangs.  I see a problem
that limits deployment of IPv6 fully:  reverse PTR records in the
".in6.arpa." zones.

(Now that I think about it, this may very well be a network operator
issue.  Who maintains the ".in.arpa." zones delegated by IANA now?)

I've been going 'round and 'round with AT about "static" IPv6
addresses.  In particular, I can't get a PTR record in the ip6.arpa.
zone to save my life.  Now, the problem is not really ripe yet, because
the big reason for PTR records is for mail servers -- best practice
calls for /PTR agreement, just like for IPv4 the best practice is
for A/PTR agreement.

The existing DNS providers can support delegation domains, so that I
don't have to have DNS servers of my own if I don't want to.  It could
be that one would need to "buy" the delegation domain, but that's a
front-office consideration.  Personally, I use register.com for my
domain DNS zones.  I believe strongly that other registrars that offer
customer zone editing, plus DNS service providers, can support reverse
delegation zones with a minimum of hassle, and without charging an arm
and a leg for the service.

 From the customers' viewpoint, a GUI would make the maintenance
relatively painless.

(Keying the information below took a long time.  Any rational DNS admin
and DNS service provider would have automation in place to take out the
painful work.)

What would the domain names look like?  Let's take my current IP/IPv6
assignments from AT:

   2600:1700:79b0:ddc0::/64
   99.65.194.96/29

The IPv6 delegation would be easy:

> 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-1.
> 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-2.

because the delegation would always be on a /64 boundary. The customer
assignments would be straightforward.  In my BIND9 zone file, it would
look something like this:

> $ORIGIN 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa.
> @ IN SOA ...
> @ NS my-DNS-server-1.
> @ NS my-DNS-server-2.
> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR server1.example.com.
> 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR server2.example.com.

Delegations for the IP range, not being on an octet boundary, would be a
little more problematic:

 > 96-103.194.65.99.in-addr.arpa. NS my-DNS-server-1
 > 96-103.194.65.99.in-addr.arpa. NS my-DNS-server-2> $GENERATE 96-102 $
IN CNAME $.96-103.194.65.99.in-addr.arpa.

In my BIND9 zone file, it would look something like this:

> $ORIGIN 96-103.194.65.99.in-addr.arpa.
> @ SOA ...
> @ NS my-dns-server-1.
> @ NS my-dns-server-2.
> 96 IN PTR server1.example.com.
> 97 IN PTR server2.example.com.

The advantage to this system to the number providers is they would have
one administrative record per customer, instead of having to deal with
each PTR record individually.  The advantage to customers is they don't
have to beg and snivel to get PTR records, just beg and snivel once to
get the delegation.  The advantage to DNS server providers is they have
something else to sell.

Want to encourage IPv6 adoption?  This would help.