From: Alexander Aring <alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: linux-wpan-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
mcr-SWp7JaYWvAQV+D8aMU/kSg@public.gmane.org,
lukasz.duda-hR+23Fw+YnFSHonuZl5R5Q@public.gmane.org,
martin.gergeleit-6wGqcYweBVc@public.gmane.org,
Alexander Aring
<alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: [RFCv4 bluetooth-next 0/2] 6lowpan: 6co and stateful compression support
Date: Mon, 14 Dec 2015 15:00:52 +0100 [thread overview]
Message-ID: <1450101654-22633-1-git-send-email-alex.aring@gmail.com> (raw)
Hi,
this patch series adds stateful compression support and add 6co option as a new
userspace option for processing RA messages inside userspace.
I am not sure if "6CO" handling inside userspace is the best option here.
I will send also "radvd" patches which introduce a very "basic" support for
processing(non 6LBR)/manage(6LBR) 6CO option fields. These patches doesn't
support lifetime handling of contexts. There exists the question as well if
we should handle the lifetime handling inside userspace or kernelspace.
I am currently follow this approach:
If we doesn't need it inside the kernelspace, then we should handle it in
userspace.
It's difficult to figure out if we really can it handle inside userspace only.
RFC6775 describes some different roles inside the network:
- 6LN (6LoWPAN Node)
- 6LR (Router inside 6LoWPAN network)
- 6LBR ($IP_NETWORK <-> 6LoWPAN network)
Processing ICMPv6 (RA/RS, NA/NS) messages may be different for each role. I
currently have not the full overlook inside RFC6775 and sometimes (as example
of ABRO field, another Option-Field for 6LoWPAN) says:
8.1.3. Routers Processing Router Advertisements
Note: (I suppose this is for 6LR only!)
If a received RA does not contain an ABRO, then the RA MUST be silently
ignored.
---
For my knowledge such handling need to be inside kernelspace. This is filter
functionality only, processing can be handled inside userspace (which needs ABRO
also as userspace option at first), but then the kernel need to know which "role
(6LN, 6LR, 6LBR)" the interface has.
- Alex
changes since v4:
- remove patches for adding debugfs which are already upstream.
- add "ipv6: add 6co as icmpv6 userspace option"
- fix transmit check on (cid) instead (sci || dci) for adding CID inline
data. If CID is zero it will be compressed.
- remove "dci_table, sci_table, mcast_table" we have "ctx_table" only.
- Change enabled with "u32 flags" since we need more information than
"enabled" only. We handle also "compression flag" now.
Alexander Aring (2):
6lowpan: iphc: add support for stateful compression
ipv6: add 6co as icmpv6 userspace option
include/net/6lowpan.h | 31 ++++
include/net/ndisc.h | 1 +
net/6lowpan/core.c | 6 +-
net/6lowpan/debugfs.c | 97 ++++++++++++
net/6lowpan/iphc.c | 420 +++++++++++++++++++++++++++++++++++++++++++-------
net/ipv6/ndisc.c | 3 +-
6 files changed, 499 insertions(+), 59 deletions(-)
--
2.6.1
next reply other threads:[~2015-12-14 14:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-14 14:00 Alexander Aring [this message]
2015-12-14 14:00 ` [RFCv4 bluetooth-next 1/2] 6lowpan: iphc: add support for stateful compression Alexander Aring
[not found] ` <1450101654-22633-2-git-send-email-alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-12-15 10:29 ` Duda, Lukasz
[not found] ` <AB80DA35A7B64E4E98291794926897D9011B97546F-SLoVk1VVLw+l5Akvao6LmQ@public.gmane.org>
2015-12-15 11:08 ` Alexander Aring
2015-12-17 12:26 ` Duda, Lukasz
2015-12-17 13:41 ` Alexander Aring
2015-12-14 14:00 ` [RFCv4 bluetooth-next 2/2] ipv6: add 6co as icmpv6 userspace option Alexander Aring
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=1450101654-22633-1-git-send-email-alex.aring@gmail.com \
--to=alex.aring-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
--cc=linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-wpan-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lukasz.duda-hR+23Fw+YnFSHonuZl5R5Q@public.gmane.org \
--cc=martin.gergeleit-6wGqcYweBVc@public.gmane.org \
--cc=mcr-SWp7JaYWvAQV+D8aMU/kSg@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.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).