Subject: [Autoconf] Suggested text on link-locals

From: Erik Nordmark <[email-masked]>
Date: Mon, 27 Jul 2009 16:54:45 +0200

Does this make it more clear?

In section 4.2 change the sentence
    If the link to which an interface connects enables no assumptions of
    connectivity to other interfaces, the only addresses which can be
    assumed "on link", are the address(es) of that interface itself.
to
    If the link to which an interface connects enables no assumptions of
    connectivity to other interfaces, the only addresses which can be
    assumed "on link", are the address(es) of that interface itself. Note
    that IPv6 link-local addresses are assumed "on link".. However, the
    utility of IPv6 link-locals is limited as specified in section 6.2.

At the end of section 6.2 add this text:

A IPv6 link-local addresses must be assigned to each interface according 
to [RFC 4291]. Due to the connectivity properties of these links with 
neighbors constantly moving in and out of reachability, the link-local 
addresses are of very limited utility. The known limitations are:
  - Even if tested for uniqueness at one moment using Duplicate Address 
Detection [RFC 4862], a duplicate link-local address might appear as a 
neighbor the next moment and DAD would not detect that.
  - There is no mechanism to ensure that IPv6 link-local are unique 
across multiple links, hence they can not be used to reliably identify 
routers.
  - Routers must not forward any packets with Link-Local source or
    destination addresses to other links [RFC 4921]. And a Manet router 
that forwards packets by definition forwards from one link to another 
due to the undefined connectivity properties. (The set of neighbors that 
heard the packet received by the router might be different than the set 
of neighbors that hears a packet transmitted by the router even if the 
same interface on the router is used for the two operations.)

   Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Jul 2009 17:33:46 +0200

>    utility of IPv6 link-locals is limited as specified in section 6.2.

Ok to me.

> across multiple links, hence they can not be used to reliably identify 
          ^across links (because it can be used to reliably  identify 
routers on the same link).

>    destination addresses to other links [RFC 4921].

Ok to me.

> And a Manet router 

Sounds good too.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 27 Jul 2009 18:37:22 +0200

Hi Erik,

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens
|Erik Nordmark
|Verzonden: maandag 27 juli 2009 16:55
|Aan: [email-masked]
|Onderwerp: [Autoconf] Suggested text on link-locals
|
|
|Does this make it more clear?
|
|In section 4.2 change the sentence
|    If the link to which an interface connects enables no assumptions of
|    connectivity to other interfaces, the only addresses which can be
|    assumed "on link", are the address(es) of that interface itself.
|to
|    If the link to which an interface connects enables no assumptions of
|    connectivity to other interfaces, the only addresses which can be
|    assumed "on link", are the address(es) of that interface itself.
|Note
|    that IPv6 link-local addresses are assumed "on link".. However, the
|    utility of IPv6 link-locals is limited as specified in section 6.2.

We just specify "on-link" not equals "reachable".
"on-link" means here we don't send packets with a link-local as destination
to a default gateway.

|
|At the end of section 6.2 add this text:
|
|A IPv6 link-local addresses must be assigned to each interface according
|to [RFC 4291]. Due to the connectivity properties of these links with
|neighbors constantly moving in and out of reachability, the link-local
|addresses are of very limited utility.

Maybe, maybe not. I would not disqualify the characteristics.

| The known limitations are:
|  - Even if tested for uniqueness at one moment using Duplicate Address
|Detection [RFC 4862], a duplicate link-local address might appear as a
|neighbor the next moment and DAD would not detect that.

I do not understand the difference with globals / ULAs.

|  - There is no mechanism to ensure that IPv6 link-local are unique
|across multiple links, hence they can not be used to reliably identify
|routers.

This is nothing new.
And the IETF routing protocol number 1 protocol runs perfect on it.
Many others have no problem either.

|  - Routers must not forward any packets with Link-Local source or
|    destination addresses to other links [RFC 4921]. And a Manet router
|that forwards packets by definition forwards from one link to another
|due to the undefined connectivity properties. 

There are multiple opinions on what a link is.
So I cannot agree on the text. But I know what you are saying.

|(The set of neighbors that
|heard the packet received by the router might be different than the set
|of neighbors that hears a packet transmitted by the router even if the
|same interface on the router is used for the two operations.)

Yes, and this is exactly what makes it very powerful for neighborhood 
Discovery [NHDP, OSPF, etc.].

Regards, Teco.

|
|   Erik
|
|_______________________________________________
|Autoconf mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/autoconf

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 27 Jul 2009 19:44:54 +0200

> "on-link" means here we don't send packets with a link-local as destination

I can't parse your first sentence. Are you suggesting that we say 
something different in the draft? Or that we are already specifying this?

Note that in general (even on an Ethernet) all on-link addresses are not 
reachable; fe80::/10 (or fe80::/64) is on-link, but you don't get a 
response from all the addresses in that prefix.

> Maybe, maybe not. I would not disqualify the characteristics.

I explicitly tried to not forbid them - just have appropriate warnings.

> I do not understand the difference with globals / ULAs.

The autoconf WG would presumably come up with a protocol that has some 
ways to avoid non-unique addresses being allocated.

> And the IETF routing protocol number 1 protocol runs perfect on it.

ICMPv4 doesn't run on IPv6; Perhaps you meant ICMPv6, which I wouldn't 
call a routing protocol; I could call it an ES-IS protocol.

> Many others have no problem either.

Duplicate address detection is there to handle unlikely, but very hard 
to detect failures. Hence it is no surprise that most of the time one 
can get away with not doing any DAD.

> So I cannot agree on the text. But I know what you are saying.

Part of the idea with the text in this but a stake in the ground in what 
a link is for these dynamic environments. I don't know if it makes sense 
to do that more directly in a separate section in the document, or have 
it be in this section, but I think it should be in the document.

    Erik

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Jul 2009 12:32:35 -0700

Hi,

I have updated the VET spec to match the proposal briefed
to the autoconf working group today. In this proposal, the
MANET router configures a virtual interface (i.e., a VET
interface) over one or several underlying MANET interfaces
that belong to the same MANET. The MANET router then only
needs to assign an address to the VET interface and can
leave the MANET interfaces with link-local addresses only
or with no addresses at all.

The specific text is found in section 4.1 and Appendix B.
The term "Enterprise Router (ER)" is equivalent to the
term "MANET router" as it is normally used in the autoconf
terminology. The term "enterprise-interior interface" is
equivalent to "MANET interface", and an "Enterprise
Border Router (EBR)" is simply a MANET router that also
configures a VET interface.

Please have a look and send any questions or comments. The
draft is here:

http://tools.ietf.org/html/draft-templin-intarea-vet

Fred
[email-masked]

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 28 Jul 2009 00:31:04 +0200

Hi Eric,

|Teco Boot wrote:
|
|> |Note
|> |    that IPv6 link-local addresses are assumed "on link".. However,
|the
|> |    utility of IPv6 link-locals is limited as specified in section
|6.2.
|>
|> We just specify "on-link" not equals "reachable".
|> "on-link" means here we don't send packets with a link-local as
|destination
|> to a default gateway.
|
|I can't parse your first sentence. Are you suggesting that we say
|something different in the draft? Or that we are already specifying
|this?

What I intended to say is that the assumption that addresses that
are "on-link" are reachable is not always true. In a MANET, interfaces
on the same link (= communication facility) can be out of transmission
range. Using links with full connectivity, "on-link" would mean
"reachable" (see remarks below...).

The draft does not specify what a link is, nor what "on-link" means.

|Note that in general (even on an Ethernet) all on-link addresses are not
|reachable; fe80::/10 (or fe80::/64) is on-link, but you don't get a
|response from all the addresses in that prefix.

OK, so now we can say MANET links are nothing special.
And I am even more convinced there is no problem with link-locals.

|> |At the end of section 6.2 add this text:
|> |
|> |A IPv6 link-local addresses must be assigned to each interface
|according
|> |to [RFC 4291]. Due to the connectivity properties of these links with
|> |neighbors constantly moving in and out of reachability, the link-
|local
|> |addresses are of very limited utility.
|>
|> Maybe, maybe not. I would not disqualify the characteristics.
|
|I explicitly tried to not forbid them - just have appropriate warnings.

OK. I agree upper layer protocols (applications) shall use ULA or globals.
We need to check address selection rules for this (RFC3484). ULA / globals
shall be preferred over link-locals.
For routing protocols, this is different.

|> | The known limitations are:
|> |  - Even if tested for uniqueness at one moment using Duplicate
|Address
|> |Detection [RFC 4862], a duplicate link-local address might appear as
|a
|> |neighbor the next moment and DAD would not detect that.
|>
|> I do not understand the difference with globals / ULAs.
|
|The autoconf WG would presumably come up with a protocol that has some
|ways to avoid non-unique addresses being allocated.

OK.

|> |  - There is no mechanism to ensure that IPv6 link-local are unique
|> |across multiple links, hence they can not be used to reliably
|identify
|> |routers.
|>
|> This is nothing new.
|> And the IETF routing protocol number 1 protocol runs perfect on it.
|
|ICMPv4 doesn't run on IPv6; Perhaps you meant ICMPv6, which I wouldn't
|call a routing protocol; I could call it an ES-IS protocol.

Sorry, I meant OSPF. And to be specific: OSPFv3.

|> Many others have no problem either.
|
|Duplicate address detection is there to handle unlikely, but very hard
|to detect failures. Hence it is no surprise that most of the time one
|can get away with not doing any DAD.

OK.

|> |  - Routers must not forward any packets with Link-Local source or
|> |    destination addresses to other links [RFC 4921]. And a Manet
|router
|> |that forwards packets by definition forwards from one link to another
|> |due to the undefined connectivity properties.
|>
|> There are multiple opinions on what a link is.
|> So I cannot agree on the text. But I know what you are saying.
|
|Part of the idea with the text in this but a stake in the ground in what
|a link is for these dynamic environments. I don't know if it makes sense
|to do that more directly in a separate section in the document, or have
|it be in this section, but I think it should be in the document.

Fully agreed we need such.

Teco.

|    Erik
|
|> |(The set of neighbors that
|> |heard the packet received by the router might be different than the
|set
|> |of neighbors that hears a packet transmitted by the router even if
|the
|> |same interface on the router is used for the two operations.)
|>
|> Yes, and this is exactly what makes it very powerful for neighborhood
|> Discovery [NHDP, OSPF, etc.].
|>
|>
|> Regards, Teco.
|>
|>
|>
|> |
|> |   Erik
|> |
|> |_______________________________________________
|> |Autoconf mailing list
|> [email-masked]
|> |https://www.ietf.org/mailman/listinfo/autoconf
|>

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 28 Jul 2009 00:38:52 -0700

> "reachable" (see remarks below...).

OK

> The draft does not specify what a link is, nor what "on-link" means.

It does so implicitly. If you want it to be more explicit, then you 
should direct that comment to the authors/DT. I tried to have this 
thread be about the suggested clarifications for IPv6 link-local addresses.

> And I am even more convinced there is no problem with link-locals.

The largest issue with link-locals is that they are not guaranteed to 
have the uniqueness properties you might assume.
Hence I think the utility of IPv6 link-locals is very limited.

> Sorry, I meant OSPF. And to be specific: OSPFv3.

I don't think you can assert that OSPFv3 works correctly by a simple 
test, since your EUI-64 derived link-locals are not likely to conflict 
in your test.

To show that OSPFv3 works you would actually have to run it with routers 
that (at least temporarily) have the same IPv6 link-local addresses yet 
are on the same link. That would help verify that such routers 
temporarily being within reach doesn't cause any confusion.

> Fully agreed we need such.

Care to propose text to the WG?

    Erik

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 28 Jul 2009 09:46:51 +0200

Hi Erik,

thanks for the text. It is ok for me.

Ulrich

On Mon, Jul 27, 2009 at 4:54 PM, Erik Nordmark <[email-masked]>wrote:

> A IPv6 link-local addresses must be assigned to each interface according to
> [RFC 4291]. Due to the connectivity properties of these links with neighbors
> constantly moving in and out of reachability, the link-local addresses are
> of very limited utility. The known limitations are:
>  - There is no mechanism to ensure that IPv6 link-local are unique across
> multiple links, hence they can not be used to reliably identify routers.
>   destination addresses to other links [RFC 4921]. And a Manet router that
> forwards packets by definition forwards from one link to another due to the
> undefined connectivity properties. (The set of neighbors that heard the
> packet received by the router might be different than the set of neighbors
> that hears a packet transmitted by the router even if the same interface on
> the router is used for the two operations.)
>
>  Erik
>
> _______________________________________________
> Autoconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/autoconf
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 28 Jul 2009 10:50:22 +0200

Erik Nordmark a écrit :
[...]
>  have the uniqueness properties you might assume.

That is because the 'subnet' and the 'link' are not defined (DAD on
something undefined is undefined too).

IMHO, and I will stop talking about this right after: we can't work IP
over something that we insist to not know what is (link-layers with
unknown properties, unpredictable and numerous movements and
disconnections, etc.)

Alex

>> |> This is nothing new. |> And the IETF routing protocol number 1
>> protocol runs perfect on it. | |ICMPv4 doesn't run on IPv6; Perhaps
>> you meant ICMPv6, which I wouldn't |call a routing protocol; I
>> could call it an ES-IS protocol.
>> 
>  test, since your EUI-64 derived link-locals are not likely to
> conflict in your test.
> 
> To show that OSPFv3 works you would actually have to run it with
> routers that (at least temporarily) have the same IPv6 link-local
> addresses yet are on the same link. That would help verify that such
> routers temporarily being within reach doesn't cause any confusion.
> 
>> |Part of the idea with the text in this but a stake in the ground
>> in what |a link is for these dynamic environments. I don't know if
>> it makes sense |to do that more directly in a separate section in
>> the document, or have |it be in this section, but I think it should
>> be in the document.
>> 
> _______________________________________________ Autoconf mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/autoconf
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 28 Jul 2009 01:58:28 -0700

Hello Alex,

> unknown properties, unpredictable and numerous movements and

Well, a lot of people have done it.  So, there must be
something wrong with your assumptions.

I'm serious!

In particular, IP can operate _without_ subnets entirely.
And, without multicast.  And, without DNS.  And...

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 28 Jul 2009 10:59:32 +0200

Hi Eric,

|The largest issue with link-locals is that they are not guaranteed to
|have the uniqueness properties you might assume.
|Hence I think the utility of IPv6 link-locals is very limited.

In another thread, we concluded link-locals do not differ from globals
that much on this subject.

|> Sorry, I meant OSPF. And to be specific: OSPFv3.
|
|I don't think you can assert that OSPFv3 works correctly by a simple
|test, since your EUI-64 derived link-locals are not likely to conflict
|in your test.

I tested and I read the spec. There is no problem in OSPFv3. Information
is maintained using RouterID and RouterID-InterfaceID. These are 32-bit
and 64-bit IDs and have nothing to do with addresses.

There would be a problem with next-hop addresses when there are duplicates.
No-one said we can accept duplicates on a link. We say the problem 
preventing them would be equal for link-locals and globals / ULA.

|> |Part of the idea with the text in this but a stake in the ground in
|what
|> |a link is for these dynamic environments. I don't know if it makes
|sense
|> |to do that more directly in a separate section in the document, or
|have
|> |it be in this section, but I think it should be in the document.
|>
|> Fully agreed we need such.
|
|Care to propose text to the WG?

I did. Recent posting (July 21):
===========
link       - a communication facility or medium over which nodes can
             communicate at the link layer, i.e., the layer
             immediately below IP. (out of RFC4861)

MANET link - 1-hop connectivity between two MANET interfaces. Called
             edge in graph theory.

MANET interface
           - MANET router interface with a MANET protocol enabled.

Radio link - a link with undetermined connectivity properties, such
             as asymmetry, non-transitivity and time-variation as
             described in
             [draft-baccelli-multi-hop-wireless-communication].
             Wireless links have often undetermined connectivity
             properties. 

Radio interface
           - MANET router interface to a Radio link.

The term "MANET link" needs another thought. The word "link" in 
"MANET link" would be associated with term "link", this is 
confusing. I am OK on any better term, but I still 
can't come up with something. "MANET edge" ?? No, this wouldn't 
work.
==========

Later on, Charlie P. and I discussed what "on-link" really means.
We have to choose between "on same communication facility" and
"in range". We concluded we better not use "on-link", as on a 
Radio link, we use MANET protocols for handling the more 
difficult connectivity characteristics. We need for example
Link Quality and Symmetry [NHDP] and Link Metrics / costs 
[dearlove-olsrv2-metrics], [OSPF-MANET].

This leaves open using link-locals for MANET protocols. 
It exactly provides what is needed: 1-hop connectivity.

Regards, Teco.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 28 Jul 2009 11:14:39 +0200

> something wrong with your assumptions.

I'm fine, I've been also told yesteerday than I'm 4 (four) years behind 
the state of the art :-)

> And, without multicast.  And, without DNS.  And...

Charlie the IPv6 over non-subnet non-multicast is wishful thinking. 
YEs, it is that little behaviour that could.

:-)

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 28 Jul 2009 02:29:49 -0700

> something undefined is undefined too).

Link is defined in RFC 2460 and I don't see any need to change that.
"Subnet", "subnet ID" and "subnet prefix" are defined in RFC 4291; FWIW 
I think you mean "subnet prefix" and not unspecific "subnet".

What is wrong with those definitions?

I think the struggle is with describing the practical implications of 
the time-variant, non-transitive and asymmetric reachability, and also 
some historical assumption that subnet prefix mapping to one link.

> unknown properties, unpredictable and numerous movements and

Why do you mean by "unknown properties"?

FWIW I use the unpredictable and numerous movements and disconnections 
technology know as 802.11 at the moment; seems to be usable for IP in 
practice ;-)

    Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 28 Jul 2009 12:00:05 +0200

Erik Nordmark a écrit :
>> Erik Nordmark a écrit : [...]
>>> The largest issue with link-locals is that they are not
>>> guaranteed to have the uniqueness properties you might assume.
>> 

It has a big problem in that it doesn't mention "wireless" in the
examples.  Were it to say "wireless" too, in addition Ethernets, ATM,
PPP then it would no longer be an invitation to consider wireless links
to not be the rfc2460 links.

> "Subnet", "subnet ID" and "subnet prefix" are defined in RFC 4291;
> FWIW I think you mean "subnet prefix" and not unspecific "subnet".
> 

I meant to say that in a wireless topology

               B
             A-|-C

where A can't hear C because too far, the link and subnet are undefined.
  People consider this topology (1) to not have any subnet prefix (the
"/128" recommendation, equally the "not on-link subnet"), sometimes I
consider it to (2) have two different subnets: one from A to B
one from B to C, or (3) one single subnet for all three and B is a
repeater, not router.

I think the existing subnet definitions don't cover these three cases I
mentioned just above.

>  the time-variant, non-transitive and asymmetric reachability, and
> also some historical assumption that subnet prefix mapping to one
> link.

I think the historical assumption a subnet prefix mapped on one link is
ok and is widely implemented.  I doubt it can be changed just like that.

(ok several prefixes and subnets on one link, but not ok no subnet on a
  link).

>> IMHO, and I will stop talking about this right after: we can't work
>> IP over something that we insist to not know what is (link-layers
>> with unknown properties, unpredictable and numerous movements and 
>> disconnections, etc.)
> 

I meant "undetermined connectivitiy properties", a term used in the
draft to mean the links considered by AUTOCONF.  It was explained as 
"unplanned connectivity properties" too.

> FWIW I use the unpredictable and numerous movements and
> disconnections technology know as 802.11 at the moment; seems to be
> usable for IP in practice ;-)

:-)

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 28 Jul 2009 04:10:42 -0700

> Hi Eric,

FWIW spelling is Erik.

> that much on this subject.

For what value of "we"? Where is the thread?

> preventing them would be equal for link-locals and globals / ULA.

If you neither have guaranteed to be unique interface IDs to form the 
IPv6-link locals, nor a robust protocol to test and detect duplicate 
addresses, then how can you claim that OSPFv3 would work reliably?

> I did. Recent posting (July 21):

Perhaps I should have been more explicit - text which clarifies the term 
  more than that is in RFC 2460. It we all agree that we just need the 
definition from 2460 then we are done.

> MANET link - 1-hop connectivity between two MANET interfaces. Called

Why is that term needed? Isn't it the same as "link"? It not, what is 
the difference?

>            - MANET router interface with a MANET protocol enabled.

Why do you need a specific term and not use use the RFC 2460 "interface" 
term?

>            - MANET router interface to a Radio link.

Why do you need to define those?
The reason I'm asking is that "radio" is rather generic, and would seem 
to include WiFi, 3G and other stuff where the L2 might ensure that there 
is transient and symmetric reachability.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 28 Jul 2009 04:22:55 -0700

> to not be the rfc2460 links.

Can you define what the term "example" means?
This is getting silly.
Do we also need to list avian carriers in the examples? Satelite links? 
Software emulated virtual links inside a hypervisor?

> where A can't hear C because too far, the link and subnet are undefined.

No, the definition of link and subnet prefix still hold.

> one from B to C, or (3) one single subnet for all three and B is a

Again, please don't use the term "subnet". Are you talking about a 
"subnet ID" or "subnet prefix"? Note that those are definitions about 
the address format, and not about reachability.

> I think the existing subnet definitions don't cover these three cases I

There is no definition of "subnet". There is a definition about "subnet 
prefix", which looks fine to me.

> (ok several prefixes and subnets on one link, but not ok no subnet on a

Back when RFC 1970 was published we introduced the notion that a link 
might not have any global prefixes that are on link. Sorry to spring 
this on you with only 13 years of warning ;-)

I think IPv4 operational practice for pt-pt links that have no subnet 
prefix associated with them dates a bit further back.

    Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 28 Jul 2009 14:06:16 +0200

Erik,

But if you say that the link definition and the subnet prefix 
definitions still hold in the    B   case then I don't understand
                                A-|-C
why we need the "/128" and the "not on-link subnet prefix" recommendations.

Anyways, just to try to converge, let me remind that my only interest is 
to avoid prohibiting the use of link-local addresses and that the text 
you provided for the draft seems ok to me.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 28 Jul 2009 16:17:50 +0200

Hi Erik, 

|> In another thread, we concluded link-locals do not differ from globals
|> that much on this subject.
|
|For what value of "we"? Where is the thread?

http://www.ietf.org/mail-archive/web/autoconf/current/msg01701.html
We have 62 bits random or unique EUI-64.
We might need DAD, for those who need further guarantee for uniqueness. 
I don't have any indication that DAD for globals is more easy than
for link-locals. But this is solution space.

|> |> Sorry, I meant OSPF. And to be specific: OSPFv3.
|> |
|> |I don't think you can assert that OSPFv3 works correctly by a simple
|> |test, since your EUI-64 derived link-locals are not likely to
|conflict
|> |in your test.
|>
|> I tested and I read the spec. There is no problem in OSPFv3.
|Information
|> is maintained using RouterID and RouterID-InterfaceID. These are 32-
|bit
|> and 64-bit IDs and have nothing to do with addresses.
|>
|> There would be a problem with next-hop addresses when there are
|duplicates.
|> No-one said we can accept duplicates on a link. We say the problem
|> preventing them would be equal for link-locals and globals / ULA.
|
|If you neither have guaranteed to be unique interface IDs to form the
|IPv6-link locals, nor a robust protocol to test and detect duplicate
|addresses, then how can you claim that OSPFv3 would work reliably?

Because OSPFv3 don't use addresses for the routing topology.

|> I did. Recent posting (July 21):
|> ===========
|> link       - a communication facility or medium over which nodes can
|>              communicate at the link layer, i.e., the layer
|>              immediately below IP. (out of RFC4861)
|
|Perhaps I should have been more explicit - text which clarifies the term
|  more than that is in RFC 2460. It we all agree that we just need the
|definition from 2460 then we are done.

Agreed on a link may not be "full connected"?
2460 / 4861 doesn't mandate this. A link is "just a communication facility".
I worked with ATM, FR etc. that were not full connected, and MANETs
does not differ here. Routing protocols hide this for hosts.

|> MANET link - 1-hop connectivity between two MANET interfaces. Called
|>              edge in graph theory.
|
|Why is that term needed? Isn't it the same as "link"? It not, what is
|the difference?

A "link" could be partial connected.
The "MANET link" is the elementary object in for example
[olsrv2]. It is a "link between two nodes", or "edge".
I need another term, as --* link-- is confusing.
But then, we need to rename OLSR......

|> MANET interface
|>            - MANET router interface with a MANET protocol enabled.
|
|Why do you need a specific term and not use use the RFC 2460 "interface"
|term?

There may be interfaces not running the protocols. For example, the
interface
with fixed connected hosts (like NEMO mobile network).
Sometimes, posting says "MANET interface MUST xxxx". Then I'm lost,
because I have no clue what is meant.

|> Radio link - a link with undetermined connectivity properties, such
|>              as asymmetry, non-transitivity and time-variation as
|>              described in
|>              [draft-baccelli-multi-hop-wireless-communication].
|>              Wireless links have often undetermined connectivity
|>              properties.
|>
|> Radio interface
|>            - MANET router interface to a Radio link.
|
|Why do you need to define those?
|The reason I'm asking is that "radio" is rather generic, and would seem
|to include WiFi, 3G and other stuff where the L2 might ensure that there
|is transient and symmetric reachability.

Yes, I understand you comment.
But I find "link with undetermined connectivity properties" rather
clumsy. We could introduce "lwucp" or "elwucpie". 

Regards, Teco

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 28 Jul 2009 07:22:18 -0700

Hello Teco,

> for link-locals. But this is solution space.

DAD for globals is easier, because packets using global IP
addresses can be forwarded.  Forwarding may be necessary
to guarantee uniqueness across non-local regions of the
network.

This should count as an "indication".

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 28 Jul 2009 08:11:34 -0700

> http://www.ietf.org/mail-archive/web/autoconf/current/msg01701.html

Did the WG chairs declare some form of consensus on this subject?

The thread seems to say that *if* we've solved DAD for link-locals 
*then* that can be used to solve DAD for globals. But that doesn't mean 
that the inverse is true. Hence I don't see how you can say that they 
are the same or similar.

> for link-locals. But this is solution space.

I do have an example.
For Ethernets DHCPv6 is an example of a way to make DAD simpler; a 
logically single location of the state of which addresses are allocated 
to whom avoids duplicates.
(I'm in no way advocating DHCPv6 as a solution; it is merely an example 
that global address allocation can avoid the DAD we need for link-locals.)

> Because OSPFv3 don't use addresses for the routing topology.

If the routing topology is perfect, but data packets get misdelivered or 
duplicated (due to duplicate link-locals), does that mean than routing 
is working?

> But then, we need to rename OLSR......

Do you mean that the connectivity has been checked to be symmetric, or 
something else?

> because I have no clue what is meant.

Yes, but we don't seem to need terms like "OSPF interface" or "BGP 
interface" to describe how those protocols work. (They might use 
different terms like adjacencies to describe how the protocol works.)

> clumsy. We could introduce "lwucp" or "elwucpie". 

But that isn't specific to radio. I've had Ethernet links with 
asymmetric connectivity, and a broken Ethernet switch can create 
non-transitive connectivity.
The difference is in probability.

Thus a link with high loss probability, asymmetric and non-transitive 
connectivity is just the most general form of a link. Trying to pick 
separate names for such a thing based on probabilities isn't very 
helpful, nor is tying the name to a current technology used to construct 
links with those properties.

    Erik

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 28 Jul 2009 17:22:49 +0200

Hi Charlie,

|> We might need DAD, for those who need further guarantee for
|uniqueness.
|> I don't have any indication that DAD for globals is more easy than
|> for link-locals. But this is solution space.
|>
|
|DAD for globals is easier, because packets using global IP
|addresses can be forwarded.  Forwarding may be necessary
|to guarantee uniqueness across non-local regions of the
|network.
|
|This should count as an "indication".

We run DAD before sending a packet with this address. Or am
I missing something?
When we worked out a mechanism, it could easily support both.
Maybe link-local is simpler. So I have an opposite 
indication also:-)

Regards, Teco

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 28 Jul 2009 18:12:44 +0200

Hi Erik,

|> http://www.ietf.org/mail-archive/web/autoconf/current/msg01701.html
|
|Did the WG chairs declare some form of consensus on this subject?

No.

|The thread seems to say that *if* we've solved DAD for link-locals
|*then* that can be used to solve DAD for globals. But that doesn't mean
|that the inverse is true. Hence I don't see how you can say that they
|are the same or similar.

This is evaluation of multi-hop DAD solutions. I'll postpone answering.
Still, I do not see much difference.

|> We have 62 bits random or unique EUI-64.
|> We might need DAD, for those who need further guarantee for
|uniqueness.
|> I don't have any indication that DAD for globals is more easy than
|> for link-locals. But this is solution space.
|
|I do have an example.
|For Ethernets DHCPv6 is an example of a way to make DAD simpler; a
|logically single location of the state of which addresses are allocated
|to whom avoids duplicates.
|(I'm in no way advocating DHCPv6 as a solution; it is merely an example
|that global address allocation can avoid the DAD we need for link-
|locals.)

I think DHCP depends on another token (IA, DUID).
So I say duplicate avoidance is distributed.
How is DAD on IA/DUID implemented?
What makes link-locals based on EUI-64 different from globals based on
DUID-LL?

|> |If you neither have guaranteed to be unique interface IDs to form the
|> |IPv6-link locals, nor a robust protocol to test and detect duplicate
|> |addresses, then how can you claim that OSPFv3 would work reliably?
|>
|> Because OSPFv3 don't use addresses for the routing topology.
|
|If the routing topology is perfect, but data packets get misdelivered or
|duplicated (due to duplicate link-locals), does that mean than routing
|is working?

This depends on the layer-2 technology used.
With only P2P links, using only a single link-local address, I do not
expect a problem. 
Using duplicate link-locals on multi-access links would introduce L2
problems,
and DAD would help little or not at all.

|> |> MANET link - 1-hop connectivity between two MANET interfaces.
|Called
|> |>              edge in graph theory.
|> |
|> |Why is that term needed? Isn't it the same as "link"? It not, what is
|> |the difference?
|>
|> A "link" could be partial connected.
|> The "MANET link" is the elementary object in for example
|> [olsrv2]. It is a "link between two nodes", or "edge".
|> I need another term, as --* link-- is confusing.
|> But then, we need to rename OLSR......
|
|Do you mean that the connectivity has been checked to be symmetric, or
|something else?

Yes, the "MANET links" status needs to be checked. State can also be
asymmetric, bad (do_not_use) or lost. Or have a cost value.

|> |> Radio link - a link with undetermined connectivity properties, such
|> |>              as asymmetry, non-transitivity and time-variation as
|> |>              described in
|> |>              [draft-baccelli-multi-hop-wireless-communication].
|> |>              Wireless links have often undetermined connectivity
|> |>              properties.
|> |>
|> |> Radio interface
|> |>            - MANET router interface to a Radio link.
|> |
|> |Why do you need to define those?
|> |The reason I'm asking is that "radio" is rather generic, and would
|seem
|> |to include WiFi, 3G and other stuff where the L2 might ensure that
|there
|> |is transient and symmetric reachability.
|>
|> Yes, I understand you comment.
|> But I find "link with undetermined connectivity properties" rather
|> clumsy. We could introduce "lwucp" or "elwucpie".
|
|But that isn't specific to radio. I've had Ethernet links with
|asymmetric connectivity, and a broken Ethernet switch can create
|non-transitive connectivity.
|The difference is in probability.
|
|Thus a link with high loss probability, asymmetric and non-transitive
|connectivity is just the most general form of a link. Trying to pick
|separate names for such a thing based on probabilities isn't very
|helpful, nor is tying the name to a current technology used to construct
|links with those properties.

OK, let's go for elwucpie.
I'm in for any better suggestion. 

Regards, Teco.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 28 Jul 2009 18:19:00 +0200

> Did the WG chairs declare some form of consensus on this subject?

The chairs are currently, with the minute takers, compiling the  
meeting minutes for posting on-line.

Once that's done, and the minutes are available for the list to see,  
we'll summarize the perceived consensus in the room in Stockholm, and  
call for consensus on the list.

Sincerely,

Thomas

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 29 Jul 2009 08:43:51 +0200

Hi Eric,

Back to your proposed text. I worked on refinements, so I can agree on it.

|    Note

If we add reachable to "on-link", it would be much clearer.
New text:

  If the link to which an interface connects enables no assumptions of
  connectivity to other interfaces, the only addresses which can be
  assumed "on-link" or reachable, are the address(es) of that interface
  itself. Note that IPv6 link-local addresses are assumed "on-link",
  either reachable or not. This makes the utility of IPv6 link-locals 
  limited as specified in section 6.2.

On the second part, I agree upper layer protocols that do not understand
the details of connectivity in a MANET better not use link-locals.
And we can leave open if MANET protocols use link-locals or not.
I removed some text, that is in my opinion unneeded or lead to discussions
on for example what is a link?, what is a MANET link? etc.

Old text:
|addresses are of very limited utility. The known limitations are:
|due to the undefined connectivity properties. (The set of neighbors that

New text:

A IPv6 link-local addresses must be assigned to each interface according
to [RFC 4291]. Due to the connectivity properties of these links with
neighbors constantly moving in and out of reachability, the link-local
addresses are of very limited utility for applications that are not aware.
The known limitations are:
 - Even if tested for uniqueness at one moment using Duplicate Address
   Detection [RFC 4862], a duplicate link-local address might appear as a
   neighbor the next moment and DAD would not detect that.
 - Routers must not forward any packets with Link-Local source or
   destination addresses to other links [RFC 4921]. In practice,
   IPv6 routers do not forward these packets, even on the same link.

Now I and many others can keep protocols using link-locals, when dealt
with the limitations. And we are free on not using link-locals.

OK with this?

Regards, Teco.

---

From: "Holtzer, A.C.G. (Arjen)" <[email-masked]>
Date: Thu, 30 Jul 2009 14:09:55 +0200

Hi all,

I agree on not prohibiting the use of LLs. And I agree the text should
also reflect the possible limitations of their usage. I'm not sure if
the text was meant to prohibit the use of LLs, but following the
discussion I feel the limitation seems to be formulated relatively
strong. See comments inline. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Erik Nordmark
> Sent: maandag 27 juli 2009 16:55
> To: [email-masked]
> Subject: [Autoconf] Suggested text on link-locals
> 
> 
> A IPv6 link-local addresses must be assigned to each 
> interface according to [RFC 4291]. Due to the connectivity 
> properties of these links with neighbors constantly moving in 
> and out of reachability, the link-local addresses are of very 
> limited utility. The known limitations are:
>   - Even if tested for uniqueness at one moment using 
> Duplicate Address Detection [RFC 4862], a duplicate 
> link-local address might appear as a neighbor the next moment 
> and DAD would not detect that.

Ok.

>   - There is no mechanism to ensure that IPv6 link-local are 
> unique across multiple links, hence they can not be used to 
> reliably identify routers.

>From the discussion: there's agreement that DAD cannot always guarantee
address uniqueness in mobile scenarios, but on the other hand using
random interface ID's for address generation seems to have a very low
probability of generating duplicates (see the draft Carlos referred to:
http://tools.ietf.org/html/draft-soto-mobileip-random-iids-00). So in
many cases this can be reliable enough. So maybe the text should say:

"IPv6 link-local addresses can not be entirely ensured to be unique
across multiple links using existing mechanisms in all situations, in
which they can not be used to reliably identify routers." 

People requiring it in their scenario can then still use link local
addresses and the Autoconf WG can decide if they feel the need to create
a mechanism that does ensure address uniqueness in all cases for LLs or
not. Of course, one may ask: what are the situations/scenarios mentioned
here?

Regards,
Arjen
>     destination addresses to other links [RFC 4921]. And a 
> Manet router that forwards packets by definition forwards 
> from one link to another due to the undefined connectivity 
> properties. (The set of neighbors that heard the packet 
> received by the router might be different than the set of 
> neighbors that hears a packet transmitted by the router even 
> if the same interface on the router is used for the two operations.)
> 
>    Erik
> 
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html