Subject: (ngtrans) source and destintion address selection algorithm

From: Alain Durand <[email-masked]>
Date: Wed, 13 Oct 1999 16:05:13 +0200 (CEST)

I'm writing this from another acount as we are currently
experiencing severe connectivity problems with the US..
I hope it will get through.

	- Alain

I'm copying this to IPng mailling list.

At 08:59 12/10/99 -0700, Erik Nordmark wrote:
>> The consequence of what you and Alain are saying is going to
>> be a host configuration option for "prefer 6to4" versus "prefer native"
>> in case that both are available. Do we really want another
>> config option? If yes, the words are easy to write.
>
>I personally don't think we need to configuration option, but
>others might think the order should be different.
>
>My order is:
>1. If both the source and destination have at least one native IPv6 address use
>   IPv6 native source and destination. 2. If both the source and destination
>have (at least one) 6to4 address use
>   6to4 source and destination addresses.
>3. If both the source and destination have (at least one) IPv4-compatible
>   addresses (remember that automatic tunneling stuff) use
>   IPv4-compatible source and destination addresses.
>
>In the above "native" means addresses that are not 6to4, not IPv4-compatible,
>and not IPv4-mapped.
>

I think we can generalized this order with the following algorithm to select
both source and destination address.

Lets define the precedence prec of an address as the following function
	prec(link local) = 10
	prec(site local) = 20
	prec(native-v6 global, non 6to4) = 30
	prec(native-V6 global, 6to4) = 35
	prec(IPv4 compatible) = 50

Note: those are suggested default value. They can be override manually
by configuration options if one does not like this specific order.

0. Consider the set of all possible source addresses
    and the set of all possible destination addresses,

1. Select destination address dst with the lowest precedence prec(dst)
 
2. If several destination addresses are still available, one may pick
    the first one returned by the DNS or use random selection.

3. Select src in this order:
	- one with the same precedence as prec(dst) 
	- if impossible, one with the lowest precedence
	  and prec(src) > prec(dst)
	- if impossible, one with the highest precedence

4. If several source addresses are still available, longest prefix match
  with the selected destination address or random selection may be used.

5. If the communication failed because the destination address
    is unreachable (scope too small for example), remove dst from
    the set of possible destination addresses and reiterate at step 1.

In the case of a simple application that select the first address returned by
the DNS and let the kernel fix the source address, step 3 & 4 of this algorithm
can be used by the kernel.

	- Alain.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 13 Oct 1999 16:03:49 -0700 (PDT)

> 1. Select destination address dst with the lowest precedence prec(dst)

Selecting the destination address without looking at source addresses
is not ideal.
For instance if the destination has a native and a 6to4 address and
the source has only a 6to4 address I think it is better to choose
6to4 for both source and destination.
Your algorithm will first pick the native destination and then pick the
best (in this case only) source.

Thus I think you need to look at (source, dest) pairs and 
prefer those pairs where the source and dest are "similar".

   Erik