[6lo] Questions - Implement Fragment Forwarding using VRB

[Christian Hopfner <[e-mail]>]

Hey all,

I do have some questions related to fragment forwarding or fragmentation in general and I hope I can get some help here.

Right now I'm not sure what values I have to set for DATAGRAM_SIZE and DATAGRAM_OFFSET.

As per my understanding at the LBR - DATAGRAM_SIZE has to be the size of the incoming IPv6 packet before transforming it into a 6lowpan packet. For instance if I do a ping from a local address in the same subnet as my wireless network is:
ABCD::1 to ABCD::EUI64 using linux ping6 command with option -s 100
That will result in which packet size 100byte payload, 8byte udp header, 16byte src, dst address each -> total 140byte ?

Here I'm not sure since I do have an implementation for traditional hop-by-hop forwarding which differs in some points from rfc4944 in my eyes.

Following wireshark snippet shows the use case I have tested so far, where 1f2e is the dagroot and fd44 first hop node. Here datagram size is 138byte not 140byte

[cid:image001.png@01D51D07.6393E0F0]

The next thing what I'm not sure is, where do I start to count my payload bytes I'm referring with DATAGRAM_OFFSET in frag n packets. For the following packets it seems to be quite easy since they only contain FRAGN Header and the payload beside IEEE802.15.4 header and MIC (if secured).
I'm using rpl-source routing so my headers will vary from hop to hop since there are ipv6 header, iphc header, routing headers with paging dispatch and so forth. The stack implement RFC6282, RFC8025.

RFC4944 says something about first octet of the datagram (e.g. start of the ipv6 header) which can be offset zero. Here my confusion starts. If I assume everything after ipv6 header belongs to the payload I have to strip the packet at each hop downstream? Since the DATAGRAM_OFFSET should be always a multiples of 8 octets I wonder how I should handle this in an elegant way. Or is the payload in my ping case starting with icmpv6 header with 0x80 (ICMPV6_ECHO_REQUEST), which would make more sense for me.

In some ietf slides I already found some issue statements that some re-fragmentation might be required at intermediate hops and therefore one should try to get all the slack into Frag1. I'm honestly don't understand what is meant by that, I have never heard of it. Maybe an explanation is part of the solution for my problem.

As you can see I'm somehow lost and any help is appreciated - Thanks in advance




Mit freundlichen Grüßen I Best regards 

Christian Hopfner 

Developer | TPI F&E Plattform Informatik
Endress+Hauser SE+Co. KG | Hauptstrasse 1 | 79689 Maulburg | Germany
Phone: [phone]
[e-mail] |  www.pcm.endress.com 


Endress+Hauser SE+Co. KG
Registergericht: Amtsgericht Freiburg i.Br. HRA 670225
Sitz der Gesellschaft: Maulburg
Persönlich haftender Gesellschafter: Endress+Hauser Administration SE
Sitz des persönlich haftenden Gesellschafters: Maulburg
Registergericht: Amtsgericht Freiburg i.Br. HRB 717326
Vorstand: Dr. Andreas Mayr, Dr. Peter Selders
Aufsichtsratsvorsitzender: Matthias Altendorf

Gemäss der Datenschutzgrundverordnung (EU-DSGVO) sind wir verpflichtet, Sie zu informieren,
wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis nach.


Endress+Hauser SE+Co. KG
Register Court: Local Court of Freiburg i.Br. HRA 670225
Registered Office: Maulburg
General Partner: Endress+Hauser Administration SE
Registered Office of General Partner: Maulburg
Register Court: Local Court of Freiburg i.Br. HRB 717326
Chief Executive Officer: Dr. Andreas Mayr, Dr. Peter Selders
Chairman of the Board: Matthias Altendorf

According to the General Data Protection Regulation, we are obliged to inform you when collecting your personal data.
We comply with this information duty with the following Data Protection Statement.


Disclaimer: 

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.