Subject: [6lowpan] Hop limit in multi hop messages

From: Daniel Gavelle <[email-masked]>
Date: Wed, 13 Oct 2010 13:30:40 +0100

When the multi-hop NS is sent from the LR to the LBR, its hop limit is 
set to 255 and then decremented on each hop.  When it arrives at the 
LBR, the hop limit=255 check is ignored.  There are a couple of problems 
with this mechanism:-

(1) If the packet enters a routing loop, it will take a long time to die.

(2) Some stacks have a rule that packets with a hop limit of 255 should 
never be forwarded by the routing layer or a hop limit of 254 should 
never be transmitted.

These problems could be addressed by setting the hop limit to a more 
typical value, e.g. 64, for the multi-hop messages.

Regards,

Daniel.

-- 

__________________________________________________

Daniel Gavelle, Software Team Leader
Low Power RF Solutions (formerly Jennic Ltd.)
NXP Semiconductors
Furnival Street, Sheffield, S1 4QT, UK
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Comp Reg No: 3191371 - Registered In England
http://www.nxp.com http://www.jennic.com
__________________________________________________

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 16 Oct 2010 14:37:00 +0200

Hello,

Let me try to understand the Hop Limit discussion in 6lowpan-ND context.

Le 13/10/2010 14:30, Daniel Gavelle a écrit :
> When the multi-hop NS is sent from the LR to the LBR, its hop limit
> is set to 255 and then decremented on each hop. When it arrives at
> the LBR, the hop limit=255 check is ignored. There are a couple of
> problems with this mechanism:-
>

Hmm... not sure it is a looping problem because IPv6 nodes are supposed
to drop the packet when its Hop Limit reaches 0.

> (2) Some stacks have a rule that packets with a hop limit of 255
> should never be forwarded by the routing layer or a hop limit of 254
>  should never be transmitted.

I think yes, that is the case of vanilla ND (non 6LoWPAN)
implementations - nodes must drop ND packets whose Hop Limit is less
than 255 (remark "ND packets", not just any packet).

But draft-ietf-6lowpan-nd requires that the vanilla-ND <255 check to not
be performed - thus a Hop Limit implementation according to 6lowpan-ND
would work.  Is this behaviour ok?

(e.g. 6lowpan-ND text says "result the hop_limit=255 check on the
receiver is disabled for such messages.")

>  typical value, e.g. 64, for the multi-hop messages.

I think it is good to take into account the diameter of a typical
6LoWPAN network (max number of IP hops on shortest path between most
distanced node from LBR) and require the sender's initial Hop Limit to
be set that way, in spec.

What is the typical number of IP nodes in a 6lowpan network? 16?  How
many nodes does 802.15.4 PHYs support in a network?  Implementations?
And the shortest IP path within?

I don't see WPAN networks requiring 255 (Hop Limit) nodes on a personal
area network - it's way too much.  The typical WPAN networks I
experiment are less than 8 nodes, and yes I agree it's only small scale.

I think it is not good for the 6lowpan-ND spec to be vague about it
(currently it says: "255 or smaller number").

And there are other problems with this Hop Limit field:

A Hop Limit field is decremented when forwarding packets across links.
I think here 6lowpan-ND nodes use exclusively link-local addresses as
src and dst (I have to verify spec).  A node is typically prohibited
from forwarding such packets across links.  Thus, if not forwarding, it
would not make sense to decrement the Hop Limit field of 6lowpan-ND
messages by 6lowpan-ND nodes.

What would need to happen to avoid this necessity of not forwarding
link-addressed packets is that each 6lowpan-ND node originates a _new_
6lowpan-ND message upon reception, instead of forwarding it; a new
packet with different src and dst link-scoped addresses.  If a new
packet is thus generated then that new packet would have to have a fresh
Hop Limit value, not the received value decremented.

Just some thoughts.

Alex

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 16 Oct 2010 15:11:03 +0200

On Oct 13, 2010, at 14:30, Daniel Gavelle wrote:

> These problems could be addressed by setting the hop limit to a more typical value, e.g. 64, for the multi-hop messages.

Sounds good to me.

Multihop messages between 6LR and 6LBR definitely don't need the HL=255 trick, so the nodes should be free to choose a hop limit that is appropriate for the network they are in.

I don't think we want to hardwire a suggestion for the 'hop limit' value in the draft (although a number around 64 sounds like a good implementation default).

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 17 Oct 2010 17:05:03 +0200

On Oct 16, 2010, at 14:37, Alexandru Petrescu wrote:

> src and dst (I have to verify spec). 

No, the whole point of multihop messages is that they are sent between nodes in a 6lowpan (6LR and 6LBR) that can't necessarily reach each other in a single hop.
This is nicely illustrated in 10.2.1.

Gruesse, Carsten

PS.: There is one instance of "multi-hop" in ND-13, all others are "multihop"

---

From: Daniel Gavelle <[email-masked]>
Date: Mon, 18 Oct 2010 09:01:04 +0100

I agree that we don't need a hardwired constant.  However, the 
6LowPAN-ND draft currently specifies a hop limit of 255 for multihop 
messages.  I think we should change the text to make it clear that the 
hop limit should be set to the same value as a normal multihop message 
(e.g. a UDP message) sent to the LBR.

Daniel.

Regards,

Daniel.

--

---

From: Zach Shelby <[email-masked]>
Date: Mon, 18 Oct 2010 11:09:17 +0300

Daniel,

The draft doesn't actually specify that you must use a hop limit of 255. Section 8.2.3 states:

"In the IPv6 hop limit, 255 or a smaller number."

We will definitely try to clarify this better in the text of the next revision though, this could be interpreted now as recommending the use of 255. 

Thanks,
Zach

On Oct 18, 2010, at 11:01 AM, Daniel Gavelle wrote:

> I agree that we don't need a hardwired constant.  However, the 6LowPAN-ND draft currently specifies a hop limit of 255 for multihop messages.  I think we should change the text to make it clear that the hop limit should be set to the same value as a normal multihop message (e.g. a UDP message) sent to the LBR.
> 
> Daniel.
> 
> 
> 
> Carsten Bormann wrote:
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 18 Oct 2010 10:22:26 +0200

There is a difference in type of messages:

6lowpan-ND messages (which stay in the 6lowpan network) should specify 
their Hop Limit value, more precisely than just the current vague "255 
or less".

Any other IP non-6lowpan-ND messages' Hop Limit should be left to the 
other non-6lowpan-ND protocols to specify.

(An IP UDP message sent by a node in the 6lowpan network should be able 
to reach a correspondent node on the other side of the Internet, i.e. 
its Hop Limit to be as large as it could.)

("should" but IMHO).

Alex

---

From: Daniel Gavelle <[email-masked]>
Date: Tue, 19 Oct 2010 09:33:41 +0100

The expression in the draft "In the IPv6 hop limit, 255 or a smaller 
number" has been interpreted as 255 for the default by several 
implementers.   This has led to interop difficulties.  I think the draft 
would be clearer if it specified a hop limit sufficient for messages to 
travel from the LBR to the furthest LR.

In the case I am interested in, we are using RPL with source routing so 
the worst case hop limit can be calculated:-
http://tools.ietf.org/html/draft-hui-6man-rpl-routing-header-02 
specifies  RH4_MAX_SIZE 136.  We are compressing down to 16 bits per 
address, giving a max depth of (136-8)/2 = 64, or less if we specify a 
smaller network depth in our profile specification.

Daniel.

Alexandru Petrescu wrote:
>> We will definitely try to clarify this better in the text of the next 
>> revision though, this could be interpreted now as recommending the use 
>> of 255.
>>
>> Thanks,
>> Zach
>>
>>> messages.  I think we should change the text to make it clear that 
>>> the hop limit should be set to the same value as a normal multihop 
>>> message (e.g. a UDP message) sent to the LBR.
>>>
>>> Daniel.
>>>
>>>
>>>
>>> Carsten Bormann wrote:
>>>>> These problems could be addressed by setting the hop limit to a 
>>>>> more typical value, e.g. 64, for the multi-hop messages.
>>>> Sounds good to me.
>>>> Multihop messages between 6LR and 6LBR definitely don't need the 
>>>> HL=255 trick, so the nodes should be free to choose a hop limit that 
>>>> is appropriate for the network they are in.
>>>> I don't think we want to hardwire a suggestion for the 'hop limit' 
>>>> value in the draft (although a number around 64 sounds like a good 
>>>> implementation default).
>>>> Gruesse, Carsten
>>>
>>>
>>> Regards,
>>>
>>> Daniel.
>>>
>>> -- 
>>>

Regards,

Daniel.

--

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 21 Oct 2010 16:50:08 -0700

On 10/13/10 05:30 AM, Daniel Gavelle wrote:
> set to 255 and then decremented on each hop. When it arrives at the LBR,
> the hop limit=255 check is ignored. There are a couple of problems with
> this mechanism:-
>

I don't have a problem suggesting a value like 64.

But the implementations in (2) seems to be utterly broken because there 
isn't any RFC that says that packets with 255 or 254 should be treated 
differently when transmitting or forwarding.

     Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 22 Oct 2010 12:11:57 +0200

Le 22/10/2010 01:50, Erik Nordmark a écrit :
>> should never be forwarded by the routing layer or a hop limit of
>> 254 should never be transmitted.
>>
> But the implementations in (2) seems to be utterly broken because
> there isn't any RFC that says that packets with 255 or 254 should be
> treated differently when transmitting or forwarding.

Except when those packets are ND... (I mean IIRC ND spec requires to
drop RS packets whose limit is less than 255).

Alex

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

---

From: Dario Tedeschi <[email-masked]>
Date: Wed, 27 Oct 2010 13:03:01 -0700

I think what needs to be specified is the following:

   1. For 6LoWPAN ND packets sent to a link-local address, the hop-limit
      must be set to 255 (as per RFC4861).
   2. For 6LoWPAN ND packets sent to a routable address, the hop-limit
      MAY be set less than 255.

On the receiver side, an implementation MUST discard a ND packet that 
has a link-local destination and a hop-limit less than 255.

Dario

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 27 Oct 2010 14:06:12 -0700

>       MAY be set less than 255.

That is not how RFC 4861 works. It says that NS, NA, RS, RA, and 
Redirect messages all need to be sent with hoplimit 255 and checked on 
receipt.

The NS, NA, and Redirect messages can have a global destination address.

I don't see any reason to change this as part of 6lowpan-nd.

What is you reason for wanting to change it?

    Erik

---

From: Dario Tedeschi <[email-masked]>
Date: Fri, 29 Oct 2010 11:27:15 -0700

Hi Erik

I think my argument has been rendered moot. It appears the problem has 
been solved in the latest draft using new message types for multi-hop 
Address Registration. Aside from being a much cleaner approach, it now 
allows the normal 255 check for all other ND packets.

My initial reasoning was that if the NS/NA messages (in 6LoWPAN ND) 
remained overloaded for multi-hop Address Registration, then I wanted 
some some way of protecting the last hop (i.e. router-host) from 
illegally forwarded NS/NA packets.

Dario