Proposed RFC 3484/6724 subset for getaddrinfo

Proposed RFC 3484/6724 subset for getaddrinfo

[Rich Felker]

As mentioned as a possibility before, full support for RFC 3484/6724
result sorting in getaddrinfo seems quite bloated in terms of code
size and runtime overhead. For example, some of the tests require
using netlink to obtain full details on all configured interfaces,
which leads to nastiness like:

http://blog.powerdns.com/2014/05/21/a-surprising-discovery-on-converting-ipv6-addresses-we-no-longer-prefer-getaddrinfo/

So I'd like to propose a subset of the rules in RFC 6724 which I think
suffice for getaddrinfo's use with DNS results. For reference, the
original rules are here in section 6:

http://tools.ietf.org/html/rfc6724

Here are the rules I want to include, and the work needed to evaluate
them (letter in parens, defined below):

Rule 1: Avoid unusable destinations (A)
Rule 2: Prefer matching scope (B,C)
Rule 5: Prefer matching label (B,D)
Rule 6: Prefer higher precedence (E)
Rule 8: Prefer smaller scope (C)
Rule 9: Use longest matching prefix (B,F)
Rule 10: Otherwise, leave the order unchanged (G)

A: Usability: success/failure of UDP connect()
B: Source address: using getsockname on the socket from (A).
C: Scope: Simple computation, no syscalls.
D: Label: Simple computation, no syscalls.
E: Precedence: Simple computation, no syscalls.
F: Matching prefix length: Simple computation, no syscalls.
G: Original order index: Automatically available.

With this proposal, the needed syscalls would be (per result):

socket, connect, getsockname, close

None of these generate any network traffic; they only trigger local
routing logic by the kernel.

The rules being omitted are:

Rule 3: Avoid deprecated addresses
Rule 4: Prefer home addresses
Rule 7: Prefer native transport

As far as I can tell, rule 3 seems irrelevant to DNS results anyway. I
don't see how/why one would end up with a DNS result that's reachable
via a deprecated source address but not by the non-deprecated source
address that replaces it. The situation for rule 4 may be similar, but
I'm less clear on that. As for rule 7, I fail to see why it can't be
handled by rule 5 with a label that forces the source address for
tunneling/etc. to have a label thast mismatches all other addresses'
labels.

One more thing: for my proposal, the whole sorting operation would
only be applied when there are at least 2 results and at least one of
them is IPv6. Sorting does not seem useful for v4-only results.

Does this analysis/proposal seem reasonable?

Rich

Re: Proposed RFC 3484/6724 subset for getaddrinfo

[Rich Felker]

On Fri, Jun 20, 2014 at 11:56:51AM -0400, Rich Felker wrote:
> So I'd like to propose a subset of the rules in RFC 6724 which I think
> suffice for getaddrinfo's use with DNS results. For reference, the
> original rules are here in section 6:
> [...]

Implemented and committed.

Rich