Subject: [6lo] draft-ietf-6lo-fragment-recovery: What to do if hop limit is reached

From: Martine Lenders <[email-masked]>
Date: Tue, 5 Nov 2019 11:53:35 +0100

Hello,

I'm aware this is a corner case that usually should not happen in a
properly configured WPAN, but what is an implementation of selective
fragment recovery supposed to do, if hop-limit 0 is reached? With minimal
forwarding I just reassembled it and handed it to IPv6 so it can send a
ICMPv6 Time exceeded error message. Should selective fragment recovery send
an abort ACK in that case as well? Or just the abort ACK?

Best regards,
Martine

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 6 Nov 2019 17:15:07 +0000

Hello Martine

You did great ! Yes I think that 
You should send back the beginning of the original fragment at least up to the HL in an icon error and then an  abort...

This is the generic problem with errors in 6LoWPAN HC networks . Should the ICMO contain the compressed or uncompressed?
To sort out the error which maybe with the compression I believe we must send back the compressed form in ICMP errors .

Regards,

Pascal

> Le 5 nov. 2019 à 11:54, Martine Lenders <[email-masked]> a écrit :
> 
> 
> Hello,
> 
> I'm aware this is a corner case that usually should not happen in a properly configured WPAN, but what is an implementation of selective fragment recovery supposed to do, if hop-limit 0 is reached? With minimal forwarding I just reassembled it and handed it to IPv6 so it can send a ICMPv6 Time exceeded error message.. Should selective fragment recovery send an abort ACK in that case as well? Or just the abort ACK?
> 
> Best regards,
> Martine
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Martine Lenders <[email-masked]>
Date: Wed, 6 Nov 2019 18:42:09 +0100

Hi Pascal,

Am Mi., 6. Nov. 2019 um 18:16 Uhr schrieb Pascal Thubert (pthubert) <
[email-masked]>:

> You should send back the beginning of the original fragment at least up to
> the HL in an icon error and then an  abort...
>
> This is the generic problem with errors in 6LoWPAN HC networks . Should
> the ICMO contain the compressed or uncompressed?
> To sort out the error which maybe with the compression I believe we must
> send back the compressed form in ICMP errors .
>

That is contrary to what I did and also seems to me way more complicated
than they need to because:
a) IPHC (which isn't currently "aware" of ICMPv6 as it is not compressed)
needs to parse through every intermediate non-compressed header at *every*
hop (as the compression changes at every hop).
b) If you have a classic IPv6 interface running in tandem (e.g. the border
router, but we also have use cases were people just have an Ethernet cable
on a 6LN as well for diagnostics) you have to implement two kinds of ICMPv6
error messages: compressed and uncompressed.

So having them to have compressed (MUST) would add a lot of overhead.

Best regards,
Martine

> ICMPv6 Time exceeded error message.. Should selective fragment recovery
> send an abort ACK in that case as well? Or just the abort ACK?
> >
> > Best regards,
> > Martine

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 6 Nov 2019 19:44:49 +0000

So you are sending the ICMP error with inside the uncompressed packet? Maybe it’s ok for hop count but what if the error is due to malformed/ unsupported form of compression? The sender may not recognize what it sent in the attempt of decompression that is returned. When you detect the error did you already loose track of the compressed packet? I thought you’d keep it to forward it because most times there’s no need to change the iphc piece.

Regards,

Pascal

Le 6 nov. 2019 à 18:42, Martine Lenders <[email-masked]> a écrit :

Hi Pascal,

Am Mi., 6. Nov. 2019 um 18:16 Uhr schrieb Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>:
Hello Martine

That is contrary to what I did and also seems to me way more complicated than they need to because:
a) IPHC (which isn't currently "aware" of ICMPv6 as it is not compressed) needs to parse through every intermediate non-compressed header at *every* hop (as the compression changes at every hop).
b) If you have a classic IPv6 interface running in tandem (e.g. the border router, but we also have use cases were people just have an Ethernet cable on a 6LN as well for diagnostics) you have to implement two kinds of ICMPv6 error messages: compressed and uncompressed.

Best regards,
Martine

Regards,

Pascal

> Le 5 nov. 2019 à 11:54, Martine Lenders <[email-masked]<mailto:[email-masked]>> a écrit :
>
> 
> Hello,
>
> [email-masked]<mailto:[email-masked]>