From: Daniel Borkmann <dborkman@redhat.com>
To: davem@davemloft.net, netdev@vger.kernel.org,
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>,
Thomas Graf <tgraf@suug.ch>
Subject: Re: [PATCH net-next] net: ipv6: add tokenized interface identifier support
Date: Tue, 09 Apr 2013 00:27:09 +0200 [thread overview]
Message-ID: <5163443D.6050706@redhat.com> (raw)
In-Reply-To: <20130408222154.GA25696@order.stressinduktion.org>
On 04/09/2013 12:21 AM, Hannes Frederic Sowa wrote:
> Sorry, I was a bit busy and just had more time to look at your patch
> again. Perhaps you could look into my comments. (A new patch would be
> needed as it already landed in net-next).
Right, I'll prepare this follow-up patch(es) by tomorrow. Thanks for your
feedback Hannes!
> On Mon, Apr 08, 2013 at 04:01:30PM +0200, Daniel Borkmann wrote:
>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>> index a33b157..65d8139 100644
>> --- a/net/ipv6/addrconf.c
>> +++ b/net/ipv6/addrconf.c
>> @@ -422,6 +422,7 @@ static struct inet6_dev *ipv6_add_dev(struct net_device *dev)
>> ipv6_regen_rndid((unsigned long) ndev);
>> }
>> #endif
>> + memset(ndev->token.s6_addr, 0, sizeof(ndev->token.s6_addr));
>
> ndev is allocated with __GFP_ZERO so no need to clear it. Otherwise I would do
>
> ndev->token = in6addr_any;
>
> to make the check in addrconf_prefix_rcv more clear.
>
>> +static int inet6_set_iftoken(struct inet6_dev *idev, struct in6_addr *token)
>> +{
>> + struct in6_addr ll_addr;
>> + struct inet6_ifaddr *ifp;
>> + struct net_device *dev = idev->dev;
>> +
>> + if (token == NULL)
>> + return -EINVAL;
>> + if (ipv6_addr_any(token))
>> + return -EINVAL;
>> + if (dev->flags & (IFF_LOOPBACK | IFF_NOARP))
>> + return -EINVAL;
>> + if (idev->dead || !(idev->if_flags & IF_READY))
>> + return -EINVAL;
>> + if (!ipv6_accept_ra(idev))
>> + return -EINVAL;
>> + if (idev->cnf.rtr_solicits <= 0)
>> + return -EINVAL;
>
> IF_READY marks an interface which is already up. So we are not allowed to set
> a token on an interface which is down? I would drop this requirement, seems
> like a usability issue. ;)
>
>> +
>> + write_lock_bh(&idev->lock);
>> +
>> + BUILD_BUG_ON(sizeof(token->s6_addr) != 16);
>> + memcpy(idev->token.s6_addr + 8, token->s6_addr + 8, 8);
>> +
>> + write_unlock_bh(&idev->lock);
>> +
>
> {
>> + ipv6_get_lladdr(dev, &ll_addr, IFA_F_TENTATIVE | IFA_F_OPTIMISTIC);
>> + ndisc_send_rs(dev, &ll_addr, &in6addr_linklocal_allrouters);
>> +
>> + write_lock_bh(&idev->lock);
>> + idev->if_flags |= IF_RS_SENT;
> }
>
> This should then be only called if IF_READY is set. Otherwise normal ifup
> handling will send out the rs. If one day there is the possibility to add more
> than one token we would actually have to check the minimum solicitation
> intervals. I think this does not matter now.
>
>> +
>> + /* Well, that's kinda nasty ... */
>> + list_for_each_entry(ifp, &idev->addr_list, if_list) {
>> + spin_lock(&ifp->lock);
>> + if (ipv6_addr_src_scope(&ifp->addr) ==
>> + IPV6_ADDR_SCOPE_GLOBAL) {
>> + ifp->valid_lft = 0;
>> + ifp->prefered_lft = 0;
>> + }
>> + spin_unlock(&ifp->lock);
>> + }
>
> As I understand this logic it also does deprecate current statically configured ip
> addresses? Perhaps another per-inet6_ifaddr flag to mark the ip address as
> token configured and just clean these address.
>
> The flag would have to be set in addrconf_prefix_rcv if tokens are active.
>
> Thanks,
>
> Hannes
>
prev parent reply other threads:[~2013-04-08 22:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-08 14:01 [PATCH net-next] net: ipv6: add tokenized interface identifier support Daniel Borkmann
2013-04-08 20:57 ` David Miller
2013-04-08 22:21 ` Hannes Frederic Sowa
2013-04-08 22:27 ` Daniel Borkmann [this message]
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=5163443D.6050706@redhat.com \
--to=dborkman@redhat.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=tgraf@suug.ch \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).