Re: [PATCH net-next] ip6_tunnel: ensure to always have a link local address

[Nicolas Dichtel <nicolas.dichtel@6wind.com>]

Le 21/08/2013 08:48, David Miller a écrit :
> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Date: Tue, 20 Aug 2013 12:16:06 +0200
>
>> When an Xin6 tunnel is set up, we check other netdevices to inherit the link-
>> local address. If none is available, the interface will not have any link-local
>> address. RFC4862 expects that each interface has a link local address.
>>
>> Now than this kind of tunnels supports x-netns, it's easy to fall in this case
>> (by creating the tunnel in a netns where ethernet interfaces stand and then
>> moving it to a other netns where no ethernet interface is available).
>>
>> RFC4291, Appendix A suggests two methods: the first is the one currently
>> implemented, the second is to generate a unique identifier, so that we can
>> always generate the link-local address. Let's use eth_random_addr() to generate
>> this interface indentifier.
>>
>> I remove completly the previous method, hence for the whole life of the
>> interface, the link-local address remains the same (previously, it depends on
>> which ethernet interfaces were up when the tunnel interface was set up).
>>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>
> Applied, but this brings up an issue I keep noticing.
>
> We talk about eth_random_addr() and "uniqueness" together all the
> time, but the former never implies the latter.
>
> And we're going to run into situations where any conflicts generated
> by this random address generater will cause reall failures.
>
> Therefore we'll have to create a system to prevent them.  Probably
> using some simple table that keeps track of the addresses we've
> generated.
>
Ok, I will look at this.