Hosts with multiple interfaces - applicability statement ?

[Sébastien Barré <sebastien.barre@uclouvain.be>]

Hi,

Thanks to experiments made by John Ronan, we noticed that a host with 
multiple interfaces was not (always) able to find a working path after a 
failure, even if such a path did exist.

I finally realized that the problem is simply the destination-address 
based routing of the default configurations. With the current stacks (I 
guess this is true for any current operating system), routing is 
completely based on the destination address. We can even have the 
following scenario :
- eth1 has address ADDR_1
- eth2 has address ADDR_2
- The default route is through eth2
- REAP sets the source address of its probe to ADDR_1
- But the packet goes out through eth2 since this is the default route.

The best solution that comes to my mind is to rely on the fact that PA 
addressing requires source address based routing somewhere in the 
network. But if the point where the path can be chosen is in the host 
(through multiple interfaces), then the host must itself perform source 
address based routing.

The solution that worked for the example above and seems clean enough 
was to configure multiple routing tables, one per interface. Then adding 
rules that direct packets with source address ADDR_1 to the table of 
eth1, and so on. An additional default routing table is still necessary 
so that packets with the unspecified source address can still get 
RFC3484 source address selection from the kernel.

Thus there is a solution, but I am afraid that the end user won't 
perform the above configuration, and could complain about misworking 
multihoming functions. Moreover I think that the Shim6 software should 
not make this config on behalf of the user, since this will break in 
case special policy routing configurations are already there.

I think that maybe guidelines for this case should be added to the 
applicability statement draft, so that users are aware of the problem. 
The best would be of course to find something that would be both 
flexible and without configuration from the user. Maybe someone on this 
mailing list has an idea ?

regards,

Sébastien.

--
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium
http://inl.info.ucl.ac.be/sbarre