Dear All,
On Wed, 11 Nov 2009, Fred Baker wrote:
On Nov 11, 2009, at 2:00 AM, Mohacsi Janos wrote:
I think this try_and_success_or_failure method can work in most cases,
however it has some burden for implementation and operational point of
view,
It does indeed, at least operationally. That is trivially solved for sites
one frequently visits, using a cache - if one finds that address pair
{source, destination} works one time, one might try it first next time.
As to the implementation, I have written the code for the naive version on
Linux (and then threw it away for some reason), and it's not too hard. It
comes down to
get all of my addresses
get all his addresses
for each address pair in some order
"connect" on the socket
do {
"select" for K ms or a result, whichever comes first
} while (result was a connection attempt failing)
if result was a connection succeeding, break
}
// at this point we have an open connection or some outstanding
while (we have no open connection and some connection attempts in progress) {
"select" seeking a result
}
if (we have a connection open) {
for each connection attempt except that one {
close it
}
}
return the connected socket
Yes, very similar to the code advocated by KAME folks:
http://www.kame.net/newsletter/19980604/
But the devils in the details:
- How do you scale with this part of your code snippet:
for each address pair in some order
"connect" on the socket
do {
"select" for K ms or a result, whichever comes first
} while (result was a connection attempt failing)
if result was a connection succeeding, break
}
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....
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.
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.
Best Regards,
Janos Mohacsi
Head of HBONE+ project
Network Engineer, Deputy Director of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
