netdev - Re: IPv6 over IEEE 802.15.4 aka 6LoWPAN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140806103642.GA32302@omega>
Date:	Wed, 6 Aug 2014 12:36:44 +0200
From:	Alexander Aring <alex.aring@...il.com>
To:	YOSHIFUJI Hideaki/吉藤英明 
	<hideaki.yoshifuji@...aclelinux.com>
Cc:	davem@...emloft.net, kuznet@....inr.ac.ru, jmorris@...ei.org,
	yoshfuji@...ux-ipv6.org, kaber@...sh.net, netdev@...r.kernel.org,
	linux-wpan@...r.kernel.org
Subject: Re: IPv6 over IEEE 802.15.4 aka 6LoWPAN - Neighbor discovery issue

Hi,

thanks for your reply.

On Wed, Aug 06, 2014 at 09:40:28AM +0900, YOSHIFUJI Hideaki/吉藤英明 wrote:
> Hi,
> 
> Alexander Aring wrote:
> >There exist no mapping between extended and short addresses. The global problem
> >that the neighbor discovery cache handle the address length with a static addr_len
> >value from net_device, this value should not be changed during runtime.
> >
> >
> >To handle 6LoWPAN over IEEE 802.15.4 correctly we need to indicate that the neighbor
> >discovery stores an extended or short address.
> :
> >My idea:
> >
> >Let addr_len to extended_address_length + 1. In the last byte we have a bit which
> >indicate that is it a short address. If this bit isn't set we have an extended
> >address.
> >
> >If we do that, we need some conversions about generating the ICMPv6 messages according
> >to [1]. We can solve that with some hooks in net/ipv6/ndisc.c like the ndisc_mc_map
> >function for mapping mac multicast addresses.
> >
> >Another idea to avoid hooks in net/ipv6/ndisc.c  is to parse and rebuild the ICMPv6
> >header while replacing IPv6 with the 6LoWPAN header.
> 
> Please avoid magling icmpv6/ipv6 bits as much as possible.
> 

Okay.

> >Please I need help and I need a solution which is also acceptable for mainline.
> 
> We can have L2-specific private data per NCE, and 6lowpan uses ARPHRD_IEEE802154.

First I need to clarify that we have two 6LoWPAN implementations, one
for 802.15.4 and the other one for bluetooth. Each have some generic
code inside of net/6lowpan.

What we need for this neighbor discovery issue is 802.15.4 specific only.
I think bluetooth 6LoWPAN can deal with the normal behaviour.

That a 6lowpan device for ieee802.15.4 use ARPHRD_IEEE802154 is wrong,
we need something like ARPHRD_IEEE802154_6LOWPAN, but this is another problem.

I will introduce it, currently this is most wrong because wireshark
thinks there are 802.15.4 frames but on this interface should only plain
IPv6 and upper layers visible. But this is out of scope of this issue.
I can't also use ARPHRD_6LOWPAN otherwise bluetooth will do these
802.15.4 specific things in neighbor discovery.

> Please consider using it for L2 private data, if you need L2-speicic extra
> information per NCE.

okay, I will try to implement something which allow this and make
_small_ changes according ARPHRD_... during runtime. I will send it as RFC
and we can discuss about that.

I will try to have a less of evaluating dev->type much as possible.

- Alex
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html