Subject: Re: [Autoconf] [6lowpan] link-local addresses

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Nov 2009 21:30:53 +0100

[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

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sat, 14 Nov 2009 05:43:02 +0900

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:

> 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.
Zach, if you have any additional comments, please do raise them also  
on [autoconf].

Thomas

> Some comments below.
>>>> And now you're about to remove the link definitions - thanks for  
>>>> thanking me.
>>>> 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.
>>
>> 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.
>>
>> please
>> modify the AUTOCONF document to no longer suggest that /128 prefixes
>> assigned to interfaces that way.
>>
>> configured
>> on an interface should be /128" then AUTOCONF please use "host-based
>> routes" instead in the AUTOCONF recommendations.
>>
>> 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.
>>
>> AUTOCONF doesn't talk either: they recommend the assignment of a /128
>> prefix to an _interface_ (not a node).
>
> 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.
>
>>
> Zach
>>>> 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-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Zach Shelby <[email-masked]>
Date: Fri, 13 Nov 2009 21:30:54 +0200

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.

Some comments below.

On Nov 13, 2009, at 19:01 , Alexandru Petrescu wrote:

>> 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.
>>> 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.
>
> My suggestion, along the way I understand these WGs landscapes, please
> 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.
>

> 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.

Zach

>> 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
>
>

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.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Nov 2009 23:24:45 +0100

Thomas Heide Clausen a écrit :
> 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.

Alex

> Zach, if you have any additional comments, please do raise them also on 
> [autoconf].
> 
> Thomas
> 
> 
>> Some comments below.
>>
>>>> o  A subnet prefix configured on this interface should be of length 
>>>> /128.
>>>
>>> If AUTOCONF means "host-based routes" by that "subnet prefix configured

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sat, 14 Nov 2009 07:32:14 +0900

On Nov 14, 2009, at 7:24 AM, Alexandru Petrescu wrote:

>> Thanks for Cc'ing [autoconf]. We're pleased that the document also  
>> is applicable in [6lowpan].
>> 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.
>>>
>>>>> have is
>>>> prefix
>>>> its 6LoWPAN Terminology section, and please don't remove that  
>>>> 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.
>>>>
>>> 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.
>>>>
>>> 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
>>>>
>>>>> 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
>>> 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.
>>>
>>>
>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 14 Nov 2009 00:01:27 +0100

> Oh, but it does: it's a prefix which is not configured to be on a link

On a "link" as rfc4861 understands it?  Or on a "link" which has ABC 
problem?

Is it correct to say AUTOCONF prefix is not configured on a "link having 
A-B-C problem"?   Or is it more correct to say that AUTOCONF prefix is 
not configured on a "link which does not have the A-B-C problem"?

Both are correct?

> -- 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.

So you say on-link prefix is inappropriate on links we don't understand.

It doesn't imply off-link prefix is appropriate on such links.

BEcause "off-link" is already defined: "an address that is not assigned 
to any interfaces on the specified link", i.e. a link which is understood.

If the link is not understood then we can't say whether somethhing is on 
it or off it.  It may be on it, and also off it.

Alex