SUMMARY: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG

[Pekka Savola <pekkas@netcore.fi>]

Hi,

I'll try to summarize this thread, or at least try to find the most 
important points from it, because it went on for long and I doubt 
many had energy enough to keep up with it.

(more accurately, I'll just summarize the first part of the thread that
was integral to the original topic, see the last point)

I believe we should try to avoid crossposting about this subject to both
v6ops and ipv6 WG in the future :-).

 - this seems like a problem that would merit from further investigation 

 - it was not sufficiently clear that this mechanism is about optimizing
away unnecessary DNS lookups and making them more robust (e.g. in the face
of DNS/load-balancer misbehaviour); default address selection does not
help in this case (however, if destination address selection is not
implemented, this method would give an additional benefit as well)

 - currently defined AI_ADDRCONFIG is rather vague, and it should be 
clarified in any case (e.g., "is address without route OK?") if it's
intended to be usable ("too ambiguous to implement")

 - the problem description (by yours truly) was not sufficiently clear, 
so it wasn't clear what problems the proposed modifications were trying to
address

 - some application writers are moving away / staying away from
getaddrinfo because of the side-effects of e.g. DNS
resolvers/load-balancers, also for the majority installed base of
IPv4-only and dual-stack (but without v6 connectivity) systems; this
option would help a bit there.

 - a system-level global knob, in addition to an application getaddrinfo 
hint, could be useful, but this should probably default to off at least 
(the point below)

 - the default application behaviour should not be changed, that is,
AI_ADDRCONFIG should remain optional; the getaddrinfo/system should not try
to second-guess what an application wants, nor hide information that exists
in the DNS unless the application indicates it wants the information
filtered

 - if sufficiently many people think link-locals w/ getaddrinfo would be a
useful feature, a tradeoffs document instead of a purely recommendations
document would be in order

 - this does not change the situation in the case where a route exists, 
but an ICMP DU is received (v6onbydefault-00 section 3.2 discusses this), 
or the case when the packets are silently dropped (e.g. by a discarding 
firewall)

 - the latter parts of the thread went into an area ("getaddrinfo should use
DNS-only vs not") beyond the main scope of the original topic, and are not
included in this thread summary; suffice to say that opinions differ on whether 
getaddrinfo should be agnostic of the lookup mechanism or not.  However, this 
does have a connection to the original debate: the addition of the link-locals
to AI_ADDRCONFIG would cause problems if getaddrinfo was used with local
lookup services (or similar) other than the DNS.  So, for the purposes of
AI_ADDRCONFIG and link-locals, the link local exclusion should probably be
limited to DNS or other similar naming services, if done.


---------- Forwarded message ----------
Date: Tue, 28 Oct 2003 14:30:05 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Cc: ipv6@ietf.org
Subject: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG

Hi,

(Cc:'ed to ipv6@ietf.org as well, because this seems to have significant 
impact with the IPv6 APIs as well..)

When revising my "transarch" document, I noticed another issue v6
on-by-default might cause.

If v6 is enabled by default, all the implementations I know generate the
link-local addresses for all the interfaces automatically, unless
explicitly configured otherwise (some don't have this knob).

This seems to cause an unintended consequence with getaddrinfo and its
AI_ADDRCONFIG hint (as specified in the basic socket API RFC).

That is, AI_ADDRCONFIG hint causes AAAA DNS queries to be made only if an
IPv6 address is configured on the node (similar with v4).  Loopback
addresses are excluded from this.  However, these typically autoconfigured
link-local addresses are *not* excluded.  In consequence, AI_ADDRCONFIG
seems to be of less utility than at least I had hoped.

The only reason I could think of for AI_ADDRCONFIG *not* excluding the
link-locals as well could be that if a node is expected to be able to 
communicate using regular, getaddrinfo() -using apps, using the link-local 
addresses (this would eliminate this possibility).

IMHO, using link-local addresses for anything except well-specified 
purposes (e.g. routing protocols, RFC2461/2, etc.) is really, really 
counter-productive -- as you'll have to make those apps be able to 
distinguish the zone identifiers as well, and that's probably something we 
DON'T want to do.  But your mileage may vary.

So, I'll conclude by a few questions to give food for thought:

 - does this seem like a  problem, that is, should getaddrinfo() + 
   AI_ADDRCONFIG perform AAAA DNS queries etc. if 
   the node only has v6 link-local/loopback addresses?

 - is getaddrinfo() + link-local addresses something we should support?

 - should this be fixed by e.g.:
   a) recommending that the implementations filter out link-locals as well 
      when doing AI_ADDRCONFIG (a BCP/Info document)
   b) specifying additional semantics for AI_ADDRCONFIG
   c) specifying a new hint which would perform this


Note: if we go select any of these (especially the latter two), it might
make sense to bring this discussion up in the relevant API forums like
POSIX as well, because the IETF API documents are just Informational RFCs.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------