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

Hi Pascal,

Am Mi., 6. Nov. 2019 um 18:16 Uhr schrieb Pascal Thubert (pthubert) <
pthubert@cisco.com>:

> 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 .
>

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

>
>
> Regards,
>
> Pascal
>
> > Le 5 nov. 2019 à 11:54, Martine Lenders <m.lenders@fu-berlin.de> 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
> > 6lo@ietf.org
> > https://www.ietf.org/mailman/listinfo/6lo
>