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&T 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 AAAA/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&T: 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.
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" <nanog-bounces+mark_feldman=comcast.com@nanog.org on behalf of list@satchell.net> 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&T 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 AAAA/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&T: 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.
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, &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.
On Jul 19, 2021, at 9:04 AM, 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'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&T 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
On 7/19/21, 9:04 AM, "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". 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, &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. 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
Hello, On Mon, 19 Jul 2021 at 15:04, Stephen Satchell <list@satchell.net> 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-cust... and *strongly discourages* to assign prefixes longer than /56 https://www.ripe.net/publications/docs/ripe-690#4-2-3--prefixes--longer-than... cheers, lukas
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.
On Monday, 19 July, 2021 14:04, "Stephen Satchell" <list@satchell.net> 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, &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.
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.
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 tim@pelican.org:
On Monday, 19 July, 2021 14:04, "Stephen Satchell" <list@satchell.net> 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, &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.
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.
tim@pelican.org wrote:
On Monday, 19 July, 2021 14:04, "Stephen Satchell" <list@satchell.net> 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, &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. 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.
On Jul 29, 2021, at 16:06, Joe Maimon <jmaimon@jmaimon.com> wrote:
tim@pelican.org wrote:
On Monday, 19 July, 2021 14:04, "Stephen Satchell" <list@satchell.net> 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, &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. 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.
On Jul 29, 2021, at 14:14 , Daniel Corbe <daniel@corbe.net> wrote:
On Jul 29, 2021, at 16:06, Joe Maimon <jmaimon@jmaimon.com> wrote:
tim@pelican.org wrote:
On Monday, 19 July, 2021 14:04, "Stephen Satchell" <list@satchell.net> 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, &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. 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
On Jul 29, 2021, at 14:06 , Joe Maimon <jmaimon@jmaimon.com> wrote:
tim@pelican.org wrote:
On Monday, 19 July, 2021 14:04, "Stephen Satchell" <list@satchell.net> 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, &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. 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 than 8,000,000,000. Tell me again how IPv6 is not that much larger, Joe? Owen
Owen DeLong wrote:
On Jul 29, 2021, at 14:06 , Joe Maimon <jmaimon@jmaimon.com> wrote:
tim@pelican.org wrote:
On Monday, 19 July, 2021 14:04, "Stephen Satchell" <list@satchell.net> 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, &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. 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 than 8,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
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.cutler@consultant.com <mailto:james.cutler@consultant.com>
On Jul 19, 2021, at 11:12 AM, tim@pelican.org wrote:
On Monday, 19 July, 2021 14:04, "Stephen Satchell" <list@satchell.net> 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, &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.
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.
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
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.
On Jul 29, 2021, at 22:23, Frank Habicht <geier@geier.ne.tz> 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.
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&T:
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
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 <Bryan@bryanfields.net> 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&T:
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: marka@isc.org
(Reply in-line) On Mon, Jul 19, 2021 at 06:11 Stephen Satchell <list@satchell.net> 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&T 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 AAAA/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.)
<snip>
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
On Tue, Jul 20, 2021 at 7:48 AM Michael Loftis <mloftis@wgops.com> 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! :)
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
On Tue, 20 Jul 2021 at 17:41, Bryan Fields <Bryan@bryanfields.net> 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?
participants (17)
-
Bryan Fields -
Chriztoffer Hansen -
Daniel Corbe -
Feldman, Mark -
Frank Habicht -
james.cutler＠consultant.com -
Jared Mauch -
Joe Maimon -
John Waters -
Lukas Tribus -
Mark Andrews -
Michael Loftis -
Nathan Angelacos -
Owen DeLong -
Randy Bush -
Stephen Satchell -
tim＠pelican.org