Sorry Zach, I've wrongly re-reviewed 00 instead of 01.
I'll wait for 02 then review later.
Alex
Zach Shelby a écrit :
Alex,
Alexandru Petrescu wrote:
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?
Thanks for coming back to this, good timing as I am editing -02 right
now for submission today.
Let me bring back the issues, which aren't addressed in this new version.
I took as many of your comments into account in -01 as possible, some
were not relevant which I will explain below. A few slipped the editing,
sorry about that!
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?
You are right, it would be better to simply say "IPv6 subnet prefix". In
fact this could be a global subnet prefix, or a ULA (RFC 4193) which is
used in ad-hoc LoWPANs (ULA use to be defined in nd-02 Section 9). I
will fix that in -02. Of course fe80::/10 is never advertised in an RA...
Please note: ND for 6LoWPAN defines a multi-link subnet, thus link-local
scope is limited to a single hop. However in route-over LoWPANs a LoWPAN
subnet does consist of multiple hops. We have a special NBMA case here
that we need to live with. Please see Section 5 about the LoWPAN Subnet,
and discuss more on that with Pascal and Erik if you like.
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?
Thanks, I tried to remove the use of "default prefix" in -01 but missed
a couple, this is a valid comment which I will fix in -02.
However, please note that in ND for 6LoWPAN we do have context
identifiers associated with prefix information and we actually do have a
default used by 6LoWPAN compression which is CID = 0. Please refer to
Section 4.4.2. So we could use the term "default prefix" but let's not
do that for simplicity.
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?
Please see my note above regarding the LoWPAN Subnet, which is
multi-link. We do have multihop in the subnet, and we are decrementing
the hoplimit upon IP forwarding. This is known as route-over in a LoWPAN
subnet.
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.
Thanks, this is one that was missed. It should just say a unicast
address. This is standard SAA, and is not referring to RFC4193 here.
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?
No. This is a unique address generated by the whiteboard for use by the
requesting node. See the note on short-address assignments below.
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?
That is not true with IEEE 802.15.4 and similar MAC technologies. They
almost universally have some kind of short MAC address support, e.g.
16-bit MAC addresses in 802.15.4. These short addresses can be
configured on a node on the fly in addition to its unique 64-bit EUI-64.
Thus even with this mapping we can and do assign addresses, which is
what the 'A' flag is used for.
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?
We discussed this in the Minneapolis 6lowpan wg meeting. We are not
assigning addresses as with DHCP. Instead the edge router is simply
generating a unique short link-layer address on behalf of the node. From
that point on the node uses that address in a claim and defend manner.
In fact this address could easily be generated by the node itself, and
then during the router registration DAD is performed as with all
addresses being registered. So you just keep trying until you find a
unique one.. However by having the edge router generate it we save a few
steps for efficiency as the edge router can perform DAD across the whole
LoWPAN (in extended LoWPANs this may be a very large network).
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.
It really is a link-layer address, because IEEE 802.15.4 and similar
technologies support the configuration of assigned short link-layer
addresses. This short link-layer address must be unique in a LoWPAN, and
the edge router has the whiteboard and backbone link DAD mechanisms to
ensure that it is unique on generation.
Alex
Regards,
Zach
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
