netdev - Re: [PATCHv2 bluetooth-next 00/10] 6lowpan: introduce basic 6lowpan-nd

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]
Date:	Mon, 2 May 2016 10:25:00 -0700
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Alexander Aring <aar@...gutronix.de>,
	"David S. Miller" <davem@...emloft.net>
Cc:	linux-wpan@...r.kernel.org, kernel@...gutronix.de,
	Jukka Rissanen <jukka.rissanen@...ux.intel.com>,
	hannes@...essinduktion.org,
	Stefan Schmidt <stefan@....samsung.com>, mcr@...delman.ca,
	Werner Almesberger <werner@...esberger.net>,
	Linux Bluetooth <linux-bluetooth@...r.kernel.org>,
	Network Development <netdev@...r.kernel.org>,
	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	James Morris <jmorris@...ei.org>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
	Patrick McHardy <kaber@...sh.net>
Subject: Re: [PATCHv2 bluetooth-next 00/10] 6lowpan: introduce basic 6lowpan-nd

Hi Dave,

> this patch series introduces a layer for IPv6 neighbour discovery. At first
> it introduce the "ndisc_ops" to run a different handling for recv/send of
> NA/NS messages. The use case for such ndisc operation is RFC 6775 [0].
> Which describes a different neighbour discovery handling for 6LoWPAN networks.
> 
> I didn't implement RFC 6775 in this patch series, but introduce callback
> structure for replace different functions in ndisc implementation might be
> the right direction.
> 
> Another use case would be RFC 7400 [1] which describes a new option field to
> getting capabilities of 6LoWPAN next header compression methods.
> 
> What I implemented is a necessary functionality to handle short address for
> 802.15.4 6LoWPAN networks. The L2-Layer "802.15.4" can have two different
> link-layer addresses which can be used mixed at the same time inside 802.15.4
> networks. To deal with such behaviour in ndisc, it is defined at RFC 4944 [2].
> The bad news is, that I saw different handling of such handling. What Linux
> will do is to add two source/target address information option fields, each
> with different length, if short address is valid (can also not be given).
> Example:
> 
> - WPAN interface address settings
> - extended addr (must always be there)
> - short addr (0xfffe or 0xffff -> invalid)
> 
> Will add an extended addr to source/target address information option field.
> If short addr is in some valid range, then both address will be added to
> the option fields. Indicated are these different address types by the length
> field (extended -> length=2, short -> length=1), according to [1].
> 
> The tested 6LoWPAN implementation (RIOT-OS) allows only one source/target
> option field which is short XOR extended, otherwise it will be dropped.
> There is some lack of information there [2] and I don't know how do deal with
> it right, maybe we need to update the implementation there if it's really
> wrong.
> 
> To save such information for each neighbour we use the already implemented
> neighbour private data which some casting strategy for 6LoWPAN and 6LoWPAN
> link-layer specific data e.g. 802.15.4 short address handling.
> 
> Additional I implemented to add 6CO to the is_useropt callback in case of
> 6LoWPAN interface. The 6CO option will currently parsed in userspace which
> are placed in RA-Messages.
> 
> The ndisc_ops are not finished yet, of course we need handling for RS messages
> to place the 802.15.4 short address there as well and then also processing
> of RA messages for the 802.15.4 SLLAO option field.
> 
> - Alex
> 
> [0] https://tools.ietf.org/html/rfc6775
> [1] https://tools.ietf.org/html/rfc7400#section-3.3
> [2] https://tools.ietf.org/html/rfc4944#section-8
> 
> Cc: David S. Miller <davem@...emloft.net>
> Cc: Alexey Kuznetsov <kuznet@....inr.ac.ru>
> Cc: James Morris <jmorris@...ei.org>
> Cc: Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
> Cc: Patrick McHardy <kaber@...sh.net>
> 
> changes since v2:
> - replace #ifdef CONFIG_IPV6 to #if IS_ENABLED(...)
> - replace #ifdef CONFIG_IEEE802154... to #if IS_ENABLED(...)
> - add more #if IS_ENABLED(CONFIG_IPV6) in ndisc.h
> 
> Alexander Aring (10):
>  6lowpan: add private neighbour data
>  6lowpan: add 802.15.4 short addr slaac
>  6lowpan: remove ipv6 module request
>  ndisc: add addr_len parameter to ndisc_opt_addr_space
>  ndisc: add addr_len parameter to ndisc_opt_addr_data
>  ndisc: add addr_len parameter to ndisc_fill_addr_option
>  ipv6: introduce neighbour discovery ops
>  ipv6: export ndisc functions
>  6lowpan: introduce 6lowpan-nd
>  6lowpan: add support for 802.15.4 short addr handling
> 
> include/linux/netdevice.h     |   6 +-
> include/net/6lowpan.h         |  24 ++
> include/net/addrconf.h        |   3 +
> include/net/ndisc.h           | 124 ++++++++-
> net/6lowpan/6lowpan_i.h       |   2 +
> net/6lowpan/Makefile          |   2 +-
> net/6lowpan/core.c            |  50 +++-
> net/6lowpan/iphc.c            | 167 +++++++++--
> net/6lowpan/ndisc.c           | 633 ++++++++++++++++++++++++++++++++++++++++++
> net/bluetooth/6lowpan.c       |   2 +
> net/ieee802154/6lowpan/core.c |  12 +
> net/ieee802154/6lowpan/tx.c   | 107 ++++---
> net/ipv6/addrconf.c           |   7 +-
> net/ipv6/ndisc.c              | 132 +++++----
> net/ipv6/route.c              |   4 +-
> 15 files changed, 1117 insertions(+), 158 deletions(-)
> create mode 100644 net/6lowpan/ndisc.c

is there a chance that we get input into this patch set? I wonder also if it would be acceptable to take this through bluetooth-next or should it better go straight into net-next?

Regards

Marcel