Subject: [6lo] Errata ID: 4814

From: Erik Kline <[email-masked]>
Date: Fri, 3 Sep 2021 14:28:59 -0700

All,

I've been trying to catch up on and close all outside INT area errata.  In
so doing, I've come across:

    https://www.rfc-editor.org/errata/eid4814

filed against RFC 6282.

My inclination is to reject this erratum, since 255 is in fact "used to
verify that a communication occurs over a single-hop", and this sentence
provides some background for the document treating 255 later on (section
3.1.1).

If anyone feels I've misread or misunderstood something do let me know.

Thanks,
-Erik

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 3 Sep 2021 18:05:02 -0400

On Fri, Sep 3, 2021 at 5:29 PM Erik Kline <[email-masked]> wrote:

> I agree that the errata as submitted appears to be incorrect. However,
that doesn't necessarily
mean the statement in the RFC is clear. Let's start with the proposed
wording "... a Hop Limit
value of 1 is often used to verify that a communication occurs over a
single hop." I believe a
sender would set a value of 1 to _ensure_ a packet only travels over a
single hop. A receiver
might use the comparison value of 255 to _verify_ a received packet has not
been routed.
However, the preceding sentence in RFC 6282 suggests that 64 is also a
common value for
outbound traffic. In the event, a value of 64 _might_ indicate the packet
has not been routed,
but it might also indicate the packet traveled 255 - 64 = 191 hops before
reaching the receiver,
so 255 seems the only reliable comparison value. (Why would a receiver need
to know this?)

Kerry

>
> Thanks,
> -Erik
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 05 Sep 2021 23:40:18 -0400

> so 255 seems the only reliable comparison value. (Why would a receiver need

I remember filing this erratum, and at the time, someone pointed out how
the 255 hop-limit is used, etc. as Kerry describes.  I'm surprised that
the erratum hasn't been closed previously.

The flagged statement in the RFC isn't clear if one isn't steeped in
6lowpan networking, though it isn't necessary to understand and apply
the RFC.

Dale

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 6 Sep 2021 18:46:37 -0400

> 6lowpan networking, though it isn't necessary to understand and apply
Hop Limit referred to  here is an IPv6 header field that, according to
Sect 3 of RFC 8200, is "decremented by 1 by each node that forwards
the packet."

IPv6 Neighbor Discovery [RFC 4861] sets Hop Limit to 255 according
Sect 11.2: "Because routers decrement the Hop Limit on all packets
they forward, received packets containing a Hop Limit of 255 must
have originated from a neighbor."

So the sentence referred to in the errata is correct, but could be
marginally clarified by adding " (e.g. by IPv6 Neighbor Discovery
[RFC4861]."

Kerry

On Fri, Sep 3, 2021 at 6:05 PM Kerry Lynn <[email-masked]> wrote:

>> I've been trying to catch up on and close all outside INT area errata.
>> In so doing, I've come across:
>>
> might use the comparison value of 255 to _verify_ a received packet has
> not been routed.
> so 255 seems the only reliable comparison value. (Why would a receiver
> need to know this?)
>
> Kerry
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 7 Sep 2021 10:35:59 +0200

> the erratum hasn't been closed previously.

I agree with Dale that the errata report should be closed.

I also agree that the sentence could be clearer; it is only clear to people who already are familiar with the concept of using HL=255 for verifying local provenance.  Adding a reference might indeed help.

But the whole thing is, at best, a “hold for document update” clarification proposal.

Grüße, Carsten