A crazy idea

Mailman List Mirror (Read Only)
1

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.

2

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

    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.

3

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.

4

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

5

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

6

Hello,

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:

and *strongly discourages* to assign prefixes longer than /56

cheers,
lukas

7

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.

8

Well, for SLAAC you need a /64

this is not true

randy

9

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

10

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.

11

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:

12

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.

13

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

14

(Reply in-line)

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.)

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.

15

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! :slight_smile:

16

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 :smiley:

17

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

18

tim@pelican.org wrote:

19

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

20

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