[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG



Having looked at this again, I'm firmly convinced that:

- if address family is set to AF_UNSPEC, getaddrinfo() should by default 
  attempt both IPv4 and IPv6 lookups - even if the local system is not 
  capable of communicating on both IPv4 and IPv6.  it can be useful to do A 
  lookups even if the local system doesn't support IPv4, and it can be useful 
  to do AAAA lookups even if the local system doesn't support IPv6.  the job 
  of an API is to do what the application tells it to do, not to guess what 
  the application needs.  when getaddrinfo() tries to be too clever (as it 
  does on some platforms) it gets in the way and makes it difficult just to
  do simple DNS lookups.

  this implies that a feature to avoid A or AAAA lookups on systems that
  cannot communicate on v4 or v6 (respectively) should be optional, as
  AI_ADDRCONFIG is.

- It's highly desirable to avoid unnecessary DNS queries.  DNS is too
  slow and unreliable for single queries; multiple queries only makes this
  worse.  There are various ways that DNS could be updated to return the same
  information in fewer round-trips, but none of them would obviate the need
  for hosts to do multiple concurrent queries in the near term.

- AI_ADDRCONFIG is an imperfect heuristic, not a reliable indicator of whether
  an address can be used.  that doesn't mean that it's useless, but it does
  mean that people need to be aware of its limitations and not rely on it to
  do magic - in particular, it will not do a perfect job of either avoiding
  unnecessary lookups and connection attempts, or (due to race conditions)
  of finding all usable addresses.

- getaddrinfo SHOULD ONLY DO DNS QUERIES.  LLMNR/mDNS, NIS/NIS+, netinfo, WINS
  and local file lookups only serve to cause divergence between platforms
  and problems for apps that need a consistent view of DNS.

  (Note: I don't expect to get consensus for this view, so I'll offer a 
  less radical view:   Apps whose behavior is defined based on "what DNS
  says",  rather than some other name lookup service, need a portable and
  reliable way to find out "what DNS says" without having to supply their own
  DNS lookup routines.  e.g. maybe there needs to be a AI_DNS_ONLY flag for 
  getaddrinfo?)

- if AI_ADDRCONFIG is set, the decision of whether to do DNS lookups for a
  particular address family should ignore link-local addresses as well as 
  loopback addresses.  This is in keeping with the notion that AI_ADDRCONFIG 
  is an imperfect heuristic.  The configuration of only link-local addresses 
  for a particular address family is a good (though imperfect) indicator 
  that DNS queries for that address family will not yield usable results.

  OTOH, if getaddrinfo() is set up (against my better judgement) to do 
  queries from services other than DNS, the choice of whether to query other
  services might not want to ignore link-local addresses.  For example,
  on a host with only a v4 link-local address configured it might make
  sense to query LLMNR for A records.

- IMHO, getaddrinfo()'s job should be to report what is in DNS, not to try to
  coerce apps into behaving well.  So even though apps shouldn't be using
  link-local addresses, and even though people shouldn't list link-local
  addresses in DNS, getaddrinfo() should not try to hide such addresses from
  apps if they happen to appear in DNS.

Keith

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