Subject: [Autoconf] Link with undetermined connectivity properties

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

AUTOCONFers,

The draft-baccelli-autoconf-adhoc-addr-model-01 mentions at
several places Links with undetermined connectivity properties.  And
makes these Links the central point of the draft.

This is a problem.

We can't work with things we don't understand.

As far as I know there is no link with undetermined connectivity
properties.  The links I am aware of do have determined connectivity
properties or, at least, properties desired by their designers as set
in specs.

True, Links may diverge from specs: accidents, aging of components,
buggy implementations, operator's errors.  No surprise, these factors
will affect any new method of AUTOCONF which we're about to write.

In this sense, I don't understand why do we have to deal with Links with
undetermined connectivity properties.

What do you think?

Alex

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 21 Jul 2009 13:56:58 +0200

Alex,
I understand your concern. However, I do not agree.

Saying that a link has "undetermined connectivity properties" does not mean
that we do not understand this link. It rather means that for this type of
link, there is no connectivity property that is planned in advance -- quite
a difference ;)

Would it be clearer for you if instead of using the word "undetermined",
there was "not pre-determined"? So we would talk about links with "no
pre-determined connectivity properties"?

Cheers
Emmanuel

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Jul 2009 14:17:53 +0200

Emmanuel Baccelli a écrit :
> Saying that a link has "undetermined connectivity properties" does not 
> mean that we do not understand this link. It rather means that for this 
> type of link, there is no connectivity property that is planned in 
> advance -- quite a difference ;) 

:-)

Well yes, but there is at least one planned connectivity property for 
any link - the connectivity is established after link establishment.

One can't say that this connectivity property is not planned in advance.

> pre-determined connectivity properties"? 

"undetermined" and "not pre-determined" are equivalent to my reading, 
(thus it isn't clearer); except if you meant "pre not-determined" - 
previously we may have thought it's not-determined and now we think it 
is determined.  It's a stretch...

I think I will be happily satisfied if the first paragraphs and cases of 
each section were for describing the determined cases and exceptions 
(unplanned and not pre-determined) came explained in second paragraphs, 
or appendices.

For example the IPv6 link-layer addresses should come first.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 21 Jul 2009 15:02:28 +0100

> One can't say that this connectivity property is not planned in
advance.

I can certainly say that I didn't plan whether A and B would be
directly connected, i.e. have a link between them, in advance.
I can only plan that if the physics etc. permit it then I will
(probably) establish it and use it.

> For example the IPv6 link-layer addresses should come first.

The document clearly says this is not agreed.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Jul 2009 16:09:59 +0200

Dearlove, Christopher (UK) a écrit :
>> Well yes, but there is at least one planned connectivity property
>> for any link - the connectivity is established after link
>> establishment.
>> 
> directly connected, i.e. have a link between them, in advance. I can
> only plan that if the physics etc. permit it then I will (probably)
> establish it and use it.

I agree, sometimes connections are possible, and the first obvious thing
to do when a connection is possible is to use an IPv6 link-local address.

> The document clearly says this is not agreed.

I personally do not agree with the document as it stands with respect to
link-local addresses.

Why do you oppose the use of IPv6 link-local addresses?  And what do
others think please?

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 21 Jul 2009 15:21:11 +0100

> I personally do not agree with the document as it stands with respect
to

You can't diagree with the document in that it says

"The following issues were extensively discussed among the design
team, without reaching a conclusion."

You may think there should be a conclusion, you may think you know
what it should be. But you can't disagree with that the Design Team
has (currently at least) failed to reach an agreement. (Yes, there's
some discussion, but it only points out issues, it doesn't form a
conclusion.)

> Why do you oppose the use of IPv6 link-local addresses?

I didn't say I did, you are misreading what I said. I said
"The document clearly says this is not agreed." And that's
a fact. I made no personal comment on the matter in any way.
The disagreement I referred to is among the document contributors,
of which I am not one.

---

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

|Why do you oppose the use of IPv6 link-local addresses?  And what do
|others think please?

For IPv6, routers have link-locals for running some protocols (e.g. sending
ND RA or OSPFv3 packets).
If one doesn't need those protocols (e.g. no IPv6), I say link-locals are
not mandatory.

I think it makes sense an Autoconf protocol that works for IPv6 and that is
independent of a routing protocol makes use of IPv6 link-locals.

I would run any IPv6 MANET protocol with link-locals. Repeating myself here.

Teco.

|Alex

---

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

> some discussion, but it only points out issues, it doesn't form a

I could however provide my comments on the list about the IPv6 
link-local addresses.  And I hope more people will comment on the use of 
IPv6 link-local addresses in ad-hoc networks, such that we could help 
the DT reach a conclusion.

> a fact. I made no personal comment on the matter in any way.

Ah, I understand.  But I would be very curious to know what you think 
about the use of IPv6 link-local addresses in the context of ad-hoc 
networks.  Shouldn't they be used?  Should one avoid them?  Would 
implementations block them?  Etc.  Any other point?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Jul 2009 16:32:45 +0200

Teco Boot a écrit :
> For IPv6, routers have link-locals for running some protocols (e.g.
> sending ND RA or OSPFv3 packets). If one doesn't need those protocols
> (e.g. no IPv6), I say link-locals are not mandatory.

Well, I think we need IPv6 in AUTOCONF, thus we need IPv6 link-local 
addresses mandatorily.

> I think it makes sense an Autoconf protocol that works for IPv6 and
> that is independent of a routing protocol makes use of IPv6
> link-locals.

I agree, one can build an AUTOCONF protocol that works for IPv6, that is 
not OSPF, and that uses IPv6 link-local addresses.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 21 Jul 2009 09:13:16 -0700

Hello Alex,

> Why do you oppose the use of IPv6 link-local addresses?  And what do

I was part of the discussion on this point.  Quoting some
previous email:

>
>
>> |> => you can presumably always communicate with neighbor using
>> |> => link-local addresses.
>> |
>> |Yes, of course, once it is known that a node is a neighbor.
>>
>>
>  You have to know that
> the node _is_ a _neighbor_.  That means within range
> and within range RIGHT NOW.  How are you going to
> know that?  How are you going to invalidate the
> link-local address as soon as _any_ other node
> becomes a new neighbor of the node? 

I am myself in favor of enabling the use of link-local
addresses, once these questions are answered.

Up until now no one has been able to answer, and we can
demonstrably make excellent progress even without knowing
the answers.  I think the right thing to do is to delay the
standardization of using link-locals within our presumed
[autoconf] networks.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Jul 2009 18:37:09 +0200

Hello Charles,

Charles E. Perkins a écrit :
>> I agree, sometimes connections are possible, and the first obvious 
>> thing to do when a connection is possible is to use an IPv6 
>> link-local address.
>> 
>> I personally do not agree with the document as it stands with 
>> respect to link-local addresses.
>> 
>> Why do you oppose the use of IPv6 link-local addresses?  And what 
>> do others think please?
> 
> I was part of the discussion on this point.  Quoting some previous 
> email:
> 
>> 
>> 
>>> |> => link-local addresses. | |Yes, of course, once it is known 
>>> that a node is a neighbor.
>>> 
>>> 
>> You have to know that the node _is_ a _neighbor_.  That means 
>> within range and within range RIGHT NOW.  How are you going to know
>>  that?

By sending it an NS, it's standardized, it's NUD.

>> How are you going to invalidate the link-local address as soon as 
>> _any_ other node becomes a new neighbor of the node?

With NUD.

> I am myself in favor of enabling the use of link-local addresses, 
> once these questions are answered.
> 
> Up until now no one has been able to answer, and we can demonstrably 
> make excellent progress even without knowing the answers.

Anybody discarded NUD?

> I think the right thing to do is to delay the standardization of 
> using link-locals within our presumed [autoconf] networks.

I think a good thing to do is to put it first in the discussions.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 21 Jul 2009 09:49:22 -0700

Hello Alex,

Alexandru Petrescu wrote:
>
>>>>
>>> You have to know that the node _is_ a _neighbor_.  That means within 
>>> range and within range RIGHT NOW.  How are you going to know
>>>  that?
>

And re-sending.  And waiting for answers.

>>> _any_ other node becomes a new neighbor of the node?

I'd like to see you try this in real life.  And
then please  report back your maximal handover
outage while the nodes are enjoying life in the NUD.

> I think a good thing to do is to put it first in the discussions.

That was easy, wasn't it!  No pain whatsoever.  I can't
imagine why nobody else thought of it.

Regards,
Charlie P.

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 21 Jul 2009 12:53:18 -0400

>> becomes a new neighbor of the node? 
Please don't get me wrong - I'm not trying to re-start the firestorm 
here. I think the AUTOCONF document as-is represents consensus on some 
fundamental level, and advances the discussion. It's a good thing. 
Referencing the above included email - I don't have all of the context 
of the thread, but the above statement confuses me a bit. If the concern 
is that you could theoretically have duplicate addresses, then isn't 
that what DAD is for? And concerning duplicate addresses, how is this 
any different from, say, duplicate IPv4 addresses?

As I said, I'm OK with the document as it stands for now, complete with 
the lack of consensus on V6 link-local addresses. That being said, I've 
had some experiences with deploying MANETs using V6 link-locals; it's 
worked like a champ. So I'm with Teco where link-locals are concerned -- 
if your deployment lets you utilize them (e.g. an OSPFv3 
implementation), they work very well.

Regards,
Stan

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

---

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

Hello Stan,

Stan Ratliff wrote:
>   ...   the above statement confuses me a bit. If the concern is that 
> you could theoretically have duplicate addresses, then isn't that what 
> DAD is for? And concerning duplicate addresses, how is this any 
> different from, say, duplicate IPv4 addresses?

It's not much different.  The point overall is that DAD isn't engineered
for such networks where topology can change on a timescale shorter
than DAD protocol sequences could handle.  And, the problem gets
worse as DAD is required to traverse a greater number of radio links.

There was a lot of discussion earlier about "weak-DAD" vs.
"strong-DAD".  The discussion didn't really reach many useful
conclusions, but did open the door for some really great puns.
So it was definitely worthwhile for me.

>
> As I said, I'm OK with the document as it stands for now, complete 
> with the lack of consensus on V6 link-local addresses. That being 
> said, I've had some experiences with deploying MANETs using V6 
> link-locals; it's worked like a champ. So I'm with Teco where 
> link-locals are concerned -- if your deployment lets you utilize them 
> (e.g. an OSPFv3 implementation), they work very well.

Yes, I also agree with this.  As I mentioned, I am also in
favor of enabling the use of link-locals -- whenever possible.
I think that if someone wanted to contribute a document
delimiting the sphere of applicability for DAD and link-locals
that would be a fine thing, and would get my support and
attention.

Regards,
Charlie P.

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 21 Jul 2009 13:07:44 -0400

Charles E. Perkins wrote:
>> you could theoretically have duplicate addresses, then isn't that 
>> what DAD is for? And concerning duplicate addresses, how is this any 
Fair enough. So as I read this, there's an unsolved problem here in 
general dealing with duplicate addresses -- regardless of whether they 
are V4 or V6. I don't think the WG should come to a screeching halt and 
deal with the problem before making any progress, but it's something we 
should at least discuss.

Regards,
Stan

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 21 Jul 2009 10:17:48 -0700

Hello Stan,

Stan Ratliff wrote:
>>   ...   DAD isn't engineered
> are V4 or V6. I don't think the WG should come to a screeching halt 
> and deal with the problem before making any progress, but it's 
> something we should at least discuss.

Yes, it should be discussed in solution space (so to speak).
The problem with duplicate addresses has received quite a bit
of attention in the past, as I mentioned.  I can try to unearth some
of that discussion and send pointers to the list.  As far as I know,
there has never been any perfect solution published.  Attempts
to reduce the impace of the problem include
- (the obvious) pick highly random local addresses
- (more obvious) use guaranteed unique MAC addresses
- attach more information to the link-local addresses, for
    instance neighborhood information.  This is on the theory
    that two different nodes that unfortunately have the same
    link-local address will still have different neighborhoods
- (for the despotic dictators) blast the network with DAD from
   every node once a second or <pick your poisonous interval>
- clever routing annotations to reduce the impact of duplicate
   address faults
- distribute unique cryptographic keys to all nodes

I'm sure you get the picture.  None of these solutions is
really universally applicable.  But at least it's a lot of fun
to talk about them.

Regards,
Charlie P.

---

From: Rafael Roque <[email-masked]>
Date: Tue, 21 Jul 2009 14:21:15 -0300

On Tue, Jul 21, 2009 at 2:17 PM, Charles E. Perkins <
[email-masked]> wrote:

>> general dealing with duplicate addresses -- regardless of whether they are
>> V4 or V6. I don't think the WG should come to a screeching halt and deal
>> with the problem before making any progress, but it's something we should at
>> least discuss.
>>
>

I know that no autoconf mechanisms are being discussed but...
What about existing ad-hoc addressing allocation methods that suppress the
need for DAD, that is, guarantees address uniqueness, they will not get into
account?

Regards,
Rafael

-- 
Rafael Roque Aschoff
GPRT/UFPE

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 21 Jul 2009 19:21:40 +0200

It was no fun to handle a DAD DOS attack.
I remember this like yesterday. It was in the SNA days...
Am I getting old ?? But I am experienced !!
Teco.

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens
|Charles E. Perkins
|Verzonden: dinsdag 21 juli 2009 19:18
|Aan: Stan Ratliff
|CC: [email-masked]
|Onderwerp: Re: [Autoconf] Link-locals vis-à-vis the new [autoconf]
|document
|
|
|Hello Stan,
|
|Stan Ratliff wrote:
|>
|>>
|>>   ...   DAD isn't engineered
|>> for such networks where topology can change on a timescale shorter
|>> than DAD protocol sequences could handle.  And, the problem gets
|>> worse as DAD is required to traverse a greater number of radio links.
|>>
|>> There was a lot of discussion earlier about "weak-DAD" vs.
|>> "strong-DAD".  The discussion didn't really reach many useful
|>> conclusions, but did open the door for some really great puns.
|>> So it was definitely worthwhile for me.
|>>
|> Fair enough. So as I read this, there's an unsolved problem here in
|> general dealing with duplicate addresses -- regardless of whether they
|> are V4 or V6. I don't think the WG should come to a screeching halt
|> and deal with the problem before making any progress, but it's
|> something we should at least discuss.
|
|Yes, it should be discussed in solution space (so to speak).
|The problem with duplicate addresses has received quite a bit
|of attention in the past, as I mentioned.  I can try to unearth some
|of that discussion and send pointers to the list.  As far as I know,
|there has never been any perfect solution published.  Attempts
|to reduce the impace of the problem include
|- (the obvious) pick highly random local addresses
|- (more obvious) use guaranteed unique MAC addresses
|- attach more information to the link-local addresses, for
|    instance neighborhood information.  This is on the theory
|    that two different nodes that unfortunately have the same
|    link-local address will still have different neighborhoods
|- (for the despotic dictators) blast the network with DAD from
|   every node once a second or <pick your poisonous interval>
|- clever routing annotations to reduce the impact of duplicate
|   address faults
|- distribute unique cryptographic keys to all nodes
|
|I'm sure you get the picture.  None of these solutions is
|really universally applicable.  But at least it's a lot of fun
|to talk about them.
|
|Regards,
|Charlie P.
|
|_______________________________________________
|Autoconf mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/autoconf

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 21 Jul 2009 13:24:21 -0400

SNA?!? When I want to reference an old, out-of-date networking 
technology, I normally refer to Wang-Net... ;-) ;-) ;-)

Stan

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 21 Jul 2009 20:13:08 +0200

I think the DAD discussion leads us from more important topics.

Link-locals are fine for MANET protocols, neighborhood discovery
and other communication to nearby / in  range nodes. But using
them for other traffic can introduce problems. When nodes move,
the direct connection is broken. So in a MANET, usage of domain
wide or global is preferred, even when a destination node and 
source node have link-locals. This, because loss of connection
should be circumvented. Is this an update of RFC3483 ??

I'll take some beers before reading back and understand 3484 rule 2:
> Rule 2:  Prefer appropriate scope.
>  If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB
>  and otherwise prefer SA.  Similarly, if Scope(SB) < Scope(SA): If
>  Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB.

Teco.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 21 Jul 2009 11:13:43 -0700

Hello Rafael,

Rafael Roque wrote:
>
>
>       ...    None of these solutions is
>     really universally applicable. 
>
>
> What about existing ad-hoc addressing allocation methods that suppress 
> the need for DAD, that is, guarantees address uniqueness, they will 
> not get into account?

Which existing allocation methods did you mean?

Regards.
Charlie P.

---

From: Rafael Roque <[email-masked]>
Date: Tue, 21 Jul 2009 15:34:53 -0300

Thanks for reply Charles.

> Which existing allocation methods did you mean?

There are some examples, like Prime
DHCP<http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01496591>,
and Buddy System. <http://www.utdallas.edu/%7Eravip/papers/milcom02.pdf>
Prime DHCP uses a distributed allocation function that assures unique number
generation, while Buddy System splits address allocation space by half for
each configuration process.

Regards.
R. Rafael.

-- 
Rafael Roque Aschoff
GPRT/UFPE

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 21 Jul 2009 12:10:33 -0700

Hello Rafael,

Those protocols would definitely belong in a discussion
about eliminating duplicate addresses.  Thanks for
sharing the citations.  I think it is fair to say that the
work in [autoconf] should proceed without waiting
for standardization work to begin on these proposals.
As far as I know neither of these systems have seriously
been considered in any working group of the IETF before
now.  I had suggested the buddy system for possible
consideration during the [autoconf] BOFs, and Prophet
is interesting but, at least for me at the time, had
robustness issues that I thought were not well understood.
Prime DHCP seems to be a useful refinement.

Nevertheless, pushing these ideas into a Proposed
Standard or even Experimental RFC is more work
than I see anyone volunteering to do....  or, are
you volunteering?

Regards,
Charlie P.

Rafael Roque wrote:
> There are some examples, like Prime DHCP 
> <http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01496591>, and 
> Buddy System. <http://www.utdallas.edu/%7Eravip/papers/milcom02.pdf>
> Prime DHCP uses a distributed allocation function that assures unique 
> number generation, while Buddy System splits address allocation space 
> by half for each configuration process.
>
>
> Regards.
> R. Rafael.
>
>
>
> -- 
> Rafael Roque Aschoff
> GPRT/UFPE
>

---

From: Rafael Roque <[email-masked]>
Date: Tue, 21 Jul 2009 17:32:41 -0300

I'm currently working on a new proposal that is similar to Prime by the use
of distributed allocation function, and similar to buddy system by the good
address space distribution.  It could be difficult to do both works right
now.

But I thing that eliminating duplicate addresses could lead to changes in
address model discussed here, don’t you think?

Ps.: I must say sorry for any misspelling words or expressions, since
English is not my first language!

Regards.
R. Rafael.

Charles wrote:

>> There are some examples, like Prime DHCP <
>> http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01496591>, and Buddy
>> System. <http://www.utdallas.edu/%7Eravip/papers/milcom02.pdf>
>> number generation, while Buddy System splits address allocation space by
>> half for each configuration process.
>>
>>
>> Regards.
>> R. Rafael.
>>
>>
>>
>> --
>> Rafael Roque Aschoff
>> GPRT/UFPE
>>
>>
>

-- 
Rafael Roque Aschoff
GPRT/UFPE

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Jul 2009 00:04:13 +0200

Charles E. Perkins a écrit :
>>>> within range and within range RIGHT NOW.  How are you going to
>>>> know that?
>> 

I suppose that's the only way one can do when one is not sure a neighbor
is present at an instant t.  It's called NUD but if one doesn't like one
couldn't design anything more intelligent than just wait for an answer.

I don't see what you could suggest otherwise.  You may see otherwise.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 21 Jul 2009 15:38:50 -0700

Hello Alex,

I'm not suggesting I can design a better NUD.

I'm suggesting that we can do address autoconfiguration without
having to do NUD.  That is, we _can_.  If you can design a
better address autoconfiguration that uses NUD, that will be
great.  In the meantime, we want to have address autoconfiguration,
without having to figure out how to do NUD (and, without
having to wait to figure out how to do link-local addresses).

In other words, addresses could be assigned whether or
not a neighbor is still neighboring, or unreachable, or able
to verify that it satisfies the necessary properties that have
to be satisfied by link-local addresses.

What I thought you were mandating is that we solve
those problems before getting address autoconfiguration
to work.  My belief is that we don't have to.

Regards,
Charlie P.

---

From: Rafael Roque <[email-masked]>
Date: Wed, 22 Jul 2009 00:14:35 -0300

> to be satisfied by link-local addresses.

I think i have misunderstood something but, if there are no neighbours,
there is no need for addresses too, since the node cannot communicate to
anyone!

Anyway, this kind of address assign is clearly going into stateless
direction, where no network knowledge is need, even neighborhood. This is
the idea?

-- 
Rafael Roque Aschoff
GPRT/UFPE

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 21 Jul 2009 21:32:16 -0700

Hello Rafael,

I did not mean to imply stateless.

Rafael Roque wrote:
> I think i have misunderstood something but, if there are no 
> neighbours, there is no need for addresses too, since the node cannot 
> communicate to anyone!

Here, I meant that a node which had been known to be a neighbor
may not really be a neighbor any longer.  I didn't mean to say that
there weren't any neighbors!  With no neighbors, a node is pretty
much guaranteed that its autoconfigured address will be unique
in its connected domain.

> direction, where no network knowledge is need, even neighborhood. This 
> is the idea?

No, sorry for using such imprecise language.

The idea is to maintain enough state to get the job
done, but to minimize the amount of state that has
to be kept.  At least that is one idea -- as you can
see, there are many competing ideas.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Jul 2009 12:04:16 +0200

> to be satisfied by link-local addresses.

Sounds as if we decouple de necessity to do DAD and NUD (Neighbor 
Unreachability Detection) from the use of IPv6 link-local addresses then 
we could be free to let nodes configure IPv6 link-local addresses, as 
part of the AUTOCONF IPv6 practical addressing model.

And state so in the draft(?)

Alex

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 22 Jul 2009 13:18:41 +0200

Hi Alex,

On Wed, Jul 22, 2009 at 12:04 PM, Alexandru Petrescu <
[email-masked]> wrote:
> Unreachability Detection) from the use of IPv6 link-local addresses then we
> could be free to let nodes configure IPv6 link-local addresses, as part of
> the AUTOCONF IPv6 practical addressing model.
>

Wouldn't that go a little too far in the solution space, for this particular
document? This document is not supposed to propose an autoconfiguration
solution...

Emmanuel

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Jul 2009 14:40:05 +0200

Hi Emmanuel,

Emmanuel Baccelli a écrit :
> Hi Alex,
> 
> On Wed, Jul 22, 2009 at 12:04 PM, Alexandru Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     Unreachability Detection) from the use of IPv6 link-local addresses
>     then we could be free to let nodes configure IPv6 link-local
>     addresses, as part of the AUTOCONF IPv6 practical addressing model.
> 
> Wouldn't that go a little too far in the solution space, for this 
> particular document? This document is not supposed to propose an 
> autoconfiguration solution...

But isn't it incomprehensible to read about links with unknown 
connectivity properties?  Maybe recommending IPv6 link-local addresses 
without DAD and without NUD would sound more comprehensible.

The draft already makes a few very strong recommendations in forbidding 
the use of prefixes different than /128 which I find also too far in the 
solution space.

Alex

> 
> 
> Emmanuel 
> 
> 
> ------------------------------------------------------------------------
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Jul 2009 17:08:58 +0200

Charles E. Perkins a écrit :
>>> In other words, addresses could be assigned whether or not a
>>> neighbor is still neighboring, or unreachable, or able to verify
>>> that it satisfies the necessary properties that have to be
>>> satisfied by link-local addresses.
>> 
> If  DAD and NUD are unsuitable for working with mobile devices, then
> perhaps they should not be required for establishing the
> characteristics of link-local addresses.
> 
> But that's not really the relevant point.  So far, I didn't see
> consensus for any  broadly applicable procedure for establishing
> link-local addresses, regardless of DAD and NUD.  Until you can show 
> that, I think the document cannot mandate the use of link-local
> addresses.  The document also does not prohibit their use.

Hello Charlie,

I don't see what you mean by lack of consensus on a broadly applicable 
procedure for establishing link-local addresses, but the way the IPv6 
link-local addresses are formed is standardized, there is consensus, 
it's a broadly applicable procedure.  There are only a _few_ links on 
which there is no consensus, counted on one hand's fingers, and they're 
not MANET-like.

> What, exactly, is it that you want to see stated? Can you provide
> text?

I would suggest text in section 6.2 IPv6 addressing model:

Old:
> 6.2. IPv6 Model
> 
> 
>    For IPv6, the principles described in Section 4 and Section 5
>    translate as such:
> 
>    o  An IP address configured on this interface should be unique, at
>       least within the routing domain, and
> 
>    o  A subnet prefix configured on this interface should be of length
>       /128.

New:
> 6.2. IPv6 Model
> 
> 
>    For IPv6, the principles described in Section 4 and Section 5
>    translate partially as follows:
> 
>    o  An ad-hoc network node self-forms an IPv6 link-local address for
>       each of its interfaces.  The procedure is described in the
>       document relevant to the interface type.  For example, a WiFi
>       interface should use RFC2464; for a PPP link see RFC5072.  For a
>       more exhaustive list of links see RFCXXXX.
> 
>    o  An IP address configured on this interface should be unique, at
>       least within the routing domain, and
> 
>    o  A subnet prefix configured on this interface should be of length
>       /128 (except, of course, the IPv6 link-local addresses whose
>       prefix is /10).

What do you think about this suggested modification?

Alex

> Regards, Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Jul 2009 16:33:34 +0200

Teco Boot a écrit :
> Can one explain the relation between link-locals and DAD/NUD?
> DAD/NUD should run on any address. And may be disabled.

I agree.  And in this sense, DAD and NUD couldn't be an argument to 
deter the use of IPv6 link-local addresses.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 22 Jul 2009 16:13:39 +0200

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 22 Jul 2009 09:13:31 -0700

Hello folks,

I wasn't the one who brought up DAD and NUD in the
first place.  And I didn't use them as an argument to
deter the use of link-locals.

> addresses, once these questions are answered. 

Please note the last sentence.

And before alleging some shadowy "deterrence" that would
prevent the use of link-locals, please exhibit your solution for
insuring uniqueness in an environment where mobility is
the rule (not the exception).  Be recent discussion, waving
hands in air and exclaiming "DAD" or "NUD" does not
count as a solution.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 22 Jul 2009 09:31:45 -0700

Hello Alex,

Alexandru Petrescu wrote:
> which there is no consensus, counted on one hand's fingers, and 
> they're not MANET-like.

We have a standard for transforming a MAC address to an IPv6 address
on a wire -- in other words, on a physical medium where the range of
physical packet transmission is well delimited.  But, see below...
>>       more exhaustive list of links see RFCXXXX.

I would disagree with including this text, until someone can
demonstrate the generally applicable solution that resolves

> addresses, once these questions are answered.

Your text ignores the need for resolving these
issues, and would create a mandate for something
that (a) may be infeasible and (b) is not needed for
a successful autoconfiguraiton protocol.

> What do you think about this suggested modification?

I think it ignores the issues that have been under
discussion for years now.  Therefore, I would oppose
the inclusion of that text.

Regards,
Charlie P.

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 22 Jul 2009 13:08:30 -0400

Charlie,

I take full responsibility for kicking this snowball off the side of the
mountain -- my bad. :-(
I'm in *full* agreement with you. We shouldn't let ourselves get
side-tracked with this discussion, and I hereby present myself for
verbal flogging for having brought it up in the first place... ;-) We
can make good progress without solving this issue right here and now. We
should take some time and collectively think about the evils of
duplicate addresses and how to attack the problem, but that shouldn't
stop us from making what progress we can. For now, I'm satisfied with
the notion of using /32 prefixes for V4, /128 for V6, and the caveat
"Duplicate addresses hurt *very* bad, so don't do it!"

Regards,
Stan

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Jul 2009 20:00:18 +0200

Charles E. Perkins a écrit :
>> I don't see what you mean by lack of consensus on a broadly
>> applicable procedure for establishing link-local addresses, but the
>> way the IPv6 link-local addresses are formed is standardized, there
>> is consensus, it's a broadly applicable procedure.  There are only
>> a _few_ links on which there is no consensus, counted on one hand's
>> fingers, and they're not MANET-like.
> 
>>> o  An ad-hoc network node self-forms an IPv6 link-local address
>>> for each of its interfaces.  The procedure is described in the 
> demonstrate the generally applicable solution that resolves the
> following issues that I have previously raised:
> 
>>> know that?  How are you going to invalidate the link-local
>>> address as soon as _any_ other node becomes a new neighbor of the
>>> node?
>> 
> Your text ignores the need for resolving these issues, and would
> create a mandate for something that (a) may be infeasible and (b) is
> not needed for a successful autoconfiguraiton protocol.

Charlie, ok, my suggestion for nodes to self-form IPv6 link-local 
addresses ignores the fuziness issue of neighborhood of links with 
undetermined connectivity characteristics.  But requesting to configure 
a /128 on an interface instead of any other length isn't a solution to 
that issue either.

I mean, if the prefix is /128 it does not mean that its neighbor is in
range RIGHT NOW.  These two things (/128 and and neighborness) have
nothing to do with each other, one doesn't imply the other.

The worse part is that this requirement of /128 - a real straw man 
argument - implies forbidding the use of link-local addresses which are 
/64 or /10.   (I suppose the initial presence of 'straw man'  in the 
title wasn't such intention, but it seems to turn out exactly that way - 
a strawman argumentation).

I think we have very different views on this particular topic...

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 22 Jul 2009 07:50:25 -0700

Hello Alex,

> addresses, as part of the AUTOCONF IPv6 practical addressing model.

If  DAD and NUD are unsuitable for working
with mobile devices, then perhaps they should not
be required for establishing the characteristics of
link-local addresses.

But that's not really the relevant point.  So far,
I didn't see consensus for any  broadly applicable
procedure for establishing link-local addresses,
regardless of DAD and NUD.  Until you can show
that, I think the document cannot mandate the use
of link-local addresses.  The document also does
not prohibit their use.

> And state so in the draft(?)

What, exactly, is it that you want to see stated?
Can you provide text?

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 22 Jul 2009 11:57:25 -0700

Hello Alex,

Alexandru Petrescu wrote:
> undetermined connectivity characteristics.

O.K.

>   But requesting to configure a /128 on an interface instead of any 
> other length isn't a solution to that issue either.

Using this model of configuration, it is known that
solutions can be developed.

> nothing to do with each other, one doesn't imply the other.

Right.

> argument - implies forbidding the use of link-local addresses which 
> are /64 or /10.

No, it does not.  The document explains that we recommend use of
the long prefixes unless you can somehow avoid the problems.
If you can show how to avoid the problems, you should contribute
a better document.  Until then, it is not reasonable to have a working
group document that mandates something we don't necessarily know
how to do.  Citing the acronyms DAD and UDP does not constitute
proposing a solution.

>   (I suppose the initial presence of 'straw man'  in the title wasn't 
> such intention, but it seems to turn out exactly that way - a strawman 
> argumentation).

I know what a straw man argument is, and I don't recogize it
in the document's use of /128.  Or, ... what did you mean???
> I think we have very different views on this particular topic...

That is why we have mailing lists -- to discuss technical matters
and arrive at resolutions.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Jul 2009 21:17:43 +0200

Charlie,

Charles E. Perkins a écrit :
> Using this model of configuration, it is known that solutions can be 
> developed.

Solutions to problems or simply mechanisms that work?

>> I mean, if the prefix is /128 it does not mean that its neighbor is
>>  in range RIGHT NOW.  These two things (/128 and and neighborness) 
>> have nothing to do with each other, one doesn't imply the other.
> 
> Right.
> 
>> 
> No, it does not.

The section 6.2 is clear - it says /128 prefixes exclusively.  True, a 
later appendix suggests that link-local addresses are possible. 
However, I find that appendix too far from section 6.2 to qualify your 
above conviction.

Were the section 6.2 to have a paragraph to mean that the /128 mandatory
prefix recommendation does not forbid the /64 IPv6 link-local addresses
then I'd agree with your statement above.  It is about how people read 
the documents and go straight to the important sections, skipping the 
appendices eventually.

Alex

> The document explains that we recommend use of the long prefixes
> unless you can somehow avoid the problems. If you can show how to
> avoid the problems, you should contribute a better document.  Until
> then, it is not reasonable to have a working group document that
> mandates something we don't necessarily know how to do. Citing the
> acronyms DAD and UDP does not constitute proposing a solution.
> 
>>  such intention, but it seems to turn out exactly that way - a 
>> strawman argumentation).
> 
> I know what a straw man argument is, and I don't recogize it in the 
> document's use of /128.  Or, ... what did you mean???
>> 
> That is why we have mailing lists -- to discuss technical matters and
>  arrive at resolutions.
> 
> Regards, Charlie P.
> 
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 22 Jul 2009 13:09:35 -0700

Hello Alex,

> Solutions to problems or simply mechanisms that work?

You are being mysterious here.  I reckon you meant to imply
that the published solutions do not solve "real" problems.
If so, then you should be up front about that and say so.
But we did manage to build a test network and did find
that the solution seemed to be workable.

> the documents and go straight to the important sections, skipping the 

If section 6.2 were to change emphasis to conform more closely with
my description of what was meant, would that resolve your issue?

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Jul 2009 23:06:49 +0200

> that the solution seemed to be workable.

The problem to be solved is not ready at hand.  I am no more mysterious 
than that.

> my description of what was meant, would that resolve your issue?

I think you would like to write something better, more convincing to me 
and hopefully aligned not only to your own description but according to 
at least 4 oppinions expressed on this list stating they have nothing 
against the use of IPv6 link-local addresses.

I would like to read what you plan to write in 6.2.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 22 Jul 2009 14:59:05 -0700

Hello Alex,

Alexandru Petrescu wrote:
>
>>>
>>> The section 6.2 is clear - it says /128 prefixes exclusively.  True, 
>>> a later appendix suggests that link-local addresses are possible. 
>>> However, I find that appendix too far from section 6.2 to qualify 
>>> your above conviction.
>>>
>>> ...
>>
> I think you would like to write something better, more convincing to 
> me and hopefully aligned not only to your own description but 
> according to at least 4 oppinions expressed on this list stating they 
> have nothing against the use of IPv6 link-local addresses.

I also have nothing against the use of link-local addresses.
I can be in favor of using them when possible, without
wanting to put others in the position of having to use them
when the methods for appropriate use aren't understood.

> I would like to read what you plan to write in 6.2.

I provided my input to the design team, and you have seen
the result.  Now it's your turn to provide input to the
document editor :-)

I did make comments on your earlier proposal, and did
not get a direct response:

> mandates something we don't necessarily know how to do.

Since according to this, your earlier submission wouldn't
be suitable, perhaps you could take the initiative to craft
some new text that (a) does make use of the long discussion
about link-locals and (b) helps us to progress towards a
resolution and common understanding.

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 23 Jul 2009 00:30:28 +0200

Hi Charlie,

Here another response, also with large delay.

> addresses, once these questions are answered.

What makes a link-local different form an address with other scope?
One answer would be: the other addresses can be used via single-hop
or multi-hop paths. Multi-hop paths could be preferred over single-
hop paths when link-metrics are in place. Link-locals are used on
single-hop paths only.
This has impact on address selection. If addresses are needed for
a session on whatever path, link-local addresses are not preferred.
If addresses are needed for single-hop only, link-local addresses
are fine and moreover, it guarantees packets are not forwarded.
This makes link-local addresses a candidate for network layer
protocols, and that is why I use link-locals for the MANET protocols
I run.

I asked on RFC3484 rule 2. I had my beer. I still do not understand.
Can you translate for me?

Teco.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 22 Jul 2009 16:43:28 -0700

Hello Teco,

> hop paths when link-metrics are in place. Link-locals are used on

Check.

> protocols, and that is why I use link-locals for the MANET protocols
How do you know that a particular link-local destination has
not been replaced by another node that just happens to have the
same link-local address?  Presumably, by requiring address uniqueness.
How do you enforce uniqueness?  Ahhh.... that's a toughie when you
are only allowed to use packets that cannot be forwarded...

Plus you can swamp out your network with uniqueness-enforcement
traffic if you have too many nodes or brute-force design.
> Can you translate for me?
Yes.  I can translate this rule for you.

Where's _my_ beer?

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 23 Jul 2009 08:07:13 +0200

Hi Charlie,

|How do you know that a particular link-local destination has
|not been replaced by another node that just happens to have the
|same link-local address?  

How do you know that a particular global destination has
not been replaced by another node that just happens to have the
same global address?  

|Presumably, by requiring address uniqueness.
|How do you enforce uniqueness?  Ahhh.... that's a toughie when you
|are only allowed to use packets that cannot be forwarded...

It's easy. I buy products that comply with standards and 
Recommendations published by IETF and IEEE. I don't need 
any packet. It guarantees uniqueness for globals and link-locals,
based on guaranteed unique L2 addresses.
This doesn't work for IPv4.

|Plus you can swamp out your network with uniqueness-enforcement
|traffic if you have too many nodes or brute-force design.

I could, but I don't.

|> I asked on RFC3484 rule 2. I had my beer. I still do not understand.
|> Can you translate for me?
|>
|Yes.  I can translate this rule for you.
|
|Where's _my_ beer?

Out of reach for you?
I can't bring one with me (customs).
I buy you one in Sweden. Know this cost me a lot, prices are extreme
high out there.

Now serious:
Assume router A has addresses LL_A an G_A and router B LL_B and G_B.
When a connection from A to B is initiated, and destination LL_B is
selected, address LL_A would be the source. With destination G_B is
selected, address G_A would be the source. Is this RFC3484 SA 
selection rule 2?
When a destination address needs selection, would it be LL_B or
G_B? I use MANET protocols with link-metrics. When I initiate a ping,
I select LL_B or G_B for testing the benefit of link-metrics (which 
is tremendous in some cases, a path via C could perform much better).
But what should be the address selection policy for normal 
applications? I say: use globals. Can you confirm this needs and
update on RFC3484 DA selection rule 8?

RFC3484 DA selection, 
Rule 8:  Prefer smaller scope.
 If Scope(DA) < Scope(DB), then prefer DA.  Similarly, if Scope(DA) >
 Scope(DB), then prefer DB.

Teco.

|Regards,
|Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2009 10:35:47 +0200

> when the methods for appropriate use aren't understood.

I agree.  There must be a way to formulate that, and not in the 
appendix, but in the main section 6.2.

> resolution and common understanding.

How about this text which says IPv6 link-local addresses are recommended 
when the link layer has determined connectivity properties.

New:
 >       This IPv6 link-local address are recommended when the link-layer
 >       has determined connectivity properties.
 >

What do you think?

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 23 Jul 2009 00:42:03 -0700

> not been replaced by another node that just happens to have the

For the case of globals, we can use protocol methods to insure
uniqueness.

> This doesn't work for IPv4.

My understanding is that IPv6 has a sphere of applicability which includes
devices for which IEEE addresses may not exist, or may be duplicated
by accident.

> I buy you one in Sweden. Know this cost me a lot, prices are extreme

Does this mean that, on average, Swedes are more sober than the Dutch?

> selected, address G_A would be the source. Is this RFC3484 SA 

Selection 2 covers this case, but the example only requires a
small subset of the rule.

> G_B?
The rules governing application selection of destination address
seem tricky to me, and maybe weren't completely thought
out for mobile devices.  Right now I can't study that problem,
unfortunately.  I would not make the assumption that the RFC
is correct for cases of interest to [autoconf].

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2009 11:22:01 +0200

Charles E. Perkins a écrit :
> Teco Boot wrote:
>> Hi Charlie,
>> 
>> |How do you know that a particular link-local destination has |not
>> been replaced by another node that just happens to have the |same
>> link-local address? How do you know that a particular global
>> destination has not been replaced by another node that just happens
>> to have the same global address?
>> 
> 
>> |Presumably, by requiring address uniqueness. |How do you enforce
>> uniqueness?  Ahhh.... that's a toughie when you |are only allowed
>> to use packets that cannot be forwarded...
>> 
>> Recommendations published by IETF and IEEE. I don't need any
>> packet. It guarantees uniqueness for globals and link-locals, based
>> on guaranteed unique L2 addresses. This doesn't work for IPv4.
>> 
> 
> My understanding is that IPv6 has a sphere of applicability which
> includes devices for which IEEE addresses may not exist, or may be
> duplicated by accident.

Or may be negotiated to ensure uniqueness, like with PPP.  Uniqueness is
easier to ensure on a link.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 23 Jul 2009 12:00:22 +0200

Hi Charlie,

|> |How do you know that a particular link-local destination has
|> |not been replaced by another node that just happens to have the
|> |same link-local address?
|>
|> How do you know that a particular global destination has
|> not been replaced by another node that just happens to have the
|> same global address?
|>
|
|For the case of globals, we can use protocol methods to insure
|uniqueness.

I still do not see any difference with link-locals.
When the address is not known to be unique, it is not used as source.
I think it is also not advertized in the MANET.
So other addresses are needed for verification. This may work for
link-locals also.
Anyway, we are back at DAD. Let's continue on the addressing model 
itself and I say link-locals works great.

|> |Presumably, by requiring address uniqueness.
|> |How do you enforce uniqueness?  Ahhh.... that's a toughie when you
|> |are only allowed to use packets that cannot be forwarded...
|>
|> It's easy. I buy products that comply with standards and
|> Recommendations published by IETF and IEEE. I don't need
|> any packet. It guarantees uniqueness for globals and link-locals,
|> based on guaranteed unique L2 addresses.
|> This doesn't work for IPv4.
|>
|
|My understanding is that IPv6 has a sphere of applicability which
|includes
|devices for which IEEE addresses may not exist, or may be duplicated
|by accident.

This leaves open usage of technology that works. I recommend 
using it. And I recommend defining a practical addressing model 
for it.

I am facing non-IEEE L2 addresses also. But I did not face a 
scenario with problems yet. I work with stuff I can rely on.

|Does this mean that, on average, Swedes are more sober than the Dutch?

I thought we were famous. So no need to answer.
Did consumption go down during Prohibition?

|I would not make the assumption that RFC3484
|is correct for cases of interest to [autoconf].

OK, so we add this in the Open Issues list.

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 23 Jul 2009 12:09:21 +0200

Hi Alex,

>  o  A subnet prefix configured on this interface should be of
>     length /128 (except, of course, the IPv6 link-local 
>     addresses whose prefix is /10).

The link-local is defined in RFC4291 and has a /64 well-known prefix,
which is FE80::/64. The 54 bits after the 10 bits allocated for 
link-local are zero. It is minor, but let's use /64.

Teco.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2009 13:03:46 +0200

> link-local are zero. It is minor, but let's use /64.

Teco, thanks for digging this out.

I agree with you to use /64 for IPv6 link-local addresses.

Alex

---

From: Rafael Roque <[email-masked]>
Date: Thu, 23 Jul 2009 10:27:29 -0300

Hi Teco,

> This doesn't work for IPv4.

as we can see from the messages, you have a good testbad, didn't you find
some privacy problems by using l2 address to generate IPv6?
This is a issue treated in [rfc 4941].

Regards,

R. Rafael.

-- 
Rafael Roque Aschoff
GPRT/UFPE

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 23 Jul 2009 14:58:30 +0100

> What do you think?

I think you are trying to take us back down the same route
that has consumed two or three years. There was a DT formed,
they could agree on some things, but not everything. (They
could agree that link-local addresses weren't to be excluded,
but not that they should be mandatory, for example.) Trying to
force the issue(s) that couldn't be agreed misses that point.

It would be better at this point, as Stan (among others) has
said, to take this as a starting point for actually doing some
work (the sort that ends up with a way to autoconfigure
addresses, rather than the sort that ends up with definitions
and nothing else) rather than argue points that it's clear
that not all agree - but which we may not need to all agree.
(If someone has a "good" algorithm that hands out addresses
from a limited size pool, without non-transient duplicate
assignment, for example, then we can apply it to several
different sorts of address.)

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 23 Jul 2009 16:11:50 +0200

I agree with Stan and Chris, that we should move forward with the points we
have agreed on in the strawman draft and continue the discussion about
link-local addresses later, as soon as we have understood better how to
solve the issues with these addresses in autoconf.

Ulrich

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2009 16:19:58 +0200

Dearlove, Christopher (UK) a écrit :
>> What do you think?
> 
> I think you are trying to take us back down the same route that has
> consumed two or three years. There was a DT formed, they could agree
> on some things, but not everything. (They could agree that link-local
> addresses weren't to be excluded, but not that they should be
> mandatory, for example.) Trying to force the issue(s) that couldn't
> be agreed misses that point.
> 
> It would be better at this point, as Stan (among others) has said, to
> take this as a starting point for actually doing some work (the sort
> that ends up with a way to autoconfigure addresses, rather than the
> sort that ends up with definitions and nothing else) rather than
> argue points that it's clear that not all agree - but which we may
> not need to all agree. (If someone has a "good" algorithm that hands
> out addresses from a limited size pool, without non-transient
> duplicate assignment, for example, then we can apply it to several 

Christopher, if you expect a reply about how I don't want to take
anybody back, or about the draft forbidding link-locals, please let me know.

Otherwise I contend myself reading  your email above and having my
thoughts about it.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 23 Jul 2009 15:23:37 +0100

Alexandru
> the draft forbidding link-locals

Where?

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 23 Jul 2009 15:40:15 +0100

>Section 6.2:

> An IPv6 link-local address has prefix length /64, not /128.

>From RFC 4291
<quote>
2.5.6.  Link-Local IPv6 Unicast Addresses

   Link-Local addresses are for use on a single link.  Link-Local
   addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+
</quote>

That shows a single link local address as being taken from a particular
/64 allocation (fe80::/64) with a chosen interface ID (which would then
make it a /128), not as being a /64.

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 23 Jul 2009 16:43:41 +0200

No. It says: (in the appendix)

"the use of link local addresses on interfaces connecting to a MANET link is
not prohibited"

Ulrich

On Thu, Jul 23, 2009 at 4:20 PM, Alexandru Petrescu <
[email-masked]> wrote:

> Ulrich Herberg a écrit :
>
>> I agree with Stan and Chris, that we should move forward with the points
>> we have agreed on in the strawman draft and continue the discussion about
> The draft forbids the IPv6 link-local addresses - do you agree with that?
>
> Alex
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2009 16:45:34 +0200

Ulrich Herberg a écrit :
> "the use of link local addresses on interfaces connecting to a MANET 
> link is not prohibited"

1 - in appendix it is too late, too far from first read.
2 - appendix contradicts section 6.2

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2009 16:52:14 +0200

>    |  bits    |         54 bits         |          64 bits           |

Does that make the IPv6 link-local address have a /128 subnet prefix?  I 
doubt so.

What do you mean by "A subnet prefix configured on this interface should 
be of length /128."?

By "a subnet prefix configured on an interface" I thought you mean that 
number after the slash, near the address.  For example, if I say:

# ifconfig eth0
   adr inet6: fe80::210:b5ff:fe40:b704/64 Scope:Lien

Then the "subnet prefix configured on an interface" is that /64 
appearing above.  What do you mean by "subnet prefix configured on an 
interface"?

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 23 Jul 2009 16:00:44 +0100

> What do you mean by "A subnet prefix configured on this interface should 

Ask the people who wrote the draft. But note that they include
some people who know rather a lot about IP, who don't see a
contradiction in what they wrote, and who commented that link
local addresses are allowed; and also include some staunch
supporters of link local addressing who wrote (or agreed to
be an author of a document containing those words) what's
there with that background.

> By "a subnet prefix configured on an interface" I thought you mean that 

Again, try asking the people who wrote the draft, with whom
you are confusing me.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2009 17:02:41 +0200

> Again, try asking the people who wrote the draft, with whom

I think they're on the list.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2009 16:20:55 +0200

Ulrich Herberg a écrit :
> we have agreed on in the strawman draft and continue the discussion 
> about link-local addresses later, as soon as we have understood better 
> how to solve the issues with these addresses in autoconf.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2009 16:29:39 +0200

Section 6.2:
 > [end of section]

What do you think?

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 23 Jul 2009 10:02:32 -0700

Hello Alex,

Alexandru Petrescu wrote:
> Ulrich Herberg a écrit :
>> I agree with Stan and Chris, that we should move forward with the 
>> points we have agreed on in the strawman draft and continue the 
>> discussion about link-local addresses later, as soon as we have 
>> understood better how to solve the issues with these addresses in 
>> autoconf.
>

I don't agree with this.  Instead, I understand that the
draft does not specify how to use link-locals, but does
not prohibit their use.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2009 19:47:31 +0200

AUTOCONFers,

[...]
> But what about nodes in an ad-hoc network that DON'T self-form any 
> IPv6 link-local address?

I would like to get a sense from the list about ad-hoc network nodes
which don't self-form an IPv6 link-local address for themselves.

I have my own oppinions about such nodes that I am ready to share on the
list, but I would like to see first what people on this list think about
ad-hoc network nodes that don't self-form any link-local address?  Can
such node exist?  Would a software knob allow for it?  Would other RFCs
be influenced by this absence, etc.

Any oppinion on this topic? thanks

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 23 Jul 2009 10:28:22 -0700

Hello Alex,

I don't think you can get consensus on any text that
mandates the use of link-locals.  You should try to devise
some text that makes it clear that they are allowable,
but not always mandated.

Alexandru Petrescu wrote:
>>
>>  ...    perhaps you could take the initiative to craft
> How about this text which says IPv6 link-local addresses are 
> recommended when the link layer has determined connectivity properties.
>
> New:
> > 6.2. IPv6 Model
> >
> >

But what about nodes in an ad-hoc network that DON'T self-form
any IPv6 link-local address?
> >       has determined connectivity properties.

That's not going to work.  You have to say what the
connectivity properties are.  "determined" is quite bad
for this -- the connectivity properties could be determined
to be useless or even harmful.
> >       /128 (except, of course, the IPv6 link-local addresses whose

This would be O.K. as long as we are clear that there are
some MANET interfaces for which link-locals may remain
unconfigured.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 23 Jul 2009 10:19:06 -0700

Hello Alex,

Alexandru Petrescu wrote:
> By "a subnet prefix configured on an interface" I thought you mean 
> that number after the slash, near the address.  For example, if I say:
>
> # ifconfig eth0
> appearing above ....
 
I also think this is what "subnet prefix" means.

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 23 Jul 2009 19:52:49 +0200

The draft does not recommend link-locals.
I recommend usage of link-locals.
Some posting say there are issues with link-locals. But what those are is
vague or not true. For example, I don't see much difference in duplicate
avoidance between link-locals and globals. And this is not something to
discuss right now, as posted a few times.
In DT I felt a bit lonely. Now on ML, I see neutral opinions or
recommendations for link-locals.  

Teco.

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens
|Charles E. Perkins
|Verzonden: donderdag 23 juli 2009 19:03
|Aan: Alexandru Petrescu
|CC: [email-masked]
|Onderwerp: Re: [Autoconf] Link-locals vis-à-vis the new [autoconf]
|document
|
|
|Hello Alex,
|
|Alexandru Petrescu wrote:
|> Ulrich Herberg a écrit :
|>> I agree with Stan and Chris, that we should move forward with the
|>> points we have agreed on in the strawman draft and continue the
|>> discussion about link-local addresses later, as soon as we have
|>> understood better how to solve the issues with these addresses in
|>> autoconf.
|>
|> The draft forbids the IPv6 link-local addresses - do you agree with
|that?
|
|I don't agree with this.  Instead, I understand that the
|draft does not specify how to use link-locals, but does
|not prohibit their use.
|
|Regards,
|Charlie P.
|
|_______________________________________________
|Autoconf mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/autoconf

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2009 19:42:13 +0200

> some text that makes it clear that they are allowable,

Ok let's see...

Alex

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 23 Jul 2009 14:13:27 -0400

Alex,

I've deployed MANET networks without IPV6 link local addresses, and they 
work just fine. Specifically, my deployments have used pre-configured 
IPV4 addresses. Oh, and by the way, we used /32 prefixes on the "MANET 
interfaces" as well. :-) In case it matters, the IPV4 deployments I 
speak of use EIGRP as the routing protocol (I know, it's not an IETF 
standard, but it works.)

I've also deployed MANET networks using V6 link-local addresses. In 
these cases, we use the "Overlapping Relays" modification to OSPFv3 that 
was submitted to the OSPF WG (I believe that an experimental RFC number 
is pending on that draft). As in the V4 case, the V6 link-locals work 
like a champ.

To reiterate, I'm OK with the draft as-written. It does *NOT* preclude 
the use of V6 link locals. As you rightly mention, it does not discuss 
V6 link-locals until you get to the appendix. But with it being only a 6 
page draft, I don't see the reference in the appendix as a problem -- 
IMO, if you're going to "skim" a 6 page draft, you deserve whatever trap 
you fall into because of it.

Regards,
Stan

Alexandru Petrescu wrote:
>>>> each of its interfaces. The procedure is described in the document 
>>>> relevant to the interface type. For example, a WiFi interface 
>>>> should use RFC2464; for a PPP link see RFC5072. For a

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2009 20:39:36 +0200

Charles E. Perkins a écrit :
> That's not going to work.  You have to say what the connectivity
> properties are.  "determined" is quite bad for this -- the
> connectivity properties could be determined to be useless or even
> harmful.

I will not not turn it saying that undetermined/unplanned connectivity 
properties (the current formulation of the draft) is not any more useful.

I will say what I said in earlier messages that for some particular 
MANET link layers the determined connectivity properties are when the 
number of nodes is below a threshold (counted in the tens) and the area 
covered by the MANET has a range of around 50meters, without obstacles 
to radio waves and without interference in a certain radio band (counted 
in GHz).  And that the link-layers are specified in agreed documents.

There are many such kinds of MANET link layers, counted by the tens.

There may be other MANET link layers which don't have such properties, 
and thus have undetermined connectivity properties.

Would this formulation about determined connectivity properties work better?

Alex

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 23 Jul 2009 14:54:50 -0400

Slight correction -- we've deployed with V4 addresses, but haven't used 
the /32 prefixes on them. Sorry for the mis-information.

Regards,
Stan

Stan Ratliff wrote:
> Alex,
>
> I've deployed MANET networks without IPV6 link local addresses, and 
> they work just fine. Specifically, my deployments have used 
> pre-configured IPV4 addresses. Oh, and by the way, we used /32 
> prefixes on the "MANET interfaces" as well. :-) In case it matters, 
> the IPV4 deployments I speak of use EIGRP as the routing protocol (I 
> know, it's not an IETF standard, but it works.)
>
> these cases, we use the "Overlapping Relays" modification to OSPFv3 
> that was submitted to the OSPF WG (I believe that an experimental RFC 
> number is pending on that draft). As in the V4 case, the V6 
> link-locals work like a champ.
>
> V6 link-locals until you get to the appendix. But with it being only a 
> 6 page draft, I don't see the reference in the appendix as a problem 
> -- IMO, if you're going to "skim" a 6 page draft, you deserve whatever 
> trap you fall into because of it.
>
> Regards,
> Stan
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 23 Jul 2009 11:58:55 -0700

Hello Teco,

Teco Boot wrote:
> avoidance between link-locals and globals.
Well, I don't think we can mandate PPP between every pair of
MANET nodes.

>  And this is not something to

I agree with this, except insofar as the discussion may be
needed to progress the draft.  I think solving the problem of
link-local autoconfiguration will not happen within the lifetime
of [autoconf], especially if that lifetime is prematurely snuffed
out because of insistence on solving the problem of link-local
address autoconfiguration.

> recommendations for link-locals.

I'm still puzzling over whether we are going to mandate PPP
between every pair of MANET nodes.

Sigh.  If that happens, you won't have me to kick around any more.

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 23 Jul 2009 21:28:32 +0200

Hi Charlie,

I agree on your opinion on PPP.
I'll not enforce anybody to use link-locals. I only recommend it.

Teco.

|-----Oorspronkelijk bericht-----
|Van: Charles E. Perkins [mailto:[email-masked]]
|Verzonden: donderdag 23 juli 2009 20:59
|Aan: Teco Boot
|CC: 'Alexandru Petrescu'; [email-masked]
|Onderwerp: Re: [Autoconf] Link-locals vis-à-vis the new [autoconf]
|document
|
|
|Hello Teco,
|
|Teco Boot wrote:
|> The draft does not recommend link-locals.
|> I recommend usage of link-locals.
|> Some posting say there are issues with link-locals. But what those are
|is
|> vague or not true. For example, I don't see much difference in
|duplicate
|> avoidance between link-locals and globals.
|Well, I don't think we can mandate PPP between every pair of
|MANET nodes.
|
|>  And this is not something to
|> discuss right now, as posted a few times.
|>
|
|I agree with this, except insofar as the discussion may be
|needed to progress the draft.  I think solving the problem of
|link-local autoconfiguration will not happen within the lifetime
|of [autoconf], especially if that lifetime is prematurely snuffed
|out because of insistence on solving the problem of link-local
|address autoconfiguration.
|
|> In DT I felt a bit lonely. Now on ML, I see neutral opinions or
|> recommendations for link-locals.
|>
|
|I'm still puzzling over whether we are going to mandate PPP
|between every pair of MANET nodes.
|
|Sigh.  If that happens, you won't have me to kick around any more.
|
|Regards,
|Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2009 21:58:40 +0200

Charles E. Perkins a écrit :

>>> o  An IP address configured on this interface should be unique,
>>> at least within the routing domain, and
>>> 
>>> length /128 (except, of course, the IPv6 link-local addresses
>>> whose prefix is /10).
> 
> This would be O.K. as long as we are clear that there are some MANET
> interfaces for which link-locals may remain unconfigured.

So, if you feel this would be O.K., should the editors modify the draft 
accordingly?

Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sun, 26 Jul 2009 11:59:19 +0200

Hi Alex, all,

> Any oppinion on this topic? thanks

I've just sent an e-mail with comments that I think provides an answer
for your (relevant IMHO) questions. Anyway, I'll repeat here myself,
just for the sake of keeping them on this thread. I think link-local
addresses should be allowed in MANETs, since I think disallowing them
may have issues on other protocols that we might not be considering now.
However, I also think that only using /32s and /128s would make our life
much easier :-D

Carlos

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 27 Jul 2009 14:11:28 +0200

I've tried to determine the current state of the IPv6 link-local address 
discussion, but I might have missed something.

 From a definitional perspective I think we want to include the IPv6 
link-local addresses (as well as the link-scope multicast addresses in 
this section:
4.  IP Subnet Prefix Configuration

    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 including it there might not have any operational difference 
if the MANET routing protocols do not use link-local addresses to 
communicate with their peers.

But it would matter from an operational perspective if there are 
protocols that want to restrict their communication to a single hop. 
Such protocols could then use link-local addresses (and link-scope 
multicasts), while normal applications use global (or ULA) addresses.

    Erik