Hi, thanks for this new version of the daft.
Version -01 of ND for 6lowpan is now available.
http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-nd-01.txt
This revision closes a long list of smaller and major tickets. Thanks
to all the feedback in Minneapolis and on the list. Here is a
summary of changes:
- Specified the duplicate owner interface identifier procedures. A
TID lollypop algorithm was sufficient (nonce unnecessary). - Defined
fault tolerance using secondary bindings. - Defined ad-hoc network
operation. - Removed the E flag from RA and the X flag from RR/RC. -
Completed message examples. - Lots of improvements in text quality
and consistency were made.
The draft is now quite stable, and includes all the functionality we
envision for IESG submission. I will submit -02 before the cutoff
March 10th, which will be presented in San Francisco. Looking forward
to reviews, and especially implementation feedback.
I don't have implementation feedback.
I did submit however some remarks earlier, and some were not reflected
in the new version, may I have feedback back about why not?
Let me bring back the issues, which aren't addressed in this new version.
o A subnet covers all the LoWPANs and their backbone link with the
same IPv6 global or local prefix.
This is throughout the document: I'm not sure I understand 'local'
prefix. Is it the globally reserved fe80::/10 link-local scope prefix?
Is it fc00::/7 globally unique yet smaller than global scope?
If the host moves to a different LoWPAN, with a different default
prefix, the bootstrapping process is initiated again.
Throughout the document I don't understand 'default' prefix. Are there
other alternative or preferred prefixes?
4.4.3. Multihop Information Option
This option identifies the set of prefix information options by a
sequence number. This allows for the full set of prefix information
options to be sent only periodically in unsolicited RAs. If a host
detects a difference in the sequence number of this option, then the
prefix information has likely changed, and is then requested with an
RS.
I'm not sure the term Multihop is appropriate to name this option? There
is no decrementing of HopLimit, it's a single subnet, thus no multihop.
Or this Multihop means that it's multi-link-layer-hop? I'm not sure how
people call when my PC talks to a neighbor PC in the same subnet but
separated by 3 switches - is that Multihop?
The node might also form Unique Local and Global Unicast addresses,
Is this Unique Local address an RFC4193 "Unique Local IPv6 Unicast
Addresses"? This could be clarified.
This specification includes a method for requesting a unique
stateless address from the Edge Router by setting the 'A' flag in an
Address Option during registration.
Is this unique stateless address the same as the prior mentioned Unique
Local address, same as in rfc4193?
To simplify address resolution it is assumed that LoWPAN nodes are
assigned addresses in a homogeneous so that the unicast IPv6
addresses IID resolve directly to a corresponding link-layer address.
Thus avoiding address resolution when possible.
I'm afraid this way of avoiding NS-NA address resolution means
effectively forbidding manually assigned addresses - is this ok?
This specification includes a method for requesting a unique
stateless address from the Edge Router by setting the 'A' flag in an
Address Option during registration.
A new mechanism to assign addresses? Why wouldn't DHCP be sufficient?
Maybe Stateless DHCP RFC3736?
then the ER aquires an appropriate, unique link-layer address for the
network either by generating it and performing DAD, or with some
other method.
A link-layer address or a link-local address? I suppose the latter.
Although sometimes the link-layer ids are also negotiated... but not
sure one would DAD the link-layer address.
Alex
Zach Shelby a écrit :
Hi,
Version -01 of ND for 6lowpan is now available.
http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-nd-01.txt
This revision closes a long list of smaller and major tickets. Thanks
to all the feedback in Minneapolis and on the list. Here is a
summary of changes:
- Specified the duplicate owner interface identifier procedures. A
TID lollypop algorithm was sufficient (nonce unnecessary). - Defined
fault tolerance using secondary bindings. - Defined ad-hoc network
operation. - Removed the E flag from RA and the X flag from RR/RC. -
Completed message examples. - Lots of improvements in text quality
and consistency were made.
The draft is now quite stable, and includes all the functionality we
envision for IESG submission. I will submit -02 before the cutoff
March 10th, which will be presented in San Francisco. Looking forward
to reviews, and especially implementation feedback.
Regards, Zach
-------- Original Message -------- Subject: New Version Notification
for draft-ietf-6lowpan-nd-01 Date: Mon, 23 Feb 2009 13:24:20 -0800
(PST) 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-01.txt has been
successfuly submitted by Zach Shelby and posted to the IETF
repository.
Filename: draft-ietf-6lowpan-nd Revision: 01 Title: Neighbor
Discovery for 6LoWPAN Creation_date: 2009-02-23 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 very
constrained wireless networks often making use of extended multihop
topologies. However, the use of standard IPv6 Neighbor Discovery over
6LoWPAN networks 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 mechanism allowing efficient Duplicate Address
Detection over entire 6LoWPAN networks. 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
