Subject: Thoughts on address selection

From: Fred Baker <[email-masked]>
Date: Tue, 10 Nov 2009 10:42:54 +0900

I'm following up on the discussion just had in 6man regarding address  
selection. I have this awful feeling that we are fighting off the  
alligators and forgetting to drain the swamp.

Correct me if I am wrong. The objectives being the source address  
selection algorithm are to:
   1) keep a datagram within as local a routing domain as possible
   2) to facilitate the lowest possible RTT during an exchange
   3) to work around issues caused by ingress filtering (BCP 38/84)

In short, we recommend that the source, which knows its own addresses,  
compare them to the known addresses of a potential destination, and  
choose the address pair that have the largest number of contiguous  
prefix bits in common. This achieves (1), and in so doing potentially  
achieves (2), although there are ample cases in which that is not so.  
Overcoming those failure cases and (3) are the real issue the table in  
RFC 3484 addresses.

Am I correct?

It seems to me that at least in part, this is a matter of making very  
broad assumptions about routing that may not be valid. It seems to me  
that there are two things we can do reliably. I have mentioned these  
to you before, in the v6ops context; let me bring them up again. They  
come down to - if you want the host to make statements about the  
network, I think it needs to know more than it currently knows about  
the network, either by measurement or by explicit communication.

I think the simplest solution to (2) is, frankly, to open connections  
at some rate (if I have N addresses and my peer has M, send a SYN-or- 
whatever on successive pairs in the cross-product every K milliseconds  
until I get a SYN-ACK on one of them, and then close all other  
sessions). The order of selection is determined according to the  
prefix length algorithm - the fastest responder is likely to be the  
most local domain, which is likely to be the one with a common prefix.  
In local scenarios, "open successive sessions" boils down to opening  
one session; in more remote scenarios, it will tend to select an  
address pair that (a) works and (b) has low RTT relative to the  
routing implied by other address pairs.

The simplest solution to (3), if my machine is in an administrative  
domain facing an ISP, is to have my DMZ router perform the BCP 38  
filter before the datagram reaches the ISP, and in the failure case  
reply with some form of ICMP message that says "routing took your  
datagram to an egress into the ISP with prefix <mumble>; select an  
address in prefix <mumble>". That will give the host the opportunity  
to select the correct address to traddle ingress filtering reliably.

Is there another requirement I'm missing? I don't think a table in the  
host that attempts to outthink the network is reliable or wise.

http://tools.ietf.org/html/draft-arifumi-6man-addr-select-conflict
   "Considerations of address selection policy conflicts", Arifumi
   Matsumoto, Tomohiro Fujisaki, Ruri Hiromi, 24-Oct-09,
   <draft-arifumi-6man-addr-select-conflict-01.txt>

http://tools.ietf.org/html/draft-ietf-6man-addr-select-considerations
   "Considerations for IPv6 Address Selection Policy Changes", Tim  
Chown,
   19-Oct-09, <draft-ietf-6man-addr-select-considerations-00.txt>

http://tools.ietf.org/html/draft-ietf-6man-addr-select-sol
   "Solution approaches for address-selection problems", Arifumi  
Matsumoto,
   Tomohiro Fujisaki, Ruri Hiromi, Ken-ichi Kanayama, 1-Jul-09,
   <draft-ietf-6man-addr-select-sol-02.txt>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Nov 2009 14:54:13 +1300

Fred,

Another approach to problem 3 is to extract REAP from SHIM6
and figure out how to use it to enhance address selection
in practice.

   Brian

On 2009-11-10 14:42, Fred Baker wrote:
> that there are two things we can do reliably. I have mentioned these to
> you before, in the v6ops context; let me bring them up again. They come
> down to - if you want the host to make statements about the network, I
> think it needs to know more than it currently knows about the network,
> either by measurement or by explicit communication.
> 
> I think the simplest solution to (2) is, frankly, to open connections at
> some rate (if I have N addresses and my peer has M, send a
> SYN-or-whatever on successive pairs in the cross-product every K
> milliseconds until I get a SYN-ACK on one of them, and then close all
> other sessions). The order of selection is determined according to the
> prefix length algorithm - the fastest responder is likely to be the most
> local domain, which is likely to be the one with a common prefix. In
> local scenarios, "open successive sessions" boils down to opening one
> session; in more remote scenarios, it will tend to select an address
> pair that (a) works and (b) has low RTT relative to the routing implied
> by other address pairs.
> 
> domain facing an ISP, is to have my DMZ router perform the BCP 38 filter
> before the datagram reaches the ISP, and in the failure case reply with
> some form of ICMP message that says "routing took your datagram to an
> egress into the ISP with prefix <mumble>; select an address in prefix
> <mumble>". That will give the host the opportunity to select the correct
> address to traddle ingress filtering reliably.
> 
>   "Considerations for IPv6 Address Selection Policy Changes", Tim Chown,
>   "Solution approaches for address-selection problems", Arifumi Matsumoto,
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 10 Nov 2009 11:09:07 +0900

Fred, 

For your icmp see 3.4 in:
http://www.ietf.org/internet-drafts/draft-hain-ipv6-fwrh-02.txt

Tony

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Fred Baker
> Sent: Tuesday, November 10, 2009 10:43 AM
> To: [email-masked]; draft-ietf-
> [email-masked]; draft-ietf-6man-addr-
> [email-masked]
> Cc: IETF IPv6 Mailing List
> Subject: Thoughts on address selection
>

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 10 Nov 2009 11:19:03 +0900

Fred,

On 2009/11/10, at 10:42, Fred Baker wrote:

> I'm following up on the discussion just had in 6man regarding  
> address selection. I have this awful feeling that we are fighting  
> off the alligators and forgetting to drain the swamp.
>
> In short, we recommend that the source, which knows its own  
> addresses, compare them to the known addresses of a potential  
> destination, and choose the address pair that have the largest  
> number of contiguous prefix bits in common. This achieves (1), and  
> in so doing potentially achieves (2), although there are ample cases  
> in which that is not so. Overcoming those failure cases and (3) are  
> the real issue the table in RFC 3484 addresses.
>
> Am I correct?

3) is not the only case that the policy table is designed for.
And, that's the thing the DT are working on.

> It seems to me that at least in part, this is a matter of making  
> very broad assumptions about routing that may not be valid. It seems  
> to me that there are two things we can do reliably. I have mentioned  
> these to you before, in the v6ops context; let me bring them up  
> again. They come down to - if you want the host to make statements  
> about the network, I think it needs to know more than it currently  
> knows about the network, either by measurement or by explicit  
> communication.
>
> I think the simplest solution to (2) is, frankly, to open  
> connections at some rate (if I have N addresses and my peer has M,  
> send a SYN-or-whatever on successive pairs in the cross-product  
> every K milliseconds until I get a SYN-ACK on one of them, and then  
> close all other sessions). The order of selection is determined  
> according to the prefix length algorithm - the fastest responder is  
> likely to be the most local domain, which is likely to be the one  
> with a common prefix. In local scenarios, "open successive sessions"  
> boils down to opening one session; in more remote scenarios, it will  
> tend to select an address pair that (a) works and (b) has low RTT  
> relative to the routing implied by other address pairs.
>
> Is there another requirement I'm missing? I don't think a table in  
> the host that attempts to outthink the network is reliable or wise.

What we are working on is not to make the host's decision better,
but provide a method for a network administrator to propagate
his policy to the client.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 10 Nov 2009 08:25:07 +0200 (EET)

On Tue, 10 Nov 2009, Fred Baker wrote:
> The simplest solution to (3), if my machine is in an administrative domain 
> facing an ISP, is to have my DMZ router perform the BCP 38 filter before the 
> datagram reaches the ISP, and in the failure case reply with some form of 
> ICMP message that says "routing took your datagram to an egress into the ISP 
> with prefix <mumble>; select an address in prefix <mumble>". That will give 
> the host the opportunity to select the correct address to traddle ingress 
> filtering reliably.

Just as a comment: the router might not know why it's doing BCP 38 
filtering and what the right prefix is. So it's more general and 
easier to just say "you're using a wrong source address, try something 
else" (e.g., if a packet is coming from a source address that's 
"directly connected" or otherwise do a silent discard.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Tue, 10 Nov 2009 09:37:40 -0500

> I think the simplest solution to (2) is, frankly, to open connections
at some
> rate (if I have N addresses and my peer has M, send a SYN-or- whatever
on
> successive pairs in the cross-product every K milliseconds until I get
a SYN-ACK
> on one of them, and then close all other sessions). 

+1

I think what Fred mentioned is the only real way we're going to solve
the address selection problem.  If you don't try pairs and select which
one works first, then you're stuck trying to outguess the network design
at the operating system layer.  Any approach to do this will work in
some cases and fail in others.  It would be very hard for the IETF to
judge whether some combination of approaches works more often than it
fails - because that would involve some notion of what a "typical"
network topology is.

- Wes

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 10 Nov 2009 18:00:13 +0100 (CET)

> fails - because that would involve some notion of what a "typical"

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, in my opinion:

1. the applications using getaddrinfo() library function has to be 
rewritten: most application written in principle of trying all available 
destination addresses, but no mechanism/logic in the codes to successively 
try all the source addresses. Of course this can be made hidden with some 
kernel implementation hacks, but this can be non-deterministic.

2. With application using UDP and/or multicast your 
try_and_success_or_failure might not scale. Will you send 
n(#source_address) X m(#destination_address) to the target node/group? 
Will it scale with multicast? Are you willing to increase the load of the 
e.g. DNS servers?

3. Are you happy from operational point of view some non-determinism in 
your incoming transactions? Sometimes a client identified by ULA, 
sometimes with global address? Don't you need some correlation between 
them? Don't you mind this non-determinism in your ACLs, or IP based 
authorisation schemes?

4. Don't you mind the increased incoming transactions if your service has 
more then one address? Can you scale with the increased SYN state in your 
firewall or servers?

In general, the role of source address selection seems to me shifted a 
bit: reduce the number of attempts to successfully select addresses from 
the cross-products.

Best Regards,
 		Janos Mohacsi

---

From: Fred Baker <[email-masked]>
Date: Wed, 11 Nov 2009 07:52:29 +0900

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

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.

Caching implies some form of storage, which probably involves a kernel  
API, which I have not tried to prototype.

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 11 Nov 2009 11:06:01 +0100 (CET)

Dear All,

On Wed, 11 Nov 2009, Fred Baker wrote:

>> 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
> while (we have no open connection and some connection attempts in progress) {

Yes, very similar to the code advocated by KAME folks:
http://www.kame.net/newsletter/19980604/

But the devils in the details:

>    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

---

From: Brian Haberman <[email-masked]>
Date: Wed, 11 Nov 2009 07:54:30 -0500

Mohacsi Janos wrote:
> destination addresses, but no mechanism/logic in the codes to 
> successively try all the source addresses. Of course this can be made 
> hidden with some kernel implementation hacks, but this can be 
> non-deterministic.
> 
> Will it scale with multicast? Are you willing to increase the load of 
> the e.g. DNS servers?

In what situations would m>1 if the destination is multicast?

Regards,
Brian

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 11 Nov 2009 17:38:09 +0100 (CET)

On Wed, 11 Nov 2009, Brian Haberman wrote:

>> n(#source_address) X m(#destination_address) to the target node/group? Will 
>> it scale with multicast? Are you willing to increase the load of the e.g. 
>> DNS servers?
>

None. Sending with multiple source address can be still problematical. But 
in the case of UDP might be more interesting....

Best Regards,
 		Janos

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 18 Nov 2009 18:22:40 +0900

Fred,

On 2009/11/11, at 7:52, Fred Baker wrote:

>> cases, however it has some burden for implementation and  
>> operational point of view,
>
> 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.
>

There is a similar API in Winsock2 that tries multiple destination  
addresses,
but not every pair of destination and source address.

I guess that is because if you force to try all the pairs, it perfectly
ignores the address selection manner defined in RFC 3484, and thus,
it gives us not little impact.

Usually the source address that is attached to the outgoing interface
is selected as defined in RFC3484. However, the above mentioned
implementation does not follow this manner.

> application knows nothing about IP addresses (see UNSAF). But now I  
> am engaging in wishful thinking - that the socket interface would be  
> reasonably designed.
>
> Caching implies some form of storage, which probably involves a  
> kernel API, which I have not tried to prototype.

Caching sometimes work nicely, and sometimes do harm.
I'm not sure we can create perfect-in-every-environment
caching algorithm.

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

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 18 Nov 2009 18:43:28 +0900

Mohacsi,

> 	destroy socket }
> 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....
>
> 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.
> 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,

Another point is the complexity.
The complexity should involve difficulties in e.g. trouble shooting.

> 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 ? :)

---

From: Fred Baker <[email-masked]>
Date: Wed, 18 Nov 2009 18:46:17 +0900

> it gives us not little impact.

If they space them closely and run them in parallel, I guess I don't  
see the impact. Imagine you have five addresses and your peer has five  
addresses, so there are 25 pairs. Imagine you are spacing the SYNs 10  
ms apart. Imagine that the only pair that works is the last one you  
try. worst case, you find out 2.5 seconds plus one RTT which will  
work. If you cache the result, that only happens once, and if you  
don't, how does that compare to the current model in which you pick  
one address pair by some algorithm and wait for a TCP timeout before  
trying another?

---

From: Fred Baker <[email-masked]>
Date: Wed, 18 Nov 2009 18:50:04 +0900

> I'm not sure we can create perfect-in-every-environment

but you're convinced you can design an algorithm that consistently out- 
thinks the network design?

wow. I'm not that optimistic.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 18 Nov 2009 19:07:26 +0900

Regarding this way of try-and-error approach,

>                if result was a connection succeeding goto "connected"

Even when a host can find a successful working address pair,
it is not always a desirable address.

 From user's perspective, the pair found by chance might have
poorest bandwidth or latency.

 From site administrator's perspective, the pair might not be
the best with regard to user experience, or provisioning cost.
For example, he may want to unload the traffic through CGN,
tunnel, translator middleboxes.

I'm not arguing that this approach is good or bad, but that
this approach fulfills all that we needed.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 18 Nov 2009 19:22:46 +0900

On 2009/11/18, at 18:46, Fred Baker wrote:

> see the impact. Imagine you have five addresses and your peer has  
> five addresses, so there are 25 pairs. Imagine you are spacing the  
> SYNs 10 ms apart. Imagine that the only pair that works is the last  
> one you try. worst case, you find out 2.5 seconds plus one RTT which  
> will work. If you cache the result, that only happens once, and if  
> you don't, how does that compare to the current model in which you  
> pick one address pair by some algorithm and wait for a TCP timeout  
> before trying another?

If the packets go through, the servers are going to be flooded.
If the packets are filtered at ingress filterings, site administrators
are going to be flooded :)

Also, I guess too many error packets and following error messages that
have to be generated should not be desirable.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 18 Nov 2009 19:43:07 +0900

Fred,

On 2009/11/18, at 18:50, Fred Baker wrote:

> but you're convinced you can design an algorithm that consistently  
> out-thinks the network design?

IMO, we can not create always-perfect algorithm, and
we can not create always-worst algorithm that out-thinks the network  
design.

As I wrote in another e-mail,
rather than giving over everything to hosts, I think, giving hints for  
selecting
addresses should be reasonable, at least in some environments.

> wow. I'm not that optimistic.

I may be the least optimistic :)

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 18 Nov 2009 12:19:00 +0100 (CET)

> this approach fulfills all that we needed.

Agreed:
There is a need for address ordering mechanisms - preferably configurable 
by the site administrator (with some minimal default in the operating 
systems). This way you can have quicker the working 
address pair which reasonably aligned to the policy.
But we should not expect that this policy can solve all the problems 
outside of the site (or subnet, or host). The modest goal could be to 
reasonable suggest some source addresses order based on the policy. The 
destination address selection - no chance.
Policy definition in the routing currently done by routing protocols (most 
notably the BGP). We cannot expect all the host run BGP, however they 
might capable of doing that....

My point of view:
- There is need for policy for at least the source address selection
- The try_success_or_fail proposal of Fred Baker can help achieve better 
user experience, but as I mentioned in one of my previous message it 
requires changes how the applications are currently written.

Best Regards,
 		Janos Mohacsi

---

From: Fred Baker <[email-masked]>
Date: Wed, 18 Nov 2009 23:07:33 +0900

On Nov 18, 2009, at 7:43 PM, Arifumi Matsumoto wrote:

> As I wrote in another e-mail, rather than giving over everything to  
> hosts, I think, giving hints for selecting addresses should be  
> reasonable, at least in some environments.

I would very much favor having an icmp message that the network can  
return that says "pick an address in this prefix if possible". That is  
a discussion we have had before.

---

From: Scott Brim <[email-masked]>
Date: Wed, 18 Nov 2009 05:30:10 -0600

Brian E Carpenter allegedly wrote on 11/10/2009 9:54 AM:
> Fred,
> 
> Another approach to problem 3 is to extract REAP from SHIM6 and
> figure out how to use it to enhance address selection in practice.

... or any mechanism which tests src/dst address pairs.  Note that
data packets and control packets might traverse middleboxes
differently, another reason I like the toolkit of MIF and multipath
transport.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 18 Nov 2009 10:44:16 -0800

Fred Baker wrote:
> If they space them closely and run them in parallel, I guess I don't see 
> the impact. Imagine you have five addresses and your peer has five 
> addresses, so there are 25 pairs. Imagine you are spacing the SYNs 10 ms 
> apart. Imagine that the only pair that works is the last one you try. 

I'm a bit worried about this. If e.g. the host is 100ms (RTT) away and
10 combinations work, you may end up creating TCP state (and getting
syn-acks back) on the destination host for 10 connections, while you are
only going to use one.

I feel the delay between then should ideally be a bit longer than the
RTT. Which is fine if you only try a few combinations. Of course one
problem is that you don't really know what the RTT will be.

Stig

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 19 Nov 2009 17:29:43 +0900

Fred,

On 2009/11/18, at 23:07, Fred Baker wrote:

>> As I wrote in another e-mail, rather than giving over everything to hosts, I think, giving hints for selecting addresses should be reasonable, at least in some environments.
> 
> I would very much favor having an icmp message that the network can return that says "pick an address in this prefix if possible". That is a discussion we have had before.

And as I mentioned somewhere earlier,
icmp message based approach assumes try-and-error mechanism at host.
So, the difficulties mentioned here still remain, such as,
- the effect to applications. They may require rewriting.
- caching algorithm complexity.
- possible flooding to the server and the router.
- working address pair is not always desirable.
... and something I'm missing now.

---

From: Markku Savela <[email-masked]>
Date: Thu, 19 Nov 2009 12:26:31 +0200

> a discussion we have had before.

I really hate "try, fail, retry" logic. As I said earlier, we should
change so that host will send to a *default* router only using prefixes
specifically advertised by that router.

Router should be advertising only prefixes, which wouldn't trigger the
"icmp".

---

From: Narasimhan Venkataramaiah <[email-masked]>
Date: Thu, 19 Nov 2009 19:09:39 +0000

"There is a similar API in Winsock2 that tries multiple destination  
addresses,
but not every pair of destination and source address."

In windows 7 you get every pair possible with some restrictions and the ordering is based on improving the chances of success of successful connection completion - but it still attempts to adhere to 3484 to some extent.

Simha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Arifumi Matsumoto
Sent: Wednesday, November 18, 2009 1:23 AM
To: Fred Baker
Cc: [email-masked]; [email-masked]; IETF IPv6 Mailing List; Mohacsi Janos; [email-masked]
Subject: Re: Thoughts on address selection

Fred,

---

From: Scott Brim <[email-masked]>
Date: Thu, 19 Nov 2009 21:02:22 -0500

Stig Venaas allegedly wrote on 11/18/2009 1:44 PM:
>> ms apart. Imagine that the only pair that works is the last one you try. 
> 

I think the general sense is to try pairs until you get a few acceptable
ones, no more.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Nov 2009 15:16:18 +1300

> I think the general sense is to try pairs until you get a few acceptable

If you are polite, and use some sort of exponential backoff like
REAP does, the time to discover a working pair can be quite long,
unless your first or second guess is correct.

   Brian

---

From: Stig Venaas <[email-masked]>
Date: Thu, 19 Nov 2009 20:16:18 -0800

> I think the general sense is to try pairs until you get a few acceptable

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.

I would prefer the spacing to be >RTT so that you don't try a new
connection (with a new SYN) when the previous actually works.

Stig

---

From: Fred Baker <[email-masked]>
Date: Fri, 20 Nov 2009 17:05:39 +0900

> 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.

My second point is that assumptions like "the best path is through a  
prefix we both use" are silly. Analysis of a common traceroute will  
show that two random users tend to use two random ISPs. So a routing  
policy tat starts from "assume both users are using the same prefix"  
is a lost cause. Start from the assumption that you're looking for an  
address pair that works, and as a second choice, works well for a  
given ISP pair.

---

From: Fred Baker <[email-masked]>
Date: Fri, 20 Nov 2009 17:05:39 +0900

---

From: Fred Baker <[email-masked]>
Date: Fri, 20 Nov 2009 17:06:28 +0900

> unless your first or second guess is correct.

That's kind of the point of the caching angle...

---

From: Christian Huitema <[email-masked]>
Date: Fri, 20 Nov 2009 17:41:30 +0000

+1

The state of the art, there, is ICE. Any proposed standard has to at least match the robustness of ICE.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Nov 2009 08:27:45 +1300

> That's kind of the point of the caching angle...

Of course. (REAP is used as part of SHIM6, which continues using
the successful pair as long as possible.) But when a major failure
occurs, you have to assume that thousands of hosts may all start
reachability probes simultaneously, whatever they had previously
cached.

   Brian

---

From: Stig Venaas <[email-masked]>
Date: Fri, 20 Nov 2009 13:21:50 -0800

> 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.

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).

> prefix we both use" are silly. Analysis of a common traceroute will show 
> that two random users tend to use two random ISPs. So a routing policy 
> tat starts from "assume both users are using the same prefix" is a lost 
> cause. Start from the assumption that you're looking for an address pair 
> that works, and as a second choice, works well for a given ISP pair.

I agree. Well, if you happen to have the same prefix, then it makes
sense. Also, in say an enterprise, most of the communication is probably
internal where this makes sense.

But I agree that for most communication on the Internet, it is useless.
There are some other effects though (like preferring 2001 to reach 2001,
2002 to reach 2002 etc) but there may be better ways of achieving that.

Stig

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Nov 2009 11:02:24 +1300

...
> internal where this makes sense.

Sure, that was always clear to me - longest match only makes sense
when you have already eliminated pretty much every other criterion.
Longest match with other hosts under the same enterprise prefix is
probably the best example.

> 2002 to reach 2002 etc) but there may be better ways of achieving that.

I see the argument for 2002 but why 2001? It isn't special.

   Brian

---

From: Stig Venaas <[email-masked]>
Date: Fri, 20 Nov 2009 15:24:15 -0800

> I see the argument for 2002 but why 2001? It isn't special.

Ehm, you're right of course. Basically it might be good to treat
different types of addresses differently, but matching bits is not a
good way to do that.

Stig

---

From: Mohacsi Janos <[email-masked]>
Date: Sun, 22 Nov 2009 19:15:29 +0100 (CET)

On Fri, 20 Nov 2009, Stig Venaas wrote:

>> timeout, you can get a reasonble RTT for the SYN/SYN-ACK and prevent people 
>> from turning off IPv6 in the first place.
>

Ffor the decent pair first can we use the updated RFC 3484 source address 
selection.

> 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

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 25 Nov 2009 11:32:04 +0900

Brian,

> probably the best example.

The problem is that there is no universal rule to determine which address
is within his (enterprise) network. The prefix length /32, /48 matching is
not always beneficial.

This is another motivation for distributing site local policy to the user hosts.

Regards,
Arifumi Matsumoto