Hi,
(Cc:'ed to [EMAIL PROTECTED] 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
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
