Arifumi Matsumoto wrote:
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.
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?
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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--
Arifumi Matsumoto
Secure Communication Project
NTT Information Sharing Platform Laboratories
E-mail: arif...@nttv6.net
--
Aleksi Suhonen, Research Assistant
Department of Communications Engineering
Tampere University of Technology
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
