IPv6 over IEEE 802.15.4 aka 6LoWPAN - Neighbor discovery issue

IPv6 over IEEE 802.15.4 aka 6LoWPAN - Neighbor discovery issue

[Alexander Aring]

Hi,

The IEEE 802.15.4 is a WPAN PHY/MAC layer. On top of this Layer we can use
6LoWPAN as upper layer. 6LoWPAN is an adaption layer for IPv6 over IEEE
802.15.4.

Because 6LoWPAN is an adaption we should not change anything in net/ipv6, but
there exist an issue with the 802.15.4 mac addresses and neighbor discovery.

The 802.15.4 has two kinds of mac addresses with a different length.

These are:

Short addresses are 16 bit long and contain some special addresses like
0xffff (broadcast) and 0xfffe (difficult to explain, it's simple not
available).

Extended addresses are 64 bit long and have no special address ranges. It's an
EUI-64 which should not be 00..00 or ff..ff [0].                           
                                                                           
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.

We need this information at two places. The first is the daddr pointer of
create callback of header_ops. The other place is creating of ICMPv6 neighbor
discovery ICMPv6 messages.
The source/target link-layer addresses headers for extended and short addresses should
follow description of [1].            
                                      
The second place is:                  
In the create callback of header_ops, we replace the IPv6 header with the 6LoWPAN
header, that's why we need this information in the create callback also. We need this
information also for generating MAC header. For the sending part.
                                                           
                                                           
Furthermore there exists a neighbor discovery "optimization" which do a separate
handling for extended and short addresses also. I don't take a closer look but
it introduce new option types [3] and maybe we can do all 6LoWPAN stuff there.
                                                                       
For now, we don't want to use rfc6775 and simple use the normal IPv6 neighbor
discovery. This need nd messages like [1].                             

I currently searching for a good solution that the neighbor discovery cache can
handle short and extended addresses WITHOUT touching net/ipv6 branch. 


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 I need help and I need a solution which is also acceptable for mainline.

- Alex

[0] http://standards.ieee.org/develop/regauth/tut/eui64.pdf
[1] http://tools.ietf.org/html/rfc4944#section-8
[2] http://tools.ietf.org/html/rfc6775
[3] http://tools.ietf.org/html/rfc6775#section-12

Re: IPv6 over IEEE 802.15.4 aka 6LoWPAN - Neighbor discovery issue

[YOSHIFUJI Hideaki/吉藤英明]

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.

> 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.
Please consider using it for L2 private data, if you need L2-speicic extra
information per NCE.

Regards,

--yoshfuji

Re: IPv6 over IEEE 802.15.4 aka 6LoWPAN - Neighbor discovery issue

[Alexander Aring]

Hi Varka,

On Wed, Aug 06, 2014 at 10:41:46AM +0530, Varka Bhadram wrote:
> The 6LoWPAN Neighbor Discovery protocol (RFC6775) is an optimized version of the
> standard IPv6 Neighbor Discovery protocol. 6LoWPAN-ND  uses the same standard
> ND (RFC4861) messages (ICMPv6) with some additional options (ARO , 6CO and ABRO).
> Two new messages (DAR and DAC) have been added to consider the support of Neighbor Discovery
> for bootstrapping, header compression, mobility, fault tolerance, etc.
> 
> We implemented 6LoWPAN-ND for linux kernel 3.12, which handles ARO option
> in NS(Neighbour Solicitation) and sends NA (Neighbour Advertisement) with
> updated ARO option as per RFC6775. We may send you the patches for this implementation.
> And we implemented handling of DAR and DAC.
>

Did you have solve the issue between short and extended address? For
RFC6775 we need also context based address compression, we don't support
this mainline right now.

If yes then you can send me these patches.

> Handing of RS (Router Solicitation) and RA (Router Advertisement) will take care
> by radvd (Router Advertisement Daemon) in Linux. We added the ABRO and 6CO option
> support in radvd. You can find the implementation in [1].
> 
> 
> [1]: https://github.com/reubenhwk/radvd/blob/master/send.c#L536
> 

I see you use the ContextID there, then you need the CID value from
6LoWPAN header there. I am very interest for patches which introduce
context based address compression and make it also available in
userspace to handle the ContextID with radvd.

Thanks.

- Alex

Re: IPv6 over IEEE 802.15.4 aka 6LoWPAN - Neighbor discovery issue

[Varka Bhadram]

On 08/06/2014 12:40 PM, Alexander Aring wrote:
> Hi Varka,
>
> On Wed, Aug 06, 2014 at 10:41:46AM +0530, Varka Bhadram wrote:
>> The 6LoWPAN Neighbor Discovery protocol (RFC6775) is an optimized version of the
>> standard IPv6 Neighbor Discovery protocol. 6LoWPAN-ND  uses the same standard
>> ND (RFC4861) messages (ICMPv6) with some additional options (ARO , 6CO and ABRO).
>> Two new messages (DAR and DAC) have been added to consider the support of Neighbor Discovery
>> for bootstrapping, header compression, mobility, fault tolerance, etc.
>>
>> We implemented 6LoWPAN-ND for linux kernel 3.12, which handles ARO option
>> in NS(Neighbour Solicitation) and sends NA (Neighbour Advertisement) with
>> updated ARO option as per RFC6775. We may send you the patches for this implementation.
>> And we implemented handling of DAR and DAC.
>>
> Did you have solve the issue between short and extended address? For
> RFC6775 we need also context based address compression, we don't support
> this mainline right now.

We only supported extended address. We did not include the context based
address compression.

>
> If yes then you can send me these patches.
>
>> Handing of RS (Router Solicitation) and RA (Router Advertisement) will take care
>> by radvd (Router Advertisement Daemon) in Linux. We added the ABRO and 6CO option
>> support in radvd. You can find the implementation in [1].
>>
>>
>> [1]: https://github.com/reubenhwk/radvd/blob/master/send.c#L536
>>
> I see you use the ContextID there, then you need the CID value from
> 6LoWPAN header there. I am very interest for patches which introduce
> context based address compression and make it also available in
> userspace to handle the ContextID with radvd.

Right now we providing the contextID from user space through radvd.conf.

Context based implementation is not supported so we are only using the
context identifier from user space.

> Thanks.
>
> - Alex

-- 
Regards,
Varka Bhadram.

Re: IPv6 over IEEE 802.15.4 aka 6LoWPAN - Neighbor discovery issue

[Alexander Aring]

On Wed, Aug 06, 2014 at 12:45:27PM +0530, Varka Bhadram wrote:
> On 08/06/2014 12:40 PM, Alexander Aring wrote:
> >Hi Varka,
> >
> >On Wed, Aug 06, 2014 at 10:41:46AM +0530, Varka Bhadram wrote:
> >>The 6LoWPAN Neighbor Discovery protocol (RFC6775) is an optimized version of the
> >>standard IPv6 Neighbor Discovery protocol. 6LoWPAN-ND  uses the same standard
> >>ND (RFC4861) messages (ICMPv6) with some additional options (ARO , 6CO and ABRO).
> >>Two new messages (DAR and DAC) have been added to consider the support of Neighbor Discovery
> >>for bootstrapping, header compression, mobility, fault tolerance, etc.
> >>
> >>We implemented 6LoWPAN-ND for linux kernel 3.12, which handles ARO option
> >>in NS(Neighbour Solicitation) and sends NA (Neighbour Advertisement) with
> >>updated ARO option as per RFC6775. We may send you the patches for this implementation.
> >>And we implemented handling of DAR and DAC.
> >>
> >Did you have solve the issue between short and extended address? For
> >RFC6775 we need also context based address compression, we don't support
> >this mainline right now.
> 
> We only supported extended address. We did not include the context based
> address compression.
> 

ok.

> >
> >If yes then you can send me these patches.
> >
> >>Handing of RS (Router Solicitation) and RA (Router Advertisement) will take care
> >>by radvd (Router Advertisement Daemon) in Linux. We added the ABRO and 6CO option
> >>support in radvd. You can find the implementation in [1].
> >>
> >>
> >>[1]: https://github.com/reubenhwk/radvd/blob/master/send.c#L536
> >>
> >I see you use the ContextID there, then you need the CID value from
> >6LoWPAN header there. I am very interest for patches which introduce
> >context based address compression and make it also available in
> >userspace to handle the ContextID with radvd.
> 
> Right now we providing the contextID from user space through radvd.conf.
> 
> Context based implementation is not supported so we are only using the
> context identifier from user space.
>

A static CID value in radvd.conf? Sorry, I don't know how this can be
working without very limitations of use.



Nevertheless, I want to find some solution to handle short and extended
addresses in neighbor discovery to get something working which should
already work in the current state. After that we can care about RFC6775.

This is more a "bugfix" and RFC6775 a new feature. Really, I have no
idea what happens if we get a short address 6LoWPAN nd message packet and
I got nightmares because this.

- Alex

Re: IPv6 over IEEE 802.15.4 aka 6LoWPAN - Neighbor discovery issue

[Varka Bhadram]

On 08/06/2014 01:17 PM, Alexander Aring wrote:
>>>> Handing of RS (Router Solicitation) and RA (Router Advertisement) will take care
>>>> by radvd (Router Advertisement Daemon) in Linux. We added the ABRO and 6CO option
>>>> support in radvd. You can find the implementation in [1].
>>>>
>>>>
>>>> [1]: https://github.com/reubenhwk/radvd/blob/master/send.c#L536
>>>>
>>> I see you use the ContextID there, then you need the CID value from
>>> 6LoWPAN header there. I am very interest for patches which introduce
>>> context based address compression and make it also available in
>>> userspace to handle the ContextID with radvd.
>> Right now we providing the contextID from user space through radvd.conf.
>>
>> Context based implementation is not supported so we are only using the
>> context identifier from user space.
>>
> A static CID value in radvd.conf? Sorry, I don't know how this can be
> working without very limitations of use.

Actually we have to get the CID from the 6LoWPAN packet and we have to
update or store the CID based information into a separate table.

For each and every CID we are going to have the its own info.

If CID is changed we have to increment the *version* field in ABRO option
and sends RA message. This support is future work if we have the CID based
compression.


-- 
Regards,
Varka Bhadram.

Re: IPv6 over IEEE 802.15.4 aka 6LoWPAN - Neighbor discovery issue

[Alexander Aring]

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

Re: IPv6 over IEEE 802.15.4 aka 6LoWPAN - Neighbor discovery issue

[Alexander Aring]

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 linux-wpan" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IPv6 over IEEE 802.15.4 aka 6LoWPAN - Neighbor discovery issue

[David Miller]

From: Alexander Aring <alex.aring@gmail.com>
Date: Wed, 6 Aug 2014 12:36:44 +0200

> I can't also use ARPHRD_6LOWPAN otherwise bluetooth will do these
> 802.15.4 specific things in neighbor discovery.

Have the ndisc handlers look at what the underlying device actually
is.