The Arch Rock stack does implement RFC 4861 in a route-over
configuration and passes the IPv6 Ready - Phase 2 tests. We have
found NUD useful for determining reachability with any neighboring
node - not just parents in the routing DAG. We have found SLLAO
useful for communicating both short and extended versions of the link
address.
As for particular optimizations in practice, we have changed the
timing parameters of when/how often to transmit certain messages.
Also, while the stack does perform DAD when assigning an address to
the interface, duplicates outside radio range will not be detected.
This has not a problem because we use lightweight form of DHCP to
assign unique addresses and have control over the system deployment.
And while the stack does implement processing for Prefix Information
Option, Redirect Header, or MTU options, we don't use them in practice.
The cost of link-local multicast, while significant, depends on the
frequency of utilizing it. In practice, RA messages dominate the use
of link-local multicast - we use them for routing and communicating
short link addresses. Multicast NS messages are relatively rare due
to neighbor caches.
Our duty-cycling link protocol is a form of channel-sampling designed
to support the always-on abstraction. The details of which can be
found in Chapter 4 of [1]. We are currently in the drafting stage of
standardizing this approach in the 802.15.4e task group.
[1] http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-116.pdf
--
Jonathan Hui
On Oct 13, 2009, at 7:05 AM, Julien Abeille (jabeille) wrote:
Arch Rock.
Jonathan, can you give detais?
Best,
Julien
From: Colin O'Flynn [mailto:[email protected]]
Sent: mardi 13 octobre 2009 15:51
To: Julien Abeille (jabeille); '6lowpan'
Subject: RE: [6lowpan] Fundamental concerns about 6lowpan ND
Yes, but is Contiki a usable implementation for what we want to do?
How well does sleeping or mesh routing work for instance? That is
what I mean by an implementation that uses full ND6 – someone doing
mesh + sleeping + RFC4861/2.
Regards,
-Colin
From: Julien Abeille (jabeille) [mailto:[email protected]]
Sent: October 13, 2009 2:23 PM
To: Colin O'Flynn; 6lowpan
Subject: RE: [6lowpan] Fundamental concerns about 6lowpan ND
Hi Colin,
any stack that passes IPv6 ready tests does, i know two of these,
one being Contiki/uipv6.
Best,
Julien
From: Colin O'Flynn [mailto:[email protected]]
Sent: lundi 12 octobre 2009 18:46
To: Julien Abeille (jabeille); '6lowpan'
Subject: RE: [6lowpan] Fundamental concerns about 6lowpan ND
Hello,
I understand the problems with ‘redesigning’ a core IPv6 protocol.
However I’m curious about existing implementations that use full
IPv6 ND, do you have details?
I see the 6LoWPAN ND as a ‘necessary evil’, however I would love to
be proven wrong!
Regards,
-Colin
From: [email protected] [mailto:[email protected]] On
Behalf Of Julien Abeille (jabeille)
Sent: October 12, 2009 1:47 PM
To: 6lowpan
Subject: [6lowpan] Fundamental concerns about 6lowpan ND
Dear WG,
I have serious concerns about the 6lowpan ND draft and would like to
have the WG opinion on this. I agree that a few issues arise in
lowpan environments, which are mostly linked to the non transitivity
of some link layers used in lowpans. However, my two major points of
concern are:
- RFC4861 and RFC4862, which are core to IPv6, are being very
heavily redesigned. I believe that the proposal if it is done in
6lowpan MUST be designed as an optional extension to ND, not a
redesign. The charter states that the draft should propose
"optimizations" and "limited extensions" to ND. It is not the case
at the moment. The proxy ND proposal, the mandatory addressing model
proposed, also goes beyond the scope of the document as spelled out
in the charter.
- non transitivity is not a lowpan only issue, hence if adaptations
to ND must be done, it should be in another WG, probably 6man
If these two points are not respected,
- it questions the applicability of IPv6 in smart object networks:
the draft is redesigning roughly 80% of RFC4861 and RFC4862, which
are core to IPv6
- existing IPv6 implementations will be strongly impacted, as a
number of major components will have to become layer 2 dependant:
-- address resolution will have to be disabled
-- DAD will have to be modified
-- NUD will have to be modified
-- prefix discovery will have to be modified
-- autoconf will have to be modified
-- IPv6 addresses will not be configurable if their IID is not based
on the MAC address
-- ... all these changes are 6lowpan dependant, as they do not
impact traditional links. This will raise important interoperability
issues.
- new layer 3 protocol designs will become layer 2 dependant. This
is what is currently happenning in the ROLL WG by proposing to use a
different message to transport routing information, depending on the
medium.
Moreover, a number of existing deployments show that the issues
arised on lowpan networks as far as ND is concerned are not huge:
the deployments work, and ND as it is has proven to be power
consumption friendly. DAD is the most problematic procedure, that
requires work, as two hop neighbors do not see NS sent for DAD (see
at the bottom)
In conclusion, I believe the advantages of rebuilding neighbor
discovery for lowpans are by far inferior to those of keeping using
the "same IP" on all medium. If some redesign has to be done, it
MUST be done in a more general fashion, probably in 6man, and in a
much lighter way.
Best,
Julien
DAD issue description:
node A and node C see node B, but not each other. nodes A and B
boot, configure a link local address, perfom traditional DAD. It
works. Node C boots with the same MAC address than A, configures the
same IP address, sends a NS to perform traditional DAD. A does not
see the NS hence C address configuration works. A and C have the
same address. B will not differentiate A and
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
