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:
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
Le 18/10/2010 10:09, Zach Shelby a écrit :
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:
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
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
__________________________________________________
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
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
__________________________________________________
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
