Subject: RE: API suggestion

From: Richard Draves <[email-masked]>
Date: Tue, 21 Dec 1999 10:33:56 -0800

> > based on some recent experience porting code to use 
> getaddrinfo, I'd suggest
> > adding a flag that says return only IP addresses, either 
> AF_INET or AF_INET6
> > but not other address families. ...
> 
> Your suggestion (that you want to add new flag) is not 
> generic solution 
> and has drawbacks in 2 points at least:
> 
> 1. you cannot specify other set of families.
>    ex) IPv6 and IPv7 addresses are wanted, but I hate IPv4.
> 2. you cannot specify the order of items in answered list.
>    ex) I want to get IPv4 first because throughputs of IPv4 
> connections 
>        are much better than that of IPv6 ones.
> 
> Another aproach that I suggest, is to use multiple-hints that 
> can query 
> for multiple-families, multiple-socktypes and even multiple-flags 
> answers like this:

A problem with your suggestion is that the application is specifying whether
it wants to get IPv4 addresses before IPv6 or vice-versa. This should not be
up to the application, it should be controlled via some policy external to
the application.

But if you just allow multiple hints and not have the hint order constrain
the returned address order... sounds like a promising idea. It's certainly
general.

Rich
--------------------------------------------------------------------
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: Jim Bound <[email-masked]>
Date: Tue, 21 Dec 1999 14:22:51 -0500

Rich,

>up to the application, it should be controlled via some policy external to

I don't agree.  Applications moving to IPv6 should be able to have
control over how they begin adopting IPv6.

>the returned address order... sounds like a promising idea. It's certainly

Again I don't agree.

Applications should be able to say I want all Mapped Addresses first,
then I want pure IPv6 and then I want IPv4.  Another application can
reverse the order etc... 

This is the spirit of the present API and what we have implemented for
ISVs now.  My ISVs like this flexibility.

/jim

---

From: [email-masked]
Date: Wed, 22 Dec 1999 11:01:22 +0900

>then I want pure IPv6 and then I want IPv4.  Another application can

	Could you tell me how your "flexibility" argument interact with
	src/dst address selection algorithm in getaddrinfo(3) (rich's draft)?
	What happens if they conflict with each other?

	Or, on certain platform, AI_PASSIVE lookup should return struct
	addrinfo in certain order to make sense, as the platform does not
	allow AF_INET bind after AF_INET6 bind, or vice versa.

	In my personal opinion putting policy-ish item in two or more places
	is not a good idea.  I vote against hideaki's idea.

itojun

---

From: [email-masked]
Date: Wed, 22 Dec 1999 11:09:00 +0900

>	allow AF_INET bind after AF_INET6 bind, or vice versa.

	Note that there exists commercial product which does this behavior.
	(i.e. I'm not placing academic example)

itojun

---

From: Jim Bound <[email-masked]>
Date: Tue, 21 Dec 1999 22:44:52 -0500

Itojun,

>       What happens if they conflict with each other?

Good question.  How I view it as a product engineer is I will provide
ISVs with the ability to directly request the exact address or set of
addresses they want if the application requests that.  So in a sense I
would permit applications to shut off the defaults from src/dst addr
selection and matching, of course with the health warnings that go with
that decision.  I will not force the market or applications to adopt our
policies around APIs regardless what the IETF or XNET or anyone
mandates there will always be an API back door.  I also believe that is
what we did with the flags in getipnodebyname.  All we need to do is add
the flags to getaddrinfo and there is no need for further discussion.
How I get it to work with the src/dst algorithms we define is my problem
and how I handle the conflict.  Nothing we define should prevent this
behavior and we have not at this time.

All I have to say on this issue really.  Call it added value.

I assume your not against moving the flags from getipnodebyname to
getaddrinfo from our API cabal meeting at Wash D.C.?

/jim

---

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

>All I have to say on this issue really.  Call it added value.

	Hmm, I see.  Please be sure to state the backdoor as "this is
	backdoor, not standard".

>getaddrinfo from our API cabal meeting at Wash D.C.?

	correct.  I'm okay with addition of AI_ADDRCONFIG and such (carl's
	proposal).

	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.

itojun

---

From: Jim Bound <[email-masked]>
Date: Tue, 21 Dec 1999 23:04:15 -0500

Itojun,

>	Hmm, I see.  Please be sure to state the backdoor as "this is

The APIs are not "standards" but informational.  But I agree, when the
defaults are not used what happens must be documented.

>	correct.  I'm okay with addition of AI_ADDRCONFIG and such (carl's

OK thats cool.

>	describes background/goal of AI_ADDRCONFIG.

Agreed.  Can you keep track of this one for us when we start re-writing
the API?  So we don't loose it in the flurry of email.

thanks
/jim

---

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

> 	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.

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

	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: [email-masked]
Date: Wed, 22 Dec 1999 14:35:20 +0900

>	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.

>	can result need to be better documented.

	agreed.

itojun

---

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]