Julien,
On Oct 12, 2009, at 15:47 , Julien Abeille (jabeille) wrote:
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,
This is simply not true. IPv6 is RFC2460. Neighbor Discovery is a one-
hop link protocol originally defined in RFC4861 and clearly pointing
out its need for link-specific extensions and in particular non-
transitive links.
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.
These are also not true. The extended LoWPAN model is optional. There
is also no mandatory addressing model?
- non transitivity is not a lowpan only issue, hence if adaptations
to ND must be done, it should be in another WG, probably 6man
It is a problem we have in this WG, and a problem that the industry
needs solved now, not in several years. Networks built around RFC4944
using route-over routing simply don't work. Non-transivity is also not
the only problem. Sleeping nodes is another problem which is just as
serious for RFC4861.
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
They define ND over Ethernet links. They are not core to IPv6.
- existing IPv6 implementations will be strongly impacted, as a
number of major components will have to become layer 2 dependant:
Existing IPv6 implementations are on mainly on PCs. You can very
easily make make any IPv6 stack work with a 6lowpan network interface
- without any code changes. We have implemented this in several ways.
If you run this under a PC IPv6 stack then you don't change any code.
If you are referring to modifying the few IPv6 implementations there
are for 6LoWPAN nodes then there is not a large installation base.
-- 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
This is also not true. Based on your feedback and that of others,
6lowpan-nd-06 states that in networks where the above is not true,
then there is a mechanism for performing address resolution on the
host-router interface. Furthermore, most MACs used with 6LoWPAN have
fully configurable MAC addresses.
-- ... all these changes are 6lowpan dependant, as they do not
impact traditional links. This will raise important interoperability
issues.
What interoperability issues. ND is a link protocol. Do you want your
Ethernet link to talk to your 802.15.4 link directly (now that is
interoperability!).
- 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.
This is a result of trying to piggyback messages on ND, which is a
link protocol. By the way Julien - you are opposed to doing that - so
then there is no problem!
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)
This is totally not true. You have implemented RFC4861 on Contiki. Did
you try to make that work over multiple hops, with sleeping nodes, in
a real deployment? It doesn't work. NS/NA fails. DAD fails. NUD fails.
We have been deploying 6LoWPAN commercially for almost 2 years, and
can say you need a different solution. Early RFC4944 also mostly badly
or partially made use of RFC4861 messages to try and make things work.
This working group sat on the problem for 3 years, and this is an
organic solution as a result of lots of work. By the way, you
participated in that work.
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.
Again, the same IP has nothing to do with RFC4861. And I don't see
what is "heavy" about 6LoWPAN ND.
If you want to use RFC4861 to build your LoWPANs, go ahead. The rest
of us that want LoWPANs that actually function can use 6LoWPAN-ND. If
you want to start general work on ND improvements in addition to this
then why not. But it is not either-or.
Zach
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
--
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297
Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND
This e-mail and all attached material are confidential and may contain
legally privileged information. If you are not the intended recipient,
please contact the sender and delete the e-mail from your system
without producing, distributing or retaining copies thereof.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
