On Fri, 20 Nov 2009, Stig Venaas wrote:
Fred Baker wrote:
On Nov 20, 2009, at 1:16 PM, Stig Venaas wrote:
My point is that if say the spacing is 10ms and the RTT is 100ms, you
will needlessly be trying many pairs (up to 10) before you realize that
perhaps the first you tried actually works.
My first point is that if you don't wait multiple seconds for every
timeout, you can get a reasonble RTT for the SYN/SYN-ACK and prevent people
from turning off IPv6 in the first place.
Yes, I agree with that. I only want to point out that we should not be
too agressive. Say 200ms between each might be reasonable, while I think
10ms is far too agressive.
This of course means that for people to be happy, there should not be
too many pairs to try, or we need a decent algorithm or method for
picking the most likely ones first. And of course caching. This could
maybe be done at the host/stack level or in the application.
Ffor the decent pair first can we use the updated RFC 3484 source address
selection.
I believe most TCP applications don't specify source addresses. Some
might store which destination address they successfully connected to
though. If the application does not bind to a specific source address,
it might be good if the stack caches which source addresses were
successful per destination (or destination prefix).
Yes. As I mentioned the source address selection policy table could be
extended with such a dynamic entries.
The dynamic entries should be flushed immediately, in case of
configuration any new address, or deletion of some existing addresses
(e.g. host no longer connectoed to a particular wifi lan etc.).
As Brian mentioned the full address should be cached....
Best Regards,
Janos Mohacsi
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
