Dale Worley <> writes:

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

> Dale


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

> On Fri, Sep 3, 2021 at 5:29 PM Erik Kline <[email protected]> wrote:
>
>> 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).
>>
>> 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
>
>
> If anyone feels I've misread or misunderstood something do let me know.
>>
>> Thanks,
>> -Erik
>> _______________________________________________
>> 6lo mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/6lo
>>
>
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo

Reply via email to