[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Jun 2014 11:56:51 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Proposed RFC 3484/6724 subset for getaddrinfo
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
