Hi JP & 6lowpan WG,
I have not done a thorough review of the draft yet, but I did have
a brief read to try and understand the approach. I am curious as to why
this work is not progressing more along the lines of the IPv6-over-foo
type documents that have been published in the past. Is an 802.15.4
network that much more of an onerous environment for the base IPv6
protocols (modulo some modifications/extensions)?
We had similar issues back in the 20th Century with other
NBMA-type links. RFC 2491 was written to capture those interfacing
functions needed to allow NDP and such to operate correctly.
Is it possible that standard IPv6 nodes could operate on a 6lowpan
network as well as a more traditional (e.g., ethernet) one? If so, this
seems like a lot of complexity needed in that device to determine the
type of link it is operating on.
I agree that non-transitive links are an issue for more than just
802.15.4 networks. The description given could be applied to 802.11 as
well. Yet, IPv6 over 802.11 works relatively well.
It appears that a cross-WG review would be a good idea at this
point. I would like to see some 6MAN contributors comment on this work
rather than waiting until a Last Call.
Regards,
Brian
JP Vasseur wrote:
All valid concerns and questions.
Copying Bob and Brian to get their input there.
Thanks.
JP.
On Oct 12, 2009, at 2:47 PM, 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, 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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
