[frustrated having to post again on AUTOCONF, especially now I don't
want to disturb what Carlos has to say in AUTOCONF, but here goes
Cc AUTOCONF anyways.]
Zach Shelby a écrit :
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.
YEs, let's see.
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)...
Ok.
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
Then you should say so - "off-link".
But in 6lowpan-ND draft you mention that "off-link" has no clear meaning
on non-transitive links. If "off-link" has no clear meaning, and
"on-link" has no meaning either, then we risk big trouble because these
terms are heavily used by ND.
And you define "non-local". But that word risks coliding with the
established "link-local". Another big trouble.
Couldn't we just improve that link definition and make it be
deterministic (no A-B-C problem and yes multicast support as offered by
802.15.5)?
If we did so - then we wouldn't have to say that "off-link" has no clear
meaning, and we subsequently wouldn't have to define the terms
"non-local"/"local" which risk coliding with the established "link-local".
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?
Well, AUTOCONF should recommend the use of host-based routes if that's
their intention. Host-based routes don't break anything if deployed on
small scale. An exact-match search in a routing table is easily
implementable with current tables and existing "longest-prefix" match
searches: just enter "/128" destinations in the destination fields of
that table and it works.
But AUTOCONF please don't recommend assignment of unique "/128" prefixes
on interfaces - that breaks too many things: fe80::/10 is not /128 and
worse, it's not unique and its mandatory; using SLAAC with any prefix
longer than /64 won't work for IPv6-over-802154 and many other links,
and more.
If AUTOCONF wants to put a "/128" prefix in an RA L==0 "off-link", then
(1) it should acknowledge the link definition of RFC4861 such that
"link" makes sense in "off-link" and (2) in no case should it configure
that "/128" prefix on any interface (because rfc4861 "off-link" means
the address is not assigned to any interface on specified _link_).
If AUTOCONF can't agree that "link" is what RFC4861 says it to be, then
"off-link" makes no sense, "link-local" makes no sense, and so on.
I can't understand "off-link" without first understanding "link".
Ignore "link" in any one one paragraph below and you break too many
other things:
" link - a communication facility or medium over which nodes
can
communicate at the link layer, i.e., the layer
immediately below IP. Examples are Ethernets (simple
or bridged), PPP links, X.25, Frame Relay, or ATM
networks as well as Internet-layer (or higher-layer)
"tunnels", such as tunnels over IPv4 or IPv6 itself"
" Currently, IPv6 continues the IPv4 model in that a subnet prefix is
associated with one link."
" All interfaces are required to have at least one Link-Local unicast
address (see Section 2.8 for additional required addresses)."
" off-link - the opposite of "on-link"; an address that is not
assigned to any interfaces on the specified link."
" The details of forming interface identifiers are defined in the
appropriate "IPv6 over <link>" specification, such as "IPv6 over
Ethernet" [ETHER], and "IPv6 over FDDI" [FDDI]."
" scop is a 4-bit multicast scope value used to limit the scope of
the multicast group. The values are as follows:
0 reserved
1 Interface-Local scope
2 Link-Local scope"
Or are you about to build a new Internet here in AUTOCONF?
Alex
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
