On Nov 14, 2009, at 7:24 AM, Alexandru Petrescu wrote:
Thomas Heide Clausen a écrit :
Zach,
Thanks for Cc'ing [autoconf]. We're pleased that the document also
is applicable in [6lowpan].
On Nov 14, 2009, at 4:30 AM, Zach Shelby wrote:
Alex,
(added autoconf to CC)
Now I see what you were concerned about below. Yes I agree, the
wording of how we assign addresses is slightly different. We are
using host-based routes with exact match. As the autoconf document
uses a SHOULD here, 6lowpan-nd can still use a /64 advertised
throughout the LoWPAN to form addresses. It would be nice if
autoconf could update their wording somewhat, so let's see if that
is possible.
One of the comments from [autoconf] this time was to adopt a
phrasing of "has no on-link prefix", as suggested by Dave Thaler,
Sit tight, I think that an updated I-D should be forthcoming shortly.
Thomas, Dave - what do you mean by "on-link" prefix? What do you
mean by "link"?
"on-link" prefix is understood in settings where "link" is
understood. Settings where "link" is not understood, "on-link" makes
no sense whatsoever, as "off-link" doesn't either.
Oh, but it does: it's a prefix which is not configured to be on a link
-- which is a good idea as (as you state) the "link is not
understood", beyond that we understand it well enough to realize that
the connectivity properties are undetermined, and that therefore the
use of an on-link prefix is inappropriate.
Thomas
Alex
Zach, if you have any additional comments, please do raise them
also on [autoconf].
Thomas
Some comments below.
On Nov 13, 2009, at 19:01 , Alexandru Petrescu wrote:
Zach Shelby a écrit :
On Nov 12, 2009, at 18:17 , Alexandru Petrescu wrote:
We do appreciate all the help you gave to polish our model in
April, thanks for that!
And now you're about to remove the link definitions - thanks
for thanking me.
We didn't say that we are going to remove all references to a
link. We haven't decided how to use the autoconf model yet.
Obviously we would need to build around it.
Additionally to AUTOCONF draft being against the 6lowpan-ND
definition of link, and of its first phrase in the
Bootstrapping section (are you going to remove that too?),
AUTOCONF draft also requires the prefixes to be /128
exclusively. Are you thus going to require /128 prefixes
exclusively too in the 6lowpan-ND document?
As a LoWPAN shares a single prefix, all nodes in a LoWPAN can
have is
a an address.
YEs - that shared single prefix is a /64 with IPv6 over 802.15.4,
because that's what rfc4944 suggests.
And yes, each node in a LoWPAN has an address.
Or, AUTOCONF draft-ietf-autoconf-adhoc-addr-model-00 says this:
o A subnet prefix configured on this interface should be of
length /128.
I think we either have a terminology problem (what's a "subnet
prefix
configured on an interface"?) or a crystalizing incoherency between
AUTOCONF and 6lowpan-nd.
My suggestion, along the way I understand these WGs landscapes,
please
modify the AUTOCONF document to no longer suggest that /128
prefixes
assigned to interfaces that way.
If AUTOCONF means "host-based routes" by that "subnet prefix
configured
on an interface should be /128" then AUTOCONF please use "host-
based
routes" instead in the AUTOCONF recommendations.
AUTOCONF please note that 6lowpan-ND document touches briefly on
these
host-based routes aspects when talking "exact match" searches in
its 6LoWPAN Terminology section, and please don't remove that
from the 6lowpan-ND document.
The "exact match" method of search in a routing table (as opposed
to "longest-prefix match") is terminology similar to "Basic
Match" and "Longest Match" used in rfc1812. Although the rfc is
only IPv4 it also applies to IPv6.
It is however not quite the same thing.
When you want, we can discuss the definition of "exact match"
further, as useful to implementer. The 6lowpan-ND definition of
"exact match" is a good start, IMHO.
We do not talk about assigning prefixes to nodes in this WG.
YEs, right.
AUTOCONF doesn't talk either: they recommend the assignment of a /
128
prefix to an _interface_ (not a node).
I meant interface of course (we usually just have one)...
Or, 6lowpan-ND does assign a prefix to an interface when doing the
IPv6-over-802154 SLAAC stuff.
Not exactly. We only use the advertised /64 to form the address.
After that we assume everything (except link-local) is off-link.
Therefore we don't really assign the prefix to the interface. So
in practice the end result is the same as assigning a /128. Right?
So this is just a wording difference.
Routers do advertise the prefix used throughout the LoWPAN
(using RAs). And nodes may then auto-configure addresses based
on that.
YEs, and the auto-configured addresses look like this:
2001:db8::XXXX:XXXX:XXXX:XXXX/64
Note the "/64".
So the autoconf text should say that you can should a /128 or a /
64 when using SLAAC to make that explicitly OK?
Zach
Alex
Are you going to modify the 6lowpan-ND bootstrapping because
AUTOCONF draft requires prefixes /128?
It already works like this, no changes necessary. As far as I
can tell, the autoconf draft requires no functional changes to
the base mechanisms of our work. Again, we still need to look at
the details.
Cheers, Zach
--
http://www.sensinode.com
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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
