Implementation of 6LoWPAN-ND [RFC 6775]

[MohamedSeliem]

The commit of this pull is to update the neighbor discovery files to implement the new optimized version of neighbor discovery which suggested by IETF in RFC 6775.
IPv6 Neighbor Discovery (ND) based on RFC4861 was developed primarily for wired traffic on the shared medium. Its heavily use the multicast transmission in periodic router-advertisement multicast addresses with router solicitation, neighbor solicitation, address resolution, and duplicate-address detection. While periodic multicast signaling and solicited-node multicast signaling are useful for network stability in the standard Ethernet-based shared network, the limited-lifetime, battery-operated devices in the IEEE 802.15.4 network conserve energy with less signaling and by sending broadcast messages only once in a while. That makes it inefficient and sometimes impractical for IPv6 over Low power Wireless Personal Area Networks (6LoWPAN).
(https://tools.ietf.org/html/rfc6775) optimizes multicast messages to uni-cast messages. It eliminates the need for relatively expensive address resolution by sending a neighbor registration option along with a neighbor solicitation; it supports sleepy nodes in the networks; and it optimizes the protocol constants while eliminating periodic router-advertisement messages.
You could find all details in the following paper http://eece.cu.edu.eg/~akhattab/files/ND.pdf

[MohamedSeliem]

@vsaw , i need your feedback and comments on this.
Thanks

[MohamedSeliem]

a previous discussion,was conducted in a old version of this PR, can be found here #1760

[vsaw]

The files core/net/ipv6/uip-6lowpan-nd6.c looks like a copy of core/net/ipv6/uip-nd6.c. I have not run a diff on these two files so I don't know what you have added. Still can you explain why you created a new file and not edited the existing core/net/ipv6/uip-nd6.c

The pull request is is still in a state that makes it very hard to review your contribution to ContikiOS. But I very much encourage you to keep working on it as it seems like it's just a matter of cleaning things up, especially since Travis seems to like your pull-request.

[MohamedSeliem]

@vsaw Thank you for your comment, but let me clear things a little bit here.

RFC 6775 optimize neighbor discovery protocol (RFC 4861) by adding some features to make it practical in LoWPAN networks.
RFC 6775 suggests 3 new optional headers which will be attached to ND messages, such as:
1- Address Registration Option (ARO): attached to (NS, NA)
2- 6LoWPAN context optional header (6CO):attached to (RA)
3- Authoritative border router (abro): attached to (RA)
each one of those options is used for specified purpose. for example, ARO used by host node to register its address with preferred default router, this will allow host nodes to sleep as specified in the RFC.

Besides, the RFC 6775 adds new constants and modified some other constants.

so, in my implementation i wanted to keep the old ND (4861) and the same time implement the optimized version (6775). consequently, core/net/ipv6/uip-6lowpan-nd6.c will be similar to core/net/ipv6/uip-nd6.c but with the extra added logic to implement the RFC 6775 features.

e.g. in uip-nd6-ns-output, you will find the processing of the ARO (new option header) and the modification to ND processes such as DAD, NUD, address resolution.
Conclusion, this implementation keeps the old ND and make the new implementation elective.

Finally, please let me know if you have any other comments, i'll really appreciate it.

Regards

[vsaw]

Hi @MohamedSeliem

thank you very much for taking the time to reply to my remarks. This makes your intentions clear to me and I agree that making the RFC 6775 optional and keeping the current RFC 4861 based implementation in place is a good thing!

I just wonder if this can be achieved in a way that is easier to maintain. I primarily wonder if it can be oden without introducing a separate C file, but instead by using the compile time configuration like UIP_CONF_IPV6_LOWPAN_ND inside the current uip-nd6.c. This could be very similar to how UIP_ND6_SEND_NA is used.

A clean implementation of that feature would also add it to the list of configurable options in core/contiki-default-conf.h.

[MohamedSeliem]

Nothing can not be achieved :)
however, it will be very complex to follow or to maintain. as RFC 6775 updates old ND, and the methodology of creating and processing ND messages are a little bit different.

e.g. NS, NA messages have new ARO option, and this option might be included or not in the message based on its purpose. merging such behavior with the old ND may be confusing.

another level of complexity, when we think about that in 6lowpan ND, we have 3 types of nodes:
6ln, 6lr, and 6lbr ; and each one have different in managing its data structure.

finally, in my opinion it will be very complex to combine the old and new ND in the same file , so that leaves us with only 2 options:
1- give up on old ND and start to rely on optimized ND (not reliable solution)
2- implement the new optimized ND keeping the old one for now, untill we ready to move forward towards a mature version of optimized 6lowpan-ND.

Thanks for your time

[vsaw]

@MohamedSeliem I see, in that case I propose to get a separate set of opinions on what should be done in order to achieve consensus.

@simonduq @adamdunkels Anyone care to weigh in?

[kelsayed]

I believe the best option would be to have a compilation flag or #define that will allow using the new optimized ND or the current one. Is this possible @MohamedSeliem?

[MohamedSeliem]

@kelsayed yes of course, in this implementation, we define UIP_CONF_IPV6_LOWPAN_ND flag.
By setting this flag to 1, it will enable the optimized ND functions, while setting it to zero will keep the basic ND.

[MohamedSeliem]

@yatch i need your feedback and comments on this.
Thanks

[yatch]

@MohamedSeliem OK; let me leave some (general) comments:

• It'd be nice if you could explain concisely in the pull-request message which features of RFC 6775 are supported. You can edit the pull-request message anytime you want.
• Can you provide any sample simulation file to see how your code work? It would be helpful for others to understand the PR.
• You might want to check the Contiki code style written in https://github.com/contiki-os/contiki/wiki/Code-Contributions . The other contents in the wiki page are also useful.

[sumantgupta1984]

Please provide permission to pull the code

[MohamedSeliem]

@sumantgupta1984 you can get the code by forking a clone from this link:

https://github.com/MohamedSeliem/contiki

[tuvok]

Hi guys, what is the current status here?
Any plans to merge this?

[kelsayed]

@MohamedSeliem Could you apply the recommendation of @yatch to have the PR moving forward.

[tuvok]

I just noticed there is a bug in uip-6lowpan-nd6.h here, it has these definitions:
#define UIP_ND6_OPT_DNSSL 31 #define UIP_ND6_OPT_ARO 32 #define UIP_ND6_OPT_6CO 33 #define UIP_ND6_OPT_ABRO 34

the values starting with ARO are off by one:
https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5

[MohamedSeliem]

@kelsayed Sure I will do, However, we still need Contiki member to weigh in for reviewing process.
@simonduq @nvt @adamdunkels anyone planning to move forward to with optimized ND 6775 implementation?

@tuvok Thank you for reporting this, please feel free to contact me if you found any other bugs to fix.

[simonduq]

@MohamedSeliem I'm no longer active here sorry, moved on to Contiki-NG.

[tuvok]

@MohamedSeliem
The ARO option seems to be created incorrectly too, the last line of the function:
memcpy(&(((uip_nd6_opt_aro*)aro)->eui64), uip_lladdr, UIP_LLADDR_LEN);
just copies the lladdr, but the eui64 is 8 bytes not 6, different format:
http://packetlife.net/blog/2008/aug/4/eui-64-ipv6/