Subject: addr sel API?

From: Aleksi Suhonen <[email-masked]>
Date: Mon, 29 Jun 2009 14:40:53 +0300

Hi,

Address selection happens in many places: in some cases it's supposed to 
happen inside the kernel, in some cases inside a library and in some 
cases in the application.

Would it make sense to create a uniform API so that no matter where it 
takes place, it has access to all the same input and configuration?

Implementors can then decide if it should be centralized in the kernel, 
in libc/libsocket/libnsl/libresolv, in some sort of a server or service 
or whatever.

The API should be fully re-entrant and iterative and it should support 
constraints, I guess?

A good API would make future improvements in the address selection 
algorithm easier to transfer from the drawing board into production use.

Thoughts? Comments? Or does it exist already and I'm just ignorant?

-- 
	Aleksi Suhonen

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 30 Jun 2009 13:28:18 +0900

Hi,

is RFC 5014 what you are looking for ?

On 2009/06/29, at 20:40, Aleksi Suhonen wrote:

> Hi,
>
> Address selection happens in many places: in some cases it's  
> supposed to happen inside the kernel, in some cases inside a library  
> and in some cases in the application.
>
> Would it make sense to create a uniform API so that no matter where  
> it takes place, it has access to all the same input and configuration?
>
> Implementors can then decide if it should be centralized in the  
> kernel, in libc/libsocket/libnsl/libresolv, in some sort of a server  
> or service or whatever.
>
> The API should be fully re-entrant and iterative and it should  
> support constraints, I guess?
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--
Arifumi Matsumoto
   Secure Communication Project
   NTT Information Sharing Platform Laboratories
   E-mail: [email-masked]

---

From: Aleksi Suhonen <[email-masked]>
Date: Tue, 30 Jun 2009 16:38:46 +0300

> is RFC 5014 what you are looking for ?

No, that seems to only deal with source address selection. It also 
doesn't deal with IPv4 at all.

What I was thinking of is an API, where you supply a set of source 
addresses and destination addresses and it returns a set of valid 
address pairs ordered by preference.

You could optionally give it constraints and you could also optionally 
request extra info, like next-hops and link numbers.

The simplest use case would be when some app tries to connect a socket 
with IPADDR_ANY and a single destination address. Either the socket 
library or the kernel would then call this API with the very minimal 
input. It would then proceed to try to create the requested connection 
by using the resultant address pairs in the given order until one works.

A more complex use case would be when some MTA finds five MX records 
with the same priority. It would then resolve all the addresses for them 
and give them all as the set of destination addresses along with what 
ever it has been configured with as the source addresses to the API. 
(This was the most extreme case of application level address selection I 
could come up with.)

The point I'm trying to make is that basic address selection decisions 
can happen in many places (kernel, library, server code, client code) 
and there's a need for network administrators to be able to influence 
those decisions. If some new protocol for this purpose is created or if 
some new address selection methods are defined, all the thousands of 
server and client software may potentially need to be rewritten to 
support it.

Alternatively, if address selection is centralized, it can be improved 
without having to rewrite everything else.

>> Address selection happens in many places: in some cases it's supposed 
>> to happen inside the kernel, in some cases inside a library and in 
>> some cases in the application.
>>

-- 
	Aleksi Suhonen, Research Assistant
	Department of Communications Engineering
	Tampere University of Technology

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 30 Jun 2009 16:22:34 +0200

> Thoughts? Comments? Or does it exist already and I'm just ignorant?

No. There is no standard API for this, and it is a major road block to
implementing dual-stack correctly in some scenarios.

The problem is simply that getaddrinfo() ties the method to obtain the
address data (typically DNS and local IP stack configuration), with the
algorithm. However, it is not as simple as creating a function that takes
two lists of addresses and returns a list of pairs of addresses. Most
commonly, the caller still wants to use the locally assigned addresses (or
a subset thereof) for the source addresses. I considered writing one spec
for that, but I got side-tracked with other things...

So... For plain RFC3484, the input data could simply be a chained-list of
struct addrinfo, and the output data another chained-list of struct
addrinfo. But I can only hope that RFC3484 update won't render this
inadequate :-/ Who knows what people will want to put into source address
selection algorithms in the future?

-- 
Rémi Denis-Courmont

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 30 Jun 2009 16:29:27 +0200

> server and client software may potentially need to be rewritten to

Lets not over-dramatize the situation... Only agents that cannot use
getaddrinfo() yet still need some destination addresses prioritizing are
potentially affected. In most cases, you can use getaddrinfo(). And when
not, you do not necessarily want to use source address selection.

I fully agree that there is a problem, but it's not _that_ bad.

-- 
Rémi Denis-Courmont