RFC 6724

RFC 6724

[Phillip Hellewell]

Assuming the comments in gai.conf are accurate, glibc still use
obsolete RFC 3484 for address selection.

RFC 6724 came out in 2012, so why does glibc still use RFC 3484 rules?

The changes since RFC 3484 can be seen here:
https://tools.ietf.org/html/rfc6724#appendix-B

Thanks,
Phillip Hellewell

Re: RFC 6724

[Phillip Hellewell]

Here are the policy tables for comparison:

RFC 3484:
      Prefix        Precedence Label
      ::1/128               50     0
      ::/0                  40     1
      2002::/16             30     2
      ::/96                 20     3
      ::ffff:0:0/96         10     4

RFC 6724:
      Prefix        Precedence Label
      ::1/128               50     0
      ::/0                  40     1
      ::ffff:0:0/96         35     4
      2002::/16             30     2
      2001::/32              5     5
      fc00::/7               3    13
      ::/96                  1     3
      fec0::/10              1    11
      3ffe::/16              1    12

In general, what you are seeing is a depreference for
old/obsolete/unreliable ipv6 prefixes such as Teredo, site-local,
6to4, 6bone, etc.

The changes look good and make sense to me, except for one minor tweak
I would suggest.  The rule for fc00::/7 was added so that global IPv6
would be preferred over ULAs.  That makes sense, but as you can see it
has also been placed below IPv4 (::ffff:0:0/96).  This also makes
sense if we are talking about a global IPv4 being preferred over a
(local) ULA IPv6.  However, if choosing between a private IPv4 (10/8,
172.16/12, 192.168/16) or a ULA IPv6, they have the same scope so the
IPv6 address ought to be preferred.  To solve this, I would add in
three rules for the private IPv4 prefixes with a precedence of 2, so
that ULA will be preferred over them.

Phillip

Re: RFC 6724

[Florian Weimer]

* Phillip Hellewell:

> Assuming the comments in gai.conf are accurate, glibc still use
> obsolete RFC 3484 for address selection.
>
> RFC 6724 came out in 2012, so why does glibc still use RFC 3484 rules?
>
> The changes since RFC 3484 can be seen here:
> https://tools.ietf.org/html/rfc6724#appendix-B

RFC 3484 has always been rather problematic (particularly Rule 9, which
we do not implement).

I seriously doubt that there is any benefit from address sorting.  It's
a layering violation, and it makes renumbering harder because you now
need to consider the impact on address sorting.  Its core assumptions
are also quite wrong on many networks (e.g., private addresses often
have less georeplication than public Internet service, so public
addresses are closer by).

In any case, I think address sorting should be performed by the caching
DNS resolver, not the stub resolver.  The caching resolver can obtain
more topology information.  For individual, short-lived application
processes, this is very hard.  On the stub resolver side, the only thing
that remains is the A/AAAA sorting policy because the caching DNS
resolver does not determine that.

Do you have a setup that actually relies on address sorting?  Do you
have any examples where DNS provides a set of addresses for a single
name with different labels/precedence, so that sorting the addresses
actually has an effect?

Currently, we have a lot of code which is questionable at best when it
makes a difference, but it's mostly unused.  I would like to remove it,
rather than keep maintaining it.

Thanks,
Florian

Re: RFC 6724

[Phillip Hellewell]

On Mon, Nov 12, 2018 at 4:20 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> RFC 3484 has always been rather problematic (particularly Rule 9, which
> we do not implement).
>
> I seriously doubt that there is any benefit from address sorting.  It's
> a layering violation, and it makes renumbering harder because you now
> need to consider the impact on address sorting.  Its core assumptions
> are also quite wrong on many networks (e.g., private addresses often
> have less georeplication than public Internet service, so public
> addresses are closer by).
>
> In any case, I think address sorting should be performed by the caching
> DNS resolver, not the stub resolver.

An administrator of a given machine may not have any control over the
DNS server, yet they should still be able to control address order,
e..g., to prefer IPv4 over IPv6 or vice-versa.

> Do you have a setup that actually relies on address sorting?  Do you
> have any examples where DNS provides a set of addresses for a single
> name with different labels/precedence, so that sorting the addresses
> actually has an effect?

Yes, this happens all the time.  Look no further than google.com.  It
has both A and AAAA.  As a system administrator, I should be able to
set up my prefix policy table to prefer IPv4 over IPv6 if desired.
That is just one example.  See RFC 6724 for more examples.

One should be able to control address order without having to set up
and run their own special DNS server/proxy/whatever.

> Currently, we have a lot of code which is questionable at best when it
> makes a difference, but it's mostly unused.  I would like to remove it,
> rather than keep maintaining it.

Please don't take away this ability.  I honestly can't believe you are
even suggesting it.  That would be three steps backwards and cripple
Linux's IPv6 support.  I would have to say Linux doesn't support IPv6
if you did that.

If you don't want to update the policy table to the latest RFC, just
leave it alone and forget I said anything.

Phillip

Re: RFC 6724

[Florian Weimer]

* Phillip Hellewell:

> On Mon, Nov 12, 2018 at 4:20 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> RFC 3484 has always been rather problematic (particularly Rule 9, which
>> we do not implement).
>>
>> I seriously doubt that there is any benefit from address sorting.  It's
>> a layering violation, and it makes renumbering harder because you now
>> need to consider the impact on address sorting.  Its core assumptions
>> are also quite wrong on many networks (e.g., private addresses often
>> have less georeplication than public Internet service, so public
>> addresses are closer by).
>>
>> In any case, I think address sorting should be performed by the caching
>> DNS resolver, not the stub resolver.
>
> An administrator of a given machine may not have any control over the
> DNS server, yet they should still be able to control address order,
> e..g., to prefer IPv4 over IPv6 or vice-versa.

If you can edit /etc/gai.conf, you can install Unbound or dnsmasq, too.

>> Do you have a setup that actually relies on address sorting?  Do you
>> have any examples where DNS provides a set of addresses for a single
>> name with different labels/precedence, so that sorting the addresses
>> actually has an effect?
>
> Yes, this happens all the time.  Look no further than google.com.  It
> has both A and AAAA.  As a system administrator, I should be able to
> set up my prefix policy table to prefer IPv4 over IPv6 if desired.
> That is just one example.

Do you have another example that does not involve sorting merely by
protocol?  Something that you have encountered personally?

> One should be able to control address order without having to set up
> and run their own special DNS server/proxy/whatever.

To be honest, I don't see any other way to get full RFC 6724 support
because the RFC requires various things for which I do not see direct
kernel support.

If we disable or limit sorting in glibc, at least you will be able to
get RFC 6724 support with a suitable NSS service module or caching DNS
server.

Thanks,
Florian

Re: RFC 6724

[Phillip Hellewell]

On Mon, Nov 12, 2018 at 10:43 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> If you can edit /etc/gai.conf, you can install Unbound or dnsmasq, too.

Installing and configuring a DNS server is quite a bit more involved
than editing gai.conf.

> Do you have another example that does not involve sorting merely by
> protocol?  Something that you have encountered personally?

My personal example is slightly more complex, but is still related to
sorting by protocol.  I have daul-stack at home, and my IPv6 router
advertisements also include a ULA prefix.  So every machine on my
network has at least a 192.168.8.x IPv4 address and an IPv6 address
with my ULA prefix.  My DNS is set up to return both (in no particular
order).  I was just noticing what it shows for "Last login" when
ssh-ing into my server and also what it shows by default when I ping a
machine.  Interestingly, the results differ when pinging from Linux vs
Windows.  From Linux it chooses the IPv6 ULA address, but from Windows
it chooses the IPv4 private address for the destination host.

I tracked down the reason for the difference to the prefix policy
table.  Linux adheres to the older RFC 3484, whereas Windows uses RFC
6724.  I was surprised to see Windows ahead of Linux in adhering to
IPv6 standards.  But the strangest part about all this is that, the
older standard actually gives more appropriate results in this case,
since IPv6 ought to be preferred over IPv4 when choosing between
equally valid and useful addresses.

That's why in conjunction with my suggestion to update to the RFC 6724
policy, I also brought up the idea of adding the rules for private
IPv4 prefixes so that IPv6 ULA will be preferred over them.  To be
honest, unless those rules are included I would prefer glibc be left
alone, because in my opinion the slight improvements are not worth it
unless that drawback is addressed.

> To be honest, I don't see any other way to get full RFC 6724 support
> because the RFC requires various things for which I do not see direct
> kernel support.

I'm not sure what exactly you are referring to in RFC 6724 that the
kernel doesn't support, but I was just focused on updating the
precedence rules.  I'm assuming those could be updated to include nine
rules from RFC 6724 rather than five rules from RFC 3484.

> If we disable or limit sorting in glibc, at least you will be able to
> get RFC 6724 support with a suitable NSS service module or caching DNS
> server.

I'm in favor of adding the ability to disable sorting, as long as it
is just an option and it's not that way by default.  I can't imagine
how many things might break if this were disabled.

Phillip

Re: RFC 6724

[Florian Weimer]

* Phillip Hellewell:

> I tracked down the reason for the difference to the prefix policy
> table.  Linux adheres to the older RFC 3484, whereas Windows uses RFC
> 6724.  I was surprised to see Windows ahead of Linux in adhering to
> IPv6 standards.  But the strangest part about all this is that, the
> older standard actually gives more appropriate results in this case,
> since IPv6 ought to be preferred over IPv4 when choosing between
> equally valid and useful addresses.

It's not so strange at all.  The address selection criteria have always
been fairly arbitrary.

> That's why in conjunction with my suggestion to update to the RFC 6724
> policy, I also brought up the idea of adding the rules for private
> IPv4 prefixes so that IPv6 ULA will be preferred over them.  To be
> honest, unless those rules are included I would prefer glibc be left
> alone, because in my opinion the slight improvements are not worth it
> unless that drawback is addressed.

I'm more interested in arguments for preferring some IPv4 addresses over
IPv6 address in the destination selection algorithm, and IPv6 over IPv4
in other cases.

>> To be honest, I don't see any other way to get full RFC 6724 support
>> because the RFC requires various things for which I do not see direct
>> kernel support.
>
> I'm not sure what exactly you are referring to in RFC 6724 that the
> kernel doesn't support, but I was just focused on updating the
> precedence rules.  I'm assuming those could be updated to include nine
> rules from RFC 6724 rather than five rules from RFC 3484.

I'm not sure if the kernel has a concept of a home address.  That seems
to be something that would be maintained by higher-level tools such as
NetworkManager or systemd.

Thanks,
Florian

Re: RFC 6724

[Phillip Hellewell]

On Tue, Nov 13, 2018 at 3:51 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> I'm more interested in arguments for preferring some IPv4 addresses over
> IPv6 address in the destination selection algorithm, and IPv6 over IPv4
> in other cases.

In general I believe there are two goals:
1. Prefer global scope over local scope.
2. Prefer IPv6 over IPv4 (except for old/obsolete/unreliable IPv6 mechanisms).

I believe #1 takes precedence over #2, hence the reason why an IPv4
could be preferred over IPv6 in some cases.

> I'm not sure if the kernel has a concept of a home address.  That seems
> to be something that would be maintained by higher-level tools such as
> NetworkManager or systemd.

That's fine.  Then ignore rule 4 as far as getaddrinfo is concerned.
That doesn't mean throw the whole RFC out the window.  RFC 3484 had
that rule too.

All I'm asking is that the default policy table be updated; since RFC
6724 came out 6 years ago it surprises me that it hasn't already been
updated.

But at the same time I'm contracting myself because actually I don't
want the table to be updated unless we also address the concern that
local IPv6 should be preferred over local IPv4.

Phillip