Hi Zach thank you for the 02 version, I hope I'm reviewing the right one.
Here are some comments.
Generally I must say that I do understand the overall goal, and I fully
agree with making the LoWPAN a single subnet, with a link-local scope.
I also agree with many parts of the document, individually.
However, I have difficulty grasping the overall document (and I ack this
may be due to my new familiarity with the area.)
I'm writing these remarks not with the goal of correcting them, because
I think it may be too complex to make it coherent. I'd rather imagine a
more efficient approach would be to select some parts of the draft and
make it much shorter.
For example, why describing in detail the mesh-under and route-over
models? I understand this draft deals with only one, right?
Also example: is HC a mandatory feature? If not, then maybe just write
first the ND-over-802154 document which doesn't use on HC.
Code: 0 indicates a message sent directly from the orginating
host. 1 indicates that the message has been relayed by a
router.
Checksum: The ICMP checksum.
It appears the Code may be changed when relayed - will the checksum
change too, how?
"RR" - potential clash with many terms such as Return Routability tests
(rfc3775), "Resource Records" of DNS, Router Renumbering "RR" headers
rfc2894...
"ER" appears before being clear it's "Edge Router".
Sometimes text may have been written in a hurry ("existing applications
do not exist".)
"6LOWPAN_ER anycast address" - is it a new anycast ID? I like the idea
anyways.
In a LoWPAN, setting the hop-limit to 1 limits a packet to the link,
I agree. But then I can't understand other places which say 'multihop'.
If all nodes are neighbors then there's no multihop. Or is 'multihop'
a 'link-layer multihop' and not an 'IP multi-hop'?
LoWPAN Subnet
A subnet including a LoWPAN or an Extended LoWPAN, together with
the backbone link with the same subnet prefix and prefix length.
I disagree with this picture. This effectively makes the ER to be a
bridge, not a Router ("Edge Router").
I believe it is possible and better to have the LoWPAN have a prefix
like 2001:db8::/64 and the 'backbone' network to have prefix different
at the fourth leftmost bit (different from 2001:db8::/64) - completely
different.
If a valid prefix is available from an RA ('A' flag is set), then a
global unicast address is derived using SAA.
Is SAA SLAAC? I guess so, just it could be mentioned.
This specification includes a method for requesting a unique address
from the edge router by setting the 'A' flag in an Address Option
during registration.
It's not clear while reading whether this unique address is an IP
address or a 16bit short link-layer address. At some point I'm tempted
to believe it's an IPv6 128bit address, because it says it does DAD on
it, but at the same time DAD is done on IP addresses for link-layer
addresses.
It would be good to clarify whether this unique address assigned by ER
is an IPv6 address? or a 16bit short address out of which the node forms
a 128bit address using the rules in rfc4944. If the former then DHCPv6
applies better. If the latter then this shouldn't be done with ICMPv6
messages (as the draft proposes), but with link-layer messages (like
LCP, or similar).
> 6.2 Registration process
[...]
> The source address [of RR] is the link local address of the node.
And is it the unspecified IP address when the link-local address hasn't
yet been decided? (A-bit 1 and 0 length).
Alex
Zach Shelby a écrit :
I have submitted a new version of ND for 6LoWPAN:
http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-nd-02.txt
Changes from -01 include:
- Fixed 16 != 0xff bug (ticket closed)
- Specified use of ULAs in ad-hoc LoWPAN section 9 (ticket closed)
- Terminology cleanup based on Alex's comments
- General editing improvements
Known open issues:
- Specify Trickle in an appendix or just reference it?
- RA information dissemination consistency in more detail in Section 7
I would like to request a presentation slot of 45 minutes from the
chairs to present the draft in SFO.
- Zach
-------- Original Message --------
Subject: New Version Notification for draft-ietf-6lowpan-nd-02
Date: Mon, 9 Mar 2009 08:36:26 -0700 (PDT)
From: IETF I-D Submission Tool <[email protected]>
To: [email protected]
CC:
[email protected],[email protected],[email protected],[email protected]
A new version of I-D, draft-ietf-6lowpan-nd-02.txt has been successfuly
submitted by Zach Shelby and posted to the IETF repository.
Filename: draft-ietf-6lowpan-nd
Revision: 02
Title: Neighbor Discovery for 6LoWPAN
Creation_date: 2009-03-09
WG ID: 6lowpan
Number_of_pages: 46
Abstract:
This document specifies Neighbor Discovery optimized for 6LoWPAN.
The 6LoWPAN format allows IPv6 to be used over energy and bandwidth
constrained wireless networks often making use of extended multihop
topologies. However, the use of standard IPv6 Neighbor Discovery
with 6LoWPAN has several problems. Standard Neighbor Discovery was
not designed for wireless links, and the standard IPv6 link concept
and heavy use of multicast makes it inefficient. This document
spefies a new ND mechanism allowing for efficient Duplicate Address
Detection over entire LoWPANs. In addition it specifies context
dissemination for use with router advertisements, claim and defend
addressing, and the support of extended LoWPANs over backbone links.
The IETF Secretariat.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
