tasklwIP - A Lightweight TCP/IP stack - Tasks: task #13455, Extend neighbhor discovery to...


You are not allowed to post comments on this tracker with your current authentication level.

task #13455: Extend neighbhor discovery to support 6LoWPAN better.

Submitter:  Krishna Shingala <kshingala>
Submitted:  Sat 24 Jan 2015 12:44:21 PM UTC
Category:  IPv6 Should Start On:  Sat 24 Jan 2015 12:00:00 AM UTC
Should be Finished on:  Tue 24 Feb 2015 12:00:00 AM UTC Priority:  5 - Normal
Status:  None Privacy:  Public
Assigned to:  None Percent Complete:  0%
Open/Closed:  Open Planned Release:  None
Effort:  0.00

Jump to the original submission

Tue 28 Jul 2015 03:18:07 PM UTC, comment #12: 

Hi, please note that this is for discussing a specific task: "Extend neighbhor discovery to support 6LoWPAN", this discussion should be on a separate thread on lwip-devel list.

Short answer: as always we'll do our best to support RFCs, but since this is a lightweight stack we may limit some functionality.

If you have any comments/suggestions/questions regarding 6LowPAN, please send them to the lwip-devel list, I'd be very happy to discuss more there.

Ivan Delamer <idelamer>
Group Member
Tue 28 Jul 2015 11:13:52 AM UTC, comment #11: 

Hi Ivan,

Could you please tell when the complete patch for 6LoWPAN will be ready?
Will RFC 4944 6282 6775 all be implemented? If not, could you please tell which features will be implemented and which will not?

Thanks a lot!

April M <april_m>
Fri 24 Jul 2015 03:05:52 PM UTC, comment #10: 

Netif goes below layer 3, and can have many functions. Adaptation and Layer 2 definitely fit there. You could split it more, but in a Light-weight system it fits well in a single layer.

I am posting a patch with the current 6LowPAN code, until it is ready for merging to head.

Ivan Delamer <idelamer>
Group Member
Fri 24 Jul 2015 06:44:53 AM UTC, comment #9: 

Hi Ivan,

Could you please tell me the status of 6LoWPAN support in LWIP? Does it work now? Can it be ported to support other media such as BLE?


April M <april_m>
Fri 24 Jul 2015 06:25:30 AM UTC, comment #8: 

6LoWPAN compresses/decompresses the IPv6 header and adds new features for ND. I don't know why it is placed below netif. In fact, it should be the adaption layer between layer 3 and layer 2, I think.

April M <april_m>
Mon 23 Feb 2015 07:26:44 PM UTC, comment #7: 

Just if anyone is interested in my opinion: I fully agree with Sylvain here that RAM/ROM size (and execution speed maybe) are more important than layer separation. There are other layer separation violations in lwIP and I haven't seen a problem with that, yet.

Implementing it as a netif is what I would do as well. Once it works and we know what it needs, we still can talk about upgrading it to a more substantial part of the stack.

Simon Goldschmidt <goldsimon>
Group administrator
Mon 23 Feb 2015 07:04:01 PM UTC, comment #6: 

I don't think strict layer isolation is a must-have in a tiny embedded stack like lwIP where the smallest code size and memory requirements is the main goal (after basic security about input of course). We know what we are doing everywhere and reading the whole source code to understand how it works is not out of the question.

Sylvain Rochet <gradator>
Group Member
Mon 23 Feb 2015 06:51:07 PM UTC, comment #5: 

hi Ivan!
ND is a layer-3 protocol, it provides a routing service. As ARP, it needs to provide layer-2 info.
For lwIP, 6LoWPAN rests at the link level (layer-2), although it is itself a layer-3 protocol; IPv6 is sort of tunneled in a layer-3 over layer-3 fashion.
A 6LoWPAN-capable netif sounds awkward to me. However, a 6LoWPAN-aware netif is probably the easiest way to do it.
netif_input() checks for 6LoWPAN (as it currently checks for IP) and calls the 6LoWPAN module! netif_output() is straight-thru.
This netif should be as simple as possible; ideally just looking as a netif to lwIP and binding to another netif providing for user redirection to serial or his 802.15.4/Bluetooth stack function calls.                                       
I would rather like all ND functions in a module that can be called by the IPv6 and 6LoWPAN modules. A netif or a 6LoWPAN module calling the IPv6 module functions sounds like layer violation to me. Anyway, just my opinion.
I can help with moving current stuff to a separate module or working with the tables, or whatever you suggest, just let me know.

Sergio R. Caprile <scaprile>
Mon 23 Feb 2015 04:16:23 PM UTC, comment #4: 

FYI I'm starting work on adding 6LowPAN support.

At the moment it is implemented as a netif.

I don't know if ND is a layer 3 protocol that is layer-2-aware, or viceversa. In practice, at least for LwIP, it is a mixed layer protocol.

I think that we need to follow a similar approach with 6LowPAN.

So far I've been able to run it with ND module as is, although I agree that some API to work with the router list would be beneficial. Integration of prefixes might require some hacking initially, especially as AFAIK there is no standard to assign prefixes for header compression. It seems to be ad hoc.

Ivan Delamer <idelamer>
Group Member
Sat 21 Feb 2015 08:35:01 PM UTC, comment #3: 

Well, to me processing level 3 information in a level 2 netif violates layer independence.
ND in a TCP/IP stack is a layer-3 issue, and 6LoWPAN is a layer-3 protocol, either:

  • the netif is a 6LoWPAN-capable netif or has 6LoWPAN knowledge (eew) or
  • 6LoWPAN is built-into the IPv6 module (eew, but not as disgusting) or
  • the 6LoWPAN implementation gets its info from the IPv6 module

Yes, tables will probably be duplicated, that depends on the capacity each module assigns for them (some info WILL be duplicated anyway, and its part of the module independence. The only options to not duplicate tables are:

  • 6LoWPAN is built-into the IPv6 module
  • an independent table/ND module accessed by both. (I'm intentionally ruling out globals)

Unfortunately both require 6LoWPAN to be "made by lwIP", and I guess the most likely solution to have this implemented is getting a third-party 6LoWPAN module to interface to. So, I still vote the same.
Anyway, either you or me submit a patch or follow what the developers consider to be the right choice.

Sergio R. Caprile <scaprile>
Fri 20 Feb 2015 04:32:55 PM UTC, comment #2: 

My best guess is that the info gathered by nd6/mld6 should be available, probably (desirable) by a callback function, so link-level protocols could use it. Some way to detect changes is also desirable.
(IMHO,) I don't really think the netif but the 6LoWPAN implementation should care about this. Point is: is there an open source 6LoWPAN implementation to provide hooks/callbacks to ?
Should this task turn to "write a 6LoWPAN module" ? (perhaps followed by a ROLL module ?)

Sergio R. Caprile <scaprile>
Wed 28 Jan 2015 07:37:45 PM UTC, comment #1: 

Could you provide a patch or at least and idea of how to implement this? That would greatly raise the chances of this being integrated.

Simon Goldschmidt <goldsimon>
Group administrator
Sat 24 Jan 2015 12:44:21 PM UTC, original submission:  

For use cases that implement a 6LoWPAN inerface, the context identifiers and prefixes distributed as a part of neighbor discovery procedures need to be provide to the 6LoWPAN layer to enable efficient compression and decompression of the IP header. This interface today does not exist in lwIP as lWIP does not accound for the 6LoWPAN. It will be extremly useful to enable notifying new prefixes and context identifier to the netif which can set these for the 6LoWPAN layer. Below is a short diagram to depict position of 6LoWPAN when using lwIP stack.

          |      ND6       |       MLD6       |   
          |            IPv6/ICMPv6            |
          |              netif                |
          |             6LoWPAN               |

Krishna Shingala <kshingala>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by april_m (Posted a comment)
  • -email is unavailable- added by gradator (Posted a comment)
  • -email is unavailable- added by idelamer (Posted a comment)
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by kshingala (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-03-24 goldsimon SummaryExtend neighbhor discovery ti support 6LoWPAN better. Extend neighbhor discovery to support 6LoWPAN better.

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code