From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
To: "Bjørn Mork" <bjorn@mork.no>
Cc: David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, yoshfuji@linux-ipv6.org
Subject: Re: [PATCH net-next] ip6_tunnel: ensure to always have a link local address
Date: Wed, 21 Aug 2013 12:25:19 +0200 [thread overview]
Message-ID: <5214958F.1080907@6wind.com> (raw)
In-Reply-To: <87haej76wz.fsf@nemi.mork.no>
Le 21/08/2013 11:02, Bjørn Mork a écrit :
> Nicolas Dichtel <nicolas.dichtel@6wind.com> writes:
>> Le 21/08/2013 08:48, David Miller a écrit :
>>
>>> 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.
>
> Are eth_random_addr() collisions really any different than interfaces
> having the same address for other reasons?
I would tend to say yes, it's different.
It's easy for an administrator to fix a configuration for a physical interface,
because it's statically configured and there is a limited number of interfaces.
For virtual interfaces, they can be dynamically created and destroyed by daemons
and we can have a lot of interfaces. Hence it could be hard to fix them. Trying
to avoid these errors at kernel level could be useful.
I've start to write a patch, and to test it I've just run a simple test which
generate 1 000 000 of random addresses. I've run it several times (maybe not
enough ;-)) and I never get a duplicated address...
next prev parent reply other threads:[~2013-08-21 10:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-20 10:16 [PATCH net-next] ip6_tunnel: ensure to always have a link local address Nicolas Dichtel
2013-08-21 6:48 ` David Miller
2013-08-21 7:40 ` Nicolas Dichtel
2013-08-21 9:02 ` Bjørn Mork
2013-08-21 10:25 ` Nicolas Dichtel [this message]
2013-08-21 11:37 ` Bjørn Mork
2013-08-21 12:11 ` Nicolas Dichtel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5214958F.1080907@6wind.com \
--to=nicolas.dichtel@6wind.com \
--cc=bjorn@mork.no \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.