Mohacsi,
I think It should be implemented the following way:
for each source address in some order {
create socket
bind (current source address)
for each destination address in some order {
connect (current destination address)
do {
"select" for K ms or a result, whichever comes first
} while (result was a connection attempt failing)
if result was a connection succeeding goto "connected"
}
destroy socket }
connected:
....
Scaling remark: you would like to have #source_addresses x
#destination address sockets opened. I think it should not be an
issue....
"in some order" - ok here we arrived why RFC3484(bis) developed.
Node administrator (or site administrator if RFC3484 can be
propagated via e.g. DHCPv6) can define the order. Source address
selection is defining the order!
By the way would like to try with source address as link-local
address with destination as global address? This is
try_and_always_failure scenario.... This is another reason for
source address selection.
Your model is reasonable but it is also makes a further steps in
writing IP applications....
1. In early IPv4 era the application was written this way:
bind (to zero)
connect (first IPv4 address)
2. Later
bind (defined source address or zero)
for each destination address {
try connect destination address;
if successful break;
}
connected:
3. Now try all_source_address x all_destination_address. Which is
fair. Here I am saying to try all reasonable combination only with a
reasonable order.
That is why RFC 3484(bis) is useful.
This 3. is a huge step - which is requires modification in
applications. I am not against this one but we have to be careful -
keep compatibility with applications with earlier behaviours....
I agree that #source_addresses x #destination_address try-and-error
approach should
be useful. However, we should have reasonable pruning mechanism for
the pairs.
Pruning should be based on the address scopes and usages, and, what I
proposed at
Hiroshima, site/host administrators' policy.
Ideally, if one wishes to have a properly designed socket
interface, one puts that in a subroutine that one calls with a name
and gets either a connected socket or a failure in response, so
that the application knows nothing about IP addresses (see UNSAF).
But now I am engaging in wishful thinking - that the socket
interface would be reasonably designed.
Agreed. The implementation might benefit of the existing RFC 3484
(bis) policy table. This table can have static entries from policy
and dynamic entries (probably also has to be extended to keep
address pair). Each successful connections can create a dynamic
entry with full address inheriting the priority from the matching
static policy entry - according the source address selection the
longest match will win. Next time the full address will will. Each
dynamic entry should have expiry timer. Important each address
configuration on the host should flush all the dynamic entries from
the cache.
Regarding caching, I wrote in the previous e-mail,
Caching sometimes work nicely, and sometimes do harm.
I'm not sure we can create perfect-in-every-environment
caching algorithm.
Another point is the complexity.
The complexity should involve difficulties in e.g. trouble shooting.
Caching implies some form of storage, which probably involves a
kernel API, which I have not tried to prototype.
Fred and operator running IPv6!
I am still interested about your opinion for UDP or multicast
applications with your approach and operational questions, burdens
enumerated in my previous e-mail.
Do we send ICMP error messages with all the source addresses, also ? :)
--
Arifumi Matsumoto
Secure Communication Project
NTT Information Sharing Platform Laboratories
E-mail: arif...@nttv6.net
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
