Subject: AI_ADDRCONFIG

From: [email-masked]
Date: Wed, 22 Dec 1999 14:35:20 +0900

>> 	Separate issue: AI_ADDRCONFIG does not seem very useful for me, as
>> 	AI_ADDRCONFIG can return IPv6 address if I have ::1 (and only ::1)
>> 	configured on my host.  In this case I will not be able to reach
>> 	anyone outside via IPv6.  We'd better have more text in 2553bis, that
>> 	describes background/goal of AI_ADDRCONFIG.
>	Why isn't it useful?  You may be looking up "localhost".
>	The worst that will happen is you will get network unreachable
>	when you try to connect / send.  AI_ADDRCONFIG is an optimisation.

	AI_ADDRCONFIG checks list of local addresses to determine which
	family to return.  I'm not sure if it optimizes it.  It highly
	depends on what kind of behavior the OS kernel takes.

	There can be several choices in design principle level:
	- getaddrinfo(3) is name resolution function, this should not change
	  behavior based on what kernel supports, what configured onto my
	  interfaces.
	  getaddrinfo(3) can simply return anything it have resolved via DNS.
	  socket(2) or connect(2) may fail, user application should make a
	  loop over whatever getaddrinfo(3) returned.
	- getaddrinfo(3) should mask address families that are not supported
	  by kernel, to save from unnecessary socket(2) in user code.
	- getaddrinfo(3) should mask address families that are not configured
	  onto my interfaces.  this is what AI_ADDRCONFIG does.
	rfc2553 does not really state which is the intended behavior.

	I'm not sure which is the best one.  I'm not sure which is the
	way to go.  Actually kame getaddrinfo(3) implements 2nd case, but
	I don't really think it to be a good solution.

>	I do however agree that AI_ADDRCONFIG and the error states than
>	can result need to be better documented.

	agreed.

itojun
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Wed, 22 Dec 1999 15:33:27 +1100

Mark
--
Mark Andrews, Internet Engines Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 21 Dec 1999 21:58:16 -0800 (PST)

> 	describes background/goal of AI_ADDRCONFIG.

We actually had the opportunity to play with this exact issue
at Sun a while back.
For a while we thought we should really make AI_ADDRCONFIG mean
"have addresses that can be used to communicate outside the box"
but this is a bit tricky to clearly define.

So instead we took the path of not configuring the IPv6 loopback address
unless there is some other interface being configured for IPv6.

That seems to solve the ::1 issue.
But keep in mind that AI_ADDRCONFIG should really be viewed as an optimization
and nothing more - avoid returning addresses to the application which we know
are useless. A robust application should try all addresses that are returned
from getipnodebyname/getaddrinfo.

   Erik

---

From: Francis Dupont <[email-masked]>
Date: Tue, 28 Dec 1999 20:06:27 +0100

In your previous mail you wrote:

   	anyone outside via IPv6.

=> Jean-Luc Richier has asked how to implement this and our current
solution is to say IPv6 is available when the IPv6 routing table is not
empty. Another solution was to use to use something like in6_interfaces
(which counts non-loopback interfaces with an IPv6 address) but it was
more complex and the whole issue not very clear...

        We'd better have more text in 2553bis, that
   	describes background/goal of AI_ADDRCONFIG.
   
=> I *agree*!

Thanks

[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 21 Dec 1999 21:58:16 -0800 (PST)

Erik

---

From: [email-masked]
Date: Wed, 22 Dec 1999 14:35:20 +0900

agreed.

itojun

---

From: [email-masked]
Date: Wed, 22 Dec 1999 15:33:27 +1100

Mark

---

From: Francis Dupont <[email-masked]>
Date: Tue, 28 Dec 1999 20:06:27 +0100

=> I *agree*!

Thanks

[email-masked]