Hi Alex,
Thanks again for the comments, below are main responses. The authors
will work on these in SFO and integrate all we can in -03.
Alexandru Petrescu wrote:
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.
I agree some sections could be shorter. Right now I only see that the
LoWPAN ER Operations section could be compressed. See below regarding
the intro.
For example, why describing in detail the mesh-under and route-over
models? I understand this draft deals with only one, right?
ND for 6LoWPAN definitely supports both mesh under and route over! This
is the reason why both are covered, and why we explain the difference.
In practice the only difference is that there are no LoWPAN Routers.
Host and Edge Router operations are the same.
As the WG does not have an architecture document, and things have
changed quite much since RFC4944, we need to cover quite a lot of
architecture and terminology here. If there would be a separate
architecture document, then those things could be removed from this draft.
We'll try to make it more concise and understandable. I agree it needs
to be easy to grasp to 6lowpan newcomers.
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.
This draft works with both RFC4944 and draft-ietf-6lowpan-hc. I don't
see the point of ND without IPv6.
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?
Yes, good point. This will be corrected.
"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.
Yes it is, see the IANA consideration sections, we are requesting a new
anycast for this.
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'?
We explicitly support both mesh under and route over! In route over
LoWPANs we do have IP multihop and the LoWPAN is made up of a set of
NBMA links.
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").
This uses a similar model to Proxy ND, so nothing new. It is not a
bridge, and does IP routing.
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.
In the LoWPAN model it is like this. Extended LoWPANs share the same
prefix with their backbone link.
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.
Yes.
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 is a unique IPv6 address. Because of the IID to link-layer address
direct mapping in 6lowpan, in reality it means that it is both. As the
IID is used as a MAC address, it must be unique throughout the LoWPAN.
By performing DAD on the IPv6 address, and the prefix is the same
throughout the LoWPAN, we in fact are checking that the IID is unique.
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).
It is an IPv6 address, but it is not assigned, and has no state. It ties
in very closely with DAD and SLAAC. We see this to be a very suitable ND
operation, which of course makes use of ICMPv6. As I mentioned earlier,
this generation could easily be done by the node itself at the expense
of more packet exchanges = energy.
> 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).
The draft defines that nodes perform SLAAC and use the addresses as
optimistic during the registration phase, so OK. All nodes do have a
link-layer address by default - it is typically a 64-bit EUI-64. The
reason why some networks MAY also assign short addresses is a huge
savings in header sizes...
Zach
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.
--
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
