RFC 3484 goals: partial or full coverage?

RFC 3484 goals: partial or full coverage?

[Rich Felker]

RFC 3484 (http://tools.ietf.org/html/rfc3484) defines a number of
rules for sorting IP (mainly v6, or v6 mixed with v4) addresses for a
host in the order an application should prefer them in. The intent is
that getaddrinfo should apply these rules on name lookups. However
the rules range from being mildly to seriously expensive to apply, and
thus I'd like to gauge the level of interest in supporting them all
versus a subset.

Here are some of my thoughts so far:

Avoiding unreachable destinations is the purpose of the first rule,
and it already incurs some of the expense to check whether the address
is reachable, but that work also yields results that aid in applying
other rules (including the second), so it's not so bad.

I don't even understand how one determines if an address is deprecated
or if it's a home address, and it's probably expensive. I also don't
understand how/why a dns lookup would ever yield a set of results
where one is only reachable over a deprecated source address and the
other is reachable via a non-deprecated source address, or similar for
home and care-of addresses. If dns is just returning proper public
addresses, it seems rules 3 and 4 could be completely ignored.

Rules 5 and 6 depend on parsing gai.conf (unless we want to force the
hard-coded tables only, but I think it makes sense to support
system-local tables) which could possibly be skipped when the earlier
rules are sufficient.

Rule 7 seems mostly or fully redundant with the matching-label and
preference rules (5 and 6) which seem sufficient to prevent 6to4
addresses from being favored over native ones.

Rules 8 through 10 are trivial to apply.

If all results are v4, or if there's only one result, there's no need
to perform any sorting. There may be other cases I'm not thinking of
where this also applies. We definitely want to avoid applying any
sorting to numeric lookups and typical (single-result) hosts-file
lookups since the checks needed for the sorting would be many orders
of magnitude slower than these lookups are now (but much faster than
dns queries). At least if the RFC 3484 procedure is simplified
somewhat, I think it's possible to generate single integer sort keys
for each result so that sorting them is trivial with qsort (no heavy
comparison function).

Ideally I'd like to avoid adding more than ~500 bytes of code size to
libc (and static binaries using it) to make this stuff work, and I
certainly don't want to add runtime costs that are unreasonable to
many users. But choosing whether to return v4 or v6 results first
(this is one of the most visible effects of the whole procedure) seems
pretty important from a sense of not pessimizing systems that have
both v4 and v6 but where using one is much worse than the other.

Rich

Re: RFC 3484 goals: partial or full coverage?

[u-igbb]

On Mon, Jun 02, 2014 at 11:29:09PM -0400, Rich Felker wrote:
> Ideally I'd like to avoid adding more than ~500 bytes of code size to
> libc (and static binaries using it) to make this stuff work, and I
> certainly don't want to add runtime costs that are unreasonable to
> many users. But choosing whether to return v4 or v6 results first
> (this is one of the most visible effects of the whole procedure) seems
> pretty important from a sense of not pessimizing systems that have
> both v4 and v6 but where using one is much worse than the other.

+1

Rune