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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx>
> Cc: Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx>
> Cc: James Morris <jmorris@xxxxxxxxx>
> Cc: Hideaki YOSHIFUJI <yoshfuji@xxxxxxxxxxxxxx>
> Cc: Patrick McHardy <kaber@xxxxxxxxx>
> 
> 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

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



[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux