Subject: [Autoconf] [warning -- weeks old mail under discussion] Re: dynamically assigning prefixes on links for CP's 4 node example

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 22 Oct 2009 09:50:26 -0700

Hello Alex,

I did find this other email which predated my last
response to you.  That latter response would also
have shown what was wrong with this solution, but
it didn't explicitly rebut the DHCP-ness of your
suggested solution.

First, I don't agree with the often suggested
assumption that we can rely on MAC addresses
for uniqueness.  Maybe we ought to have a new
design team or even working group for that, but
I think such results are usually required to be clearly
labeled as, for instance, "XXXX over IEEE 802.11"
or some such.

If you really think that DHCP is even remotely
feasible for the general scenario, I can try to dig through
the timeouts and state maintenance on the servers
and relays to identify the half-dozen ways in which
the solution is not workable.  I have to say that it
seems to me that you are using DHCP and ND and
NUD as "theorems" upon which you construct a
"theory" of operation.  Unfortunately, the hypotheses
and conditionals upon which those "theorems" rely are
not satisfied in the case of mobile wireless devices of
the type under discussion in [autoconf], unless of
course you have magical properties such as unique
MAC addresses or slow speeds.

So when you quote "theorems" such as DHCP,
without going to the trouble of verifying the requisite
preconditions, you are investing confidence in a
design that would fall apart like a house of cards in
a windstorm.

Shall I make some time next week to go through
the exercise yet again?

Even without doing so, the following statement calls
out shrilly for serious skepticism and, in a world inclined
towards practical goals, dismissal:

> -designate B, C and D to request a prefix each time they think their
>  neighbors on one interface has changed. 
Ten or more neighbors, moving at any reasonable speed,
and your design is toast -- DHCP or no DHCP.

Regards,
Charlie P.

Alexandru Petrescu wrote:
> Alexandru Petrescu a écrit :
>>> Here are four nodes at time T_0:
>>>
>>>                      A --------- B --------- C --------- D
>>>
>>> The dashed lines indicate neighborliness at time T_0.
>>> Assume all bidirectional links.
>>>
>>> At time T_1, a second later, the neighborhoods
>>> are as follows:
>>>
>>>                      A --------- C --------- B --------- D
>>>
> [...]
>
> Then I said:
>> Of course, until now A can not send a packet with a dst address D, 
>> because only link-local addresses are used above.  In order to 
>> achieve A-to-D communnication, a mechanism for global address (or 
>> ULA) and subnet prefix assignment should be used.
>>
>> This can be achieved as follows:
>> -on each interface of each node pre-configure a unique /64 subnet
>>  prefix.
>
> And of course, people are interested in more than simply 
> pre-configuring  /64 unique prefixes on each node.  This can be 
> achieved as follows:
>
> -designate A to be a DHCPv6 server having a pool of such prefixes to use
>  with a technique called "prefix delegation" RFC number here.
> -designate B, C and D to request a prefix each time they think their
>  neighbors on one interface has changed.
> -designate B, C and D to RA that prefix on the other interface (on the
>  interface different from the one where it received the prefix).  If
>  there's only one interface then don't advertise on the "other"
>  interface because it doesn't exist.
> -Designate B and C to become DHCP Relays once they have received a
>  prefix (following a change in the neighbor state).
>
> In this sense - what do you think?
>
> Alex
>
>
>
>> -designate A and D to send Router Advertisements with prefixes that
>>  should be interpreted as to install in the receivers' routing tables
>>  (an extended "intepretation" of RFC4191 "more specific routes").
>> -designate B and C to also send such extended RAs but _only_ if there
>>  isn't already somebody else sending such an extended RA on that link,
>>  or if a new NA is heard from a neighbor it hasn't seen before.
>>
>> This should be done carefully such as to avoid loops.
>>
>> So, what do you think Charlie?  And of course - what do the others 
>> think?
>>
>>> Narten's answer was "unique MAC-layer addresses".
>>> Do you agree with that?
>>
>> I agree unique MAC-layer addresses are helping forming unique IPv6 
>> link-local addresses.
>>
>>> Do you think we should restrict
>>> work in [autoconf] to be applicable only to such networks
>>> in which that restriction is valid?
>>
>> Of course, I don't agree restricting work.  I don't agree forbidding 
>> link-local addresses either.
>>
>>> Do you have any intuition about the scalability of the
>>> system resulting from your definitions?
>>
>> Hmm... tough question.  I believe the method I presented above should 
>> scale well provided (1) all nodes are pre-configured with prefixes 
>> unique and (2) MAC addresses are unique.  But I have of course some 
>> doubts.
>>
>> But whereas you're very specific A-B-C-D to A-C-B-D you don't say how 
>> would you like it to scale: would it always be rectilinear scaling 
>> (max 2 interfaces per node)?  Something else?
>>
>>> What if you discovered that your definitions resulted in a
>>> system that was three orders of magnitude less scalable than
>>> an alternative that did not impose a requirement for assigning
>>> unique link-local addresses? -- or, a system that, effectively,
>>> didn't even define any broadcast-oriented links at all?
>>
>> This is speculation from your part.  You are asking to compare 
>> against something that you don't say what is.
>>
>> (no offence pointing at 'you' - it is more or less intended response to
>>  previous comments :-)
>>
>> Yours,
>>
>> Alex
>>
>> _______________________________________________
>> Autoconf mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/autoconf
>>
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Oct 2009 20:00:33 +0200

Charles E. Perkins a écrit :
> response to you.

YEs, thank you.

>  That latter response would also

Ok, I agree, we should label AUTOCONF as 802.11.

> the solution is not workable.

No, not necessary, thanks.

> I have to say that it

Hmm... how else is one supposed to make logical argumentations?

> Shall I make some time next week to go through

No.

>>  neighbors on one interface has changed. 

Hmm... at least I read some good ways of expressing your negative 
feelings towards some technical proposal.

> and your design is toast -- DHCP or no DHCP.

Charles - "speed" as we tend to interpret it may have no sense when we 
consider coverage areas.  Node speed of 300kmph equals 0 if the coverage 
is very large.

Node speed of 300kmph going through a 50m wifi area - ok, no DHCP: but 
then one wonders _why_ would a car need to communicate anything through 
that 50m wifi area.

DHCP or no DHCP... what coverage area?  what link layer?

DHCP can be very fast.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 22 Oct 2009 11:43:06 -0700

Hello Alex,

> Ok, I agree, we should label AUTOCONF as 802.11.

Well, you may agree with some other people on that point,
but I do not agree with it, and maybe it's time to get some
clarity on this point.

> Hmm... how else is one supposed to make logical argumentations?

By making assumptions that are supportable in the
area of interest.

> consider coverage areas.  Node speed of 300kmph equals 0 if the 
> coverage is very large.

This is a good point.  Perhaps the proper quantity of interest
is the average transition time through the range of coverage
from a neighboring node.

> then one wonders _why_ would a car need to communicate anything 
> through that 50m wifi area.

I personally think this is a great idea, if for instance we had
WiFi on the streetlamps and freeway dividers.  At $1.00
per transceiver chip, it's a reasonable alternative!  It draws
a lot less power than the light bulb.

> DHCP or no DHCP... what coverage area?  what link layer?

In order to counter this statement (or, more accurately,
show why it is not relevant), I would have to go through
the exercise -- but you had relieved me of that task.

I'm not going to do that unless necessary.

But, roughly speaking, the answer is that you can't
have DHCP unless you know where the server(s) and
the relays are.  And when the nodes are moving, you
don't know.  And you can't quote NUD and NA as
theorems because of the reasons I already outlined
in previous messages.  And even if you could, before
long you'd have to get some new relay because you
need the relay to be local.  And more than likely your
DHCP server will be occasionally partitioned into
temporary isolation.  But then it's back!  But the
relay is gone!  And then there's something else to
go wrong.  But, are _all_ nodes relays?  But, which
server has the state?  Or is there just one server?
But that won't ever work!

Every time I think about it, I just know it's wrong.
I do not have any belief whatsoever in this theorem.
And, with three nodes, you'll never see the problem.
Never!

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Oct 2009 00:22:34 +0200

>>> Ten or more neighbors, moving at any reasonable speed, and your
>>> design is toast -- DHCP or no DHCP.
>> 
>> Charles - "speed" as we tend to interpret it may have no sense when
>> we consider coverage areas.  Node speed of 300kmph equals 0 if the
>>  coverage is very large.
> 
> This is a good point.  Perhaps the proper quantity of interest is the
> average transition time through the range of coverage from a
> neighboring node.

Average transition time (ATT) through some coverage sounds more tempting 
than simply "speed".

So a vehicle would have an ATT of 3.6seconds (50kmph, 50m wifi).

3.6s is enough to perform DHCP and many other things.

>> Node speed of 300kmph going through a 50m wifi area - ok, no DHCP:
>> but then one wonders _why_ would a car need to communicate anything
> I personally think this is a great idea, if for instance we had WiFi
> on the streetlamps and freeway dividers.

It could work for certain values of ATT, I am sure.

> At $1.00 per transceiver chip, it's a reasonable alternative!  It
> draws a lot less power than the light bulb.
 >
> In order to counter this statement (or, more accurately, show why it
> is not relevant), I would have to go through the exercise -- but you
> had relieved me of that task.

I know why people say DHCP is slow.  I've measured it.  There are quirks 
with some implementations of the timers.  It's mostly in the discovery 
phase.  It's the same fundamental reasons why some people complain about 
slow WiFi link-layer handovers, and slow Mobile IP, and slow NUD, slow 
ND - which I've also measured.

Basically one can't do discovery otherwise than emitting and then 
_waiting_ a pre-defined amount of time.  It's the basics of the basics.

What one can do is to shorten the time one waits, at the risk of not 
hearing some things and maybe hitting into someone, or missing the 
presence of some DHCP Server.

AUTOCONF can't propose a discovery mechanism better than the discovery 
phases of DHCP, ND, and FastBSS.  People would have already done it well 
before.

> But, roughly speaking, the answer is that you can't have DHCP unless
> you know where the server(s) and the relays are.

Err... yes, more or less.

The Client performs a discovery phase, sending first to a predefined 
multicast address and then waiting.

>  And when the nodes
> are moving, you don't know.

Well - you do know for some time.

>  And you can't quote NUD and NA as 
> theorems because of the reasons I already outlined in previous
> messages.  And even if you could, before long you'd have to get some
> new relay because you need the relay to be local.  And more than
> likely your DHCP server will be occasionally partitioned into 
> temporary isolation.  But then it's back!  But the relay is gone!
> And then there's something else to go wrong.  But, are _all_ nodes
> relays?  But, which server has the state?  Or is there just one
> server? But that won't ever work!
> 
> Every time I think about it, I just know it's wrong. I do not have
> any belief whatsoever in this theorem. And, with three nodes, you'll
> never see the problem. Never!

Well I look at it as a distributed election problem.  Dynamically elect 
the Servers and the Relays, among them.  Of course, afterwards, the 
elected DHCP Server needs to learn the addresses of the relays and to 
have routes to them.   These issues can be solved by using link-local 
addresses.

This entire mechanism will work during some lapse of time during which 
the devices are within relatively stable distance.

When links start breaking, nodes disappear, other nodes appear - 
re-execute the entire election process.

Now, don't tell me that things move so fast that there is not enough 
time to deal with re-election: there will always be things which move 
too fast for whoever and whatever mechanism to break, including whatever 
AUTOCONF designs.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 22 Oct 2009 23:47:50 -0700

Hello Alex,

This is probably going to be my last rejoinder for a while.

Alexandru Petrescu wrote:
>
> Average transition time (ATT) through some coverage sounds more 
> tempting than simply "speed".
>

This is true, once the functional entities (e.g., DHCP server)
have been identified and established.
> I know why people say DHCP is slow.  I've measured it.  There are 
> quirks with some implementations of the timers.  It's mostly in the 
> discovery phase.  It's the same fundamental reasons why some people 
> complain about slow WiFi link-layer handovers, and slow Mobile IP, and 
> slow NUD, slow ND - which I've also measured.

Those slownesses are not all the same, and some have different causes.

> _waiting_ a pre-defined amount of time.  It's the basics of the basics.

But that observation does not cause the problem to go away.

> presence of some DHCP Server.

This is a very abstract statement, not so easily realizable in
practice.  And maybe even more difficult to do it for all the
protocols you mentioned at the same time.

> phases of DHCP, ND, and FastBSS.  People would have already done it 
> well before.

In fact, we did do it.  Otherwise I wouldn't have been so
interested in the working group.
> Well - you do know for some time.

Yes, but that amount of time is highly
variable and not so predictable.

>
>>  And you can't quote NUD and NA as theorems because of the reasons I 
>> already outlined in previous
> Well I look at it as a distributed election problem.  Dynamically 
> elect the Servers and the Relays, among them.  Of course, afterwards, 
> the elected DHCP Server needs to learn the addresses of the relays and 
> to have routes to them.   These issues can be solved by using 
> link-local addresses.

Once you have unique link-local addresses, yes you can
make such an election using them.  Or, you could make an
election without requiring link-local addresses.  Or you
could supply a more efficient function to replace the DHCP
server without requiring link-local addresses and reducing
the signaling overhead substantially.

So when do we start the design phase and end the
24x7 process of haggling over link-locals?  Oh, wait,
now we have to first resubmit the simple draft for
approval.  I hope that doesn't take too much longer.
> the devices are within relatively stable distance.
Yes, sort-of.
> re-execute the entire election process.
And how do you know that a node disappeared two or seven
hops away?  And what if three nodes disappear in the same
time granule?  Do you get three simultaneous network floods?

> too fast for whoever and whatever mechanism to break, including 
> whatever AUTOCONF designs.

Why would I say that?  I'd just say that you are imposing an
election operation that will further shrink the realm of applicability
for solutions that might be developed.  I fully expect that by the
time we restrict to the realm of applicability appropriate for DHCP,
NA, NUD, and unique link-locals, we'll have a few nodes in the
lab running 802.11.

Regards,
Charlie P.

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 24 Oct 2009 02:49:00 -0700

Hi Alex,

> 3.6s is enough to perform DHCP and many other things.

If you assume wifi, this is not true. You exclude the wireless  
discovery/association time (L2 processing).
You will not get DHCP offer from the server in this case. This is  
reality.

ryuji

> complain about slow WiFi link-layer handovers, and slow Mobile IP,  
> and slow NUD, slow ND - which I've also measured.
>
> AUTOCONF can't propose a discovery mechanism better than the  
> discovery phases of DHCP, ND, and FastBSS.  People would have  
> already done it well before.
>
> elect the Servers and the Relays, among them.  Of course,  
> afterwards, the elected DHCP Server needs to learn the addresses of  
> the relays and to have routes to them.   These issues can be solved  
> by using link-local addresses.
>
> This entire mechanism will work during some lapse of time during  
> which the devices are within relatively stable distance.
>
> When links start breaking, nodes disappear, other nodes appear - re- 
> execute the entire election process.
>
> time to deal with re-election: there will always be things which  
> move too fast for whoever and whatever mechanism to break, including

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 24 Oct 2009 02:51:52 -0700

> but I do not agree with it, and maybe it's time to get some

We shouldn't assume 802.11 only.
I agree with Charlie that MAC addresses uniqueness is not sufficient.
That's what we started the discussion of LL address treatment.

We cannot guarantee the LL address uniqueness along the current IPv6  
spec.
A second after DAD, the neighbors can be changed and LL address can  
now be duplicated.

In some scenarios, this issue might not be applied. However, unless  
there is a case,
we cannot ignore this issue in AUTOCONF.

ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 24 Oct 2009 12:21:51 +0200

> discovery/association time (L2 processing).

No, I dont exclude the L2 processing.  There are L2 attachment 
implementations which take shorter time than others.

There are 2, 4 or 6 wifi L2 messages (depending if security is used) for 
discovery and the L2 discovery phase can be very fast for some 
implementations.

It pretty much depends on the implementation of the L2 Client's waiting 
timers, the ESSID unniqueness among APs, the Client's knowledge of MAC 
address of AP based on location information (GPS), the use of which L2 
security mechanism, the use of AP mode or adhoc mode.

> You will not get DHCP offer from the server in this case. This is reality.

There are implementations and implementations of this.

Some are shorter than others.  When I did fast handovers (without FMIP) 
I could have handovers wifi L2 in the orders of tens of milliseconds, 
under some circumstances; discovery included.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 24 Oct 2009 12:23:41 +0200

Ryuji Wakikawa a écrit :
> We cannot guarantee the LL address uniqueness along the current IPv6 spec.

Can you enumerate the problems you've seen in practice of not assuming 
this uniqueness?

I have never seen one.  I have never seen DAD reporting duplicates either.

Theoretically - yes, DAD was designed in the spirit you talk about.

Alex

> A second after DAD, the neighbors can be changed and LL address can now 
> be duplicated.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 24 Oct 2009 12:26:51 +0200

Ryuji Wakikawa a écrit :
>>>> First, I don't agree with the often suggested assumption that 
>>>> we can rely on MAC addresses for uniqueness.  Maybe we ought to
>>>>  have a new design team or even working group for that, but I 
>>>> think such results are usually required to be clearly labeled 
>>>> as, for instance, "XXXX over IEEE 802.11" or some such.
>>> 
>> Well, you may agree with some other people on that point, but I do 
>> not agree with it, and maybe it's time to get some clarity on this 
>> point.
> 
> We shouldn't assume 802.11 only. I agree with Charlie that MAC 
> addresses uniqueness is not sufficient. That's what we started the 
> discussion of LL address treatment.
> 
> spec. A second after DAD, the neighbors can be changed and LL address
>  can now be duplicated.
> 
> In some scenarios, this issue might not be applied.

I agree on this point, in the scenario I need this issues does not apply.

> However, unless there is a case, we cannot ignore this issue in
> AUTOCONF.

I can't see what are the implications of this, thus Ill stay silent 
about it.

Alex

> 
> ryuji
> 
> 
> 
> 
>> 
>>>> 
>>>> So when you quote "theorems" such as DHCP, without going to the
>>>>  trouble of verifying the requisite preconditions, you are 
>>>> investing confidence in a design that would fall apart like a 
>>>> house of cards in a windstorm.
>>> 
>>> 
>> By making assumptions that are supportable in the area of interest.
>> 
>> 
>> 
>>> 
>>> 
>>> Charles - "speed" as we tend to interpret it may have no sense 
>>> when we consider coverage areas.  Node speed of 300kmph equals 0 
>>> if the coverage is very large.
>> 
>> This is a good point.  Perhaps the proper quantity of interest is 
>> the average transition time through the range of coverage from a 
>> neighboring node.
>> 
>>> 
>>> Node speed of 300kmph going through a 50m wifi area - ok, no 
>>> DHCP: but then one wonders _why_ would a car need to communicate 
>>> anything through that 50m wifi area.
>> 
>> WiFi on the streetlamps and freeway dividers.  At $1.00 per 
>> transceiver chip, it's a reasonable alternative!  It draws a lot 
>> less power than the light bulb.
>> 
>>> 
>> In order to counter this statement (or, more accurately, show why 
>> it is not relevant), I would have to go through the exercise -- but
>>  you had relieved me of that task.
>> 
>> But, roughly speaking, the answer is that you can't have DHCP 
>> unless you know where the server(s) and the relays are.  And when 
>> the nodes are moving, you don't know.  And you can't quote NUD and 
>> NA as theorems because of the reasons I already outlined in 
>> previous messages.  And even if you could, before long you'd have 
>> to get some new relay because you need the relay to be local.  And 
>> more than likely your DHCP server will be occasionally partitioned 
>> into temporary isolation.  But then it's back!  But the relay is 
>> gone!  And then there's something else to go wrong.  But, are _all_
>>  nodes relays?  But, which server has the state?  Or is there just 
>> one server? But that won't ever work!
>> 
>> any belief whatsoever in this theorem. And, with three nodes, 
>> you'll never see the problem. Never!
>> 
>> Regards, Charlie P.
>> 
>> _______________________________________________ Autoconf mailing 
>> list [email-masked]

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 24 Oct 2009 03:37:41 -0700

Hi Alex,

On 2009/10/24, at 3:21, Alexandru Petrescu wrote:

>>>>> when
>>>> the

Ok, but not all implementation can have this feature, right?
AUTOCONF cannot mandate this implementation to any WiFi user.

> There are 2, 4 or 6 wifi L2 messages (depending if security is used)  
> for discovery and the L2 discovery phase can be very fast for some  
> implementations.
>
> It pretty much depends on the implementation of the L2 Client's  
> waiting timers, the ESSID unniqueness among APs, the Client's  
> knowledge of MAC address of AP based on location information (GPS),  
> the use of which L2 security mechanism, the use of AP mode or adhoc  
> mode.

How can we make sure all MANET routers are configured with these  
setting?

> Some are shorter than others.  When I did fast handovers (without  
> FMIP) I could have handovers wifi L2 in the orders of tens of  
> milliseconds, under some circumstances; discovery included.

again, we cannot assume one specific example for addressing  
requirements.
We suppose to deliver a addressing model for MANET, but not for MANET  
under specific environment with specific implementation.

ryuji

>>>> WiFi
>>>> it
>>> quirks with some implementations of the timers.  It's mostly in  
>>> the discovery phase.  It's the same fundamental reasons why some  
>>> people complain about slow WiFi link-layer handovers, and slow  
>>> Mobile IP, and slow NUD, slow ND - which I've also measured.
>>>
>>> What one can do is to shorten the time one waits, at the risk of  
>>> not hearing some things and maybe hitting into someone, or missing  
>>> the presence of some DHCP Server.
>>>
>>>> unless
>>> The Client performs a discovery phase, sending first to a  
>>> predefined multicast address and then waiting.
>>>
>>>> And when the nodes
>>>> And you can't quote NUD and NA as theorems because of the reasons  
>>>> I already outlined in previous
>>> afterwards, the elected DHCP Server needs to learn the addresses  
>>> of the relays and to have routes to them.   These issues can be  
>>> solved by using link-local addresses.
>>>
>>> Now, don't tell me that things move so fast that there is not  
>>> enough time to deal with re-election: there will always be things  
>>> which move too fast for whoever and whatever mechanism to break,  
>>> including whatever AUTOCONF designs.
>>>
>>> Alex
>>>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 24 Oct 2009 03:45:47 -0700

Hi Alex,

On 2009/10/24, at 3:23, Alexandru Petrescu wrote:

> Can you enumerate the problems you've seen in practice of not  
> assuming this uniqueness?
>

I saw many for home address of MIP at returning home because of  
implementation's bugs,,,
The address duplication can be occurred because of not only the MAC  
address duplication, but also bugs in the implementation.

If your observation is true, RFC4862(2462-bis) can be updated like  
"DAD is an option".
But RFC4862 still mandate DAD.
Comparing to wired network, our AUTOCONF environment is a bit severe  
environment for DAD.

Anyway, you and i are too unreliable to report DAD is merely occurred;-)

ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 24 Oct 2009 12:47:06 +0200

> AUTOCONF cannot mandate this implementation to any WiFi user.

Right, no it cant.

>> the use of which L2 security mechanism, the use of AP mode or adhoc mode.
> 
> 
> How can we make sure all MANET routers are configured with these setting?

I dont know about MANET routers.

Non-MANET routers may be configured with _some_ of the features I 
mentioned above, not all.  Only one may suffice to reduce a lot the 
typical handover time of the non-MANET router.

> again, we cannot assume one specific example for addressing requirements.

Ok, I understand that, thanks.  I will concentrate on non-MANET routers 
which run under specific environments with specific implementations.

Alex

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 24 Oct 2009 03:48:04 -0700

On 2009/10/24, at 3:26, Alexandru Petrescu wrote:

>>>>> First, I don't agree with the often suggested assumption that we  
>>>>> can rely on MAC addresses for uniqueness.  Maybe we ought to
>> We cannot guarantee the LL address uniqueness along the current  
>> IPv6 spec. A second after DAD, the neighbors can be changed and LL  
>> address
>> can now be duplicated.

Unless there is a scenario where address uniqueness cannot be  
guaranteed,
we cannot ignore the address duplication issue in AUTOCONF.

ryuji

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 24 Oct 2009 12:52:02 +0200

> I saw many for home address of MIP at returning home because of 

Was that on the link-local address or the global address?

> If your observation is true, RFC4862(2462-bis) can be updated like "DAD 
> is an option".

Sounds logical, but no, it is not my intention.  DAD can help.

You are against not only DAD but also against LLs.

> Comparing to wired network, our AUTOCONF environment is a bit severe 

Ok.

> Anyway, you and i are too unreliable to report DAD is merely occurred;-)

:-)

Well I have seen DAD in action but I haven't seen it reporting 
duplicated link-local MAC-derived IPv6 addresses.  Thus I think I will 
stay silent about this, simply shrugging when facing people who may have 
seen it.

Alex

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 24 Oct 2009 03:55:41 -0700

Hi Alex,

On 2009/10/24, at 3:47, Alexandru Petrescu wrote:

>>>>>> is the
>>> There are 2, 4 or 6 wifi L2 messages (depending if security is  
>>> used) for discovery and the L2 discovery phase can be very fast  
>>> for some implementations.
>>>
>>> knowledge of MAC address of AP based on location information  
>>> (GPS), the use of which L2 security mechanism, the use of AP mode  
>>> or adhoc mode.

fine. This is your network. You have all control.
>> We suppose to deliver a addressing model for MANET, but not for  
>> MANET under specific environment with specific implementation.
>
> Ok, I understand that, thanks.  I will concentrate on non-MANET  
> routers which run under specific environments with specific  
> implementations.

Please understand the addressing model draft is not written only for  
your environment.
The addressing model will be applied to any MANETs.
If you want to have your own addressing model, please write up an  
internet-draft
which title may be  "MANET addressing model extension for Alex's  
network".
With your draft, we can have better understanding of your scenario and  
improve your draft.

However, unfortunately, AUTOCONF WG is not yet at that stage. We still  
build the one generic addressing model for MANET.
Once we finish the addressing model, you should propose a WG item to  
define your addressing model.

make sense?

regards,
ryuji

>>>>>>> DHCP:
>>>>> I know why people say DHCP is slow.  I've measured it.  There  
>>>>> are quirks with some implementations of the timers.  It's mostly  
>>>>> in the discovery phase.  It's the same fundamental reasons why  
>>>>> some people complain about slow WiFi link-layer handovers, and  
>>>>> slow Mobile IP, and slow NUD, slow ND - which I've also measured.
>>>>>
>>>>> Basically one can't do discovery otherwise than emitting and  
>>>>> then _waiting_ a pre-defined amount of time.  It's the basics of  
>>>>> the basics.
>>>>>
>>>>> not hearing some things and maybe hitting into someone, or  
>>>>> missing the presence of some DHCP Server.
>>>>>
>>>>>> And you can't quote NUD and NA as theorems because of the  
>>>>>> reasons I already outlined in previous
>>>>> Well I look at it as a distributed election problem.   
>>>>> Dynamically elect the Servers and the Relays, among them.  Of  
>>>>> course, afterwards, the elected DHCP Server needs to learn the  
>>>>> addresses of the relays and to have routes to them.   These  
>>>>> issues can be solved by using link-local addresses.
>>>>>
>>>>> enough time to deal with re-election: there will always be  
>>>>> things which move too fast for whoever and whatever mechanism to  
>>>>> break, including whatever AUTOCONF designs.
>>>>>
>>>>> Alex
>>>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 24 Oct 2009 12:55:50 +0200

Ryuji Wakikawa a écrit :
>>>>>> have a new design team or even working group for that, but I think 
>>>>>> such results are usually required to be clearly labeled as, for 
>>>>>> instance, "XXXX over IEEE 802.11" or some such.
> Unless there is a scenario where address uniqueness cannot be guaranteed,

Yes, there are scenarios where the uniqueness use of IPv6 link-locals is 
guaranteed: wifi and non-MANET routers.  I dont request to avoid DAD 
operation on them.  But most of the time the uniqueness _is_ guqrqnteed.

"Non-MANET" routers is also what the AUTOCONF Charter calls "ad
hoc-unaware parts".  I could use this term instead.

Alex

>>>> on the streetlamps and freeway dividers.  At $1.00 per transceiver 
>>>> chip, it's a reasonable alternative!  It draws a lot less power than 
>>>> the light bulb.
>>>> is not relevant), I would have to go through the exercise -- but
>>>> you know where the server(s) and the relays are.  And when the nodes 
>>>> are moving, you don't know.  And you can't quote NUD and NA as 
>>>> And then there's something else to go wrong.  But, are _all_

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 24 Oct 2009 04:00:35 -0700

Hi Alex,

On 2009/10/24, at 3:52, Alexandru Petrescu wrote:

>>>> IPv6 spec.

both in many times. I really had hard time to implement the returning  
home on BSD (it was timing sensitive and my poor implementation skill!)

>> Comparing to wired network, our AUTOCONF environment is a bit  
>> severe environment for DAD.
>
> Ok.
>
> duplicated link-local MAC-derived IPv6 addresses.  Thus I think I  
> will stay silent about this, simply shrugging when facing people who  
> may have seen it.

This is not AUTOCONF specific argument, more IPv6 general matter.
The point is that AUTOCONF WG cannot ignore the IPv6 required  
functionalities specially for AUTOCONF without any reason. (well,  
reason we haven't seen the duplication before).

thanks
ryuji

>>>> A second after DAD, the neighbors can be changed and LL address  
>>>> can now be duplicated.
>>>> In some scenarios, this issue might not be applied. However,  
>>>> unless there is a case,
>>>>>> when we consider coverage areas.  Node speed of 300kmph equals  
>>>>>> 0 if the coverage is very large.
>>>>>
>>>>>> DHCP: but then one wonders _why_ would a car need to  
>>>>>> communicate anything through that 50m wifi area.
>>>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 24 Oct 2009 13:12:53 +0200

[...]

:-)

> build the one generic addressing model for MANET.

Dont forget to not disturb the adhoc unaware parts of the system (which 
AUTOCONF Charter promisses to do).

Unrecommending the LLs is to disturb the adhoc unaware parts of the 
system, as exposed by the Carlos draft and by 4 people support of it.

Do you think an adhoc unaware router attaching to the MANET network will 
  be happy to have its DAD's requests unreplied?

> define your addressing model.

The AUTOCONF addressing model should be finished, yes.  Once it's 
finished I wont go against it with _my_ addressing model.  I can live 
without publishing an experimental RFC.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Sat, 24 Oct 2009 13:46:44 +0200

>Van: Ryuji Wakikawa

Hi Ryuji, all,

I have asked some pertinent questions to this workgroup about DAD.
Until now, I didn't see answers. What I see is more and more confusion.

Please confirm that:

1: DAD is not for link-local addresses only
===========================================
DAD MUST run for all types of unicast addresses [RFC 4862, page 12-13].
In reality, it is not a MUST but a SHOULD. I say so, because there are
exceptions [RFC 4862, page 12-13].
It is explicitly mentioned that new implementations MUST NOT do an 
optimization for performing DAD for link-locals only [RFC 4862 page 13].

2: DAD may be disabled, in cases overhead outweighs its benefits
================================================================
It is clearly specified that DAD may be disabled [RFC 4862 page 9].
In my opinion, this is the case where bandwidth usage is constrained
and InterfaceIDs are highly unique or even guaranteed unique.
This is the case in all MANETs I dealt with, and is not restricted to 
IEEE MAC addresses.

Because there is so much misconception on DAD, we fail to make even the 
smallest progress. I ask the chairs to correct all postings on false
statements on what Standards Track RFCs specify.

I am not interested in long discussions on DAD. But what I dislike is
strong opinions on DAD and link-locals that are based on false assumptions.

I continue posting on DAD and link-locals, because I think it is the
foundation for IPv6 Stateless Address Autoconfiguration. We need
some sort of uniqueness, either for each and every address or for a 
piece of the address, that is used for all addresses of a box. I think
the IPv6 Addressing Architecture [RFC 4291] provides what we need, that 
is a 64-bits InterfaceID (unicast address start with binary 000)
[RFC 4291 page 8]. Having unique InterfaceIDs, we can easily add 64-bit 
prefixes, either ULA for MANET-local, or border router provided prefixes
for attached MANETs.

When I read back both proposals for the MANET address model, I see 
bernardos-autoconf-addressing-model is more complete (no open issues)
and better aligns with current Standard Track RFCs. I DO NOT say
link-local addresses MUST be used for routing protocols, but it can
be very practical, as is clearly shown in running code of OSPF-MANET.
Also, there is code of BRDP in simulators that run without problems. 
I respect other opinions on using link-locals, and I have nothing against
weakening mandatory usage of them. The key point here is having unique 
InterfaceIDs. Using it, we are able to swap prefixes easily. We could 
define a protocol for detecting duplicate InterfaceIDs in the MANET, 
this would work for all of us, when needed.

I have posted proposals for corrections on the "DT draft". There was low 
acceptance. I think it doesn't help to resubmit. We have an archive for it.

Regards, Teco

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 24 Oct 2009 14:24:23 +0200

> 1: DAD is not for link-local addresses only

Teco, thanks for digging out this clarification.  It's good to have it 
in one place.

Overall, I think we should not unrecommend any stuff (be it LL or DAD) 
before having comments on this intention from as many people as 
possible, including why not the 6MAN WG.

Alex

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 24 Oct 2009 05:50:50 -0700

Hi Teco,

> 1: DAD is not for link-local addresses only

DAD is mandatory. The document said "MUST".
The exception is for interoperability with older implementations.

> 2: DAD may be disabled, in cases overhead outweighs its benefits

fine in your network, but there are other MANETs not having such  
condition.

> statements on what Standards Track RFCs specify.

What is the misconception?
We cannot fix your issue of the general IPv6 spec. in AUTOCONF WG.

> strong opinions on DAD and link-locals that are based on false  

Even you think it's false, that is the current agreement in IETF  
(according to RFCs).

> be very practical, as is clearly shown in running code of OSPF-MANET.

AFAIK, this issue was closed at the previous consensus call.
We don't open the issue again.  Please respect to the consensus in WG.

> this would work for all of us, when needed.

Your proposal is not what the current IPv6 specs said.
In AUTOCONF env, we will face more chances to have address duplication  
due to topology changes in some scenarios.
We cannot ignore these scenarios and relax the DAD for link-local.

That was what we had discussed at the previous IETF meeting and  
conclusion at the previous consensus call.
I appreciate if you can follow the WG agreement.

regards,
ryuji

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sat, 24 Oct 2009 15:08:46 +0200

> The exception is for interoperability with older implementations.

Or if DupAddrDetectTransmits is set to zero, which I think it is not
forbidden by RFC4862.

Thanks,

Carlos

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

---

From: "Teco Boot" <[email-masked]>
Date: Sat, 24 Oct 2009 15:30:58 +0200

Hi Ryuji,

>-----Oorspronkelijk bericht-----
>Van: Ryuji Wakikawa [mailto:[email-masked]]
>Verzonden: zaterdag 24 oktober 2009 14:51
>Aan: Teco Boot
>CC: [email-masked]
>Onderwerp: Re: [Autoconf] DAD, link-locals, two drafts and making up my
>mind
>
>Hi Teco,
>

Please confirm that DAD has nothing to do with link-locals.

>fine in your network, but there are other MANETs not having such

As far as I know, MANETs struggle with scalability and high overhead.
I remember Charlie on saving every bit sent out, at cost of CPU cycles.

Above, you are wrong. 
DAD is a "MUST", but only when the DupAddrDetectTransmits variable is 
non-zero, not for anycast etc..

I never said I was against a MANET wide duplicate detection. I am against 
mandating such. 

>We cannot fix your issue of the general IPv6 spec. in AUTOCONF WG.

Sorry, you don't get my message. There are no issues in the general
IPv6 specs. They just don't handle the MANET case, and this is well written
in
the documents itself, e.g. [RFC 4861, page 88].

>Even you think it's false, that is the current agreement in IETF

Please come up with references.
I did, and those clearly shows the opposite.

>We don't open the issue again.  Please respect to the consensus in WG.

I think there is no consensus in WG.

>We cannot ignore these scenarios and relax the DAD for link-local.

I did not suggest this at all.
What I say is that the baccelli draft does not address the uniqueness
topic, other than put to shame link-locals and DAD. I posted a few times
now this text is wrong.

>I appreciate if you can follow the WG agreement.

Sorry, but I have to stand up if we [Autoconf] make mistakes. We cannot
allow
another draft in the IESG wastebasket. High chance the baccelli draft
ends this way.

Regards, Teco

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 26 Oct 2009 18:20:10 -0700

Hi Carlos,

> Or if DupAddrDetectTransmits is set to zero, which I think it is not

This value can be set if the link-local address is guaranteed its  
uniqueness without IPv6 DAD operations.
For example, RFC2472

  As long as the Interface Identifier is negotiated in the IPV6CP phase
    of the PPP connection setup, it is redundant to perform duplicate
    address detection as a part of the IPv6 Stateless Autoconfiguration
    protocol [3].  Therefore it is recommended that for PPP links with
    the IPV6CP Interface-Identifier option enabled the default value of
    the DupAddrDetectTransmits autoconfiguration variable [3] be zero.

This value is not introduced to skip the uniqueness check for Link- 
local.
The LL address MUST be always verified its uniqueness .
We cannot change this definition at AUTOCONF WG.
If you mandate the link-local in MANET addressing model, we need a DAD  
mechanism to guarantee the uniqueness.
We've discussed that this DAD is difficult in some scenarios. We knew  
there is a scenario where this DAD can be optimized.
Our addressing model should cover all the possible scenarios.

regards,
ryuji

---

From: Henning Rogge <[email-masked]>
Date: Tue, 27 Oct 2009 07:44:45 +0100

> Our addressing model should cover all the possible scenarios.
That sounds like a good way to introduce a LL protocol for MANETs. If you have 
an unique MAC address, just use it to generate a unique LL. If not you need a 
protocol that ensures 2-hop unique LL IPs or mesh unique IPs for a moving 
MANET.

Henning Rogge
-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-263,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 27 Oct 2009 08:58:42 +0100

>The LL address MUST be always verified its uniqueness .

Total disagreement.
RFC 4862 page 9:
   To accommodate
   sites that believe the overhead of performing Duplicate Address
   Detection outweighs its benefits, the use of Duplicate Address
   Detection can be disabled through the administrative setting of a
   per-interface configuration flag.

>Our addressing model should cover all the possible scenarios.

Total disagreement.
Our charter says "practical addressing model".

If we think IPv6 can boil the ocean, to begin with assigning a 
unique IPv6 address to each and every molecule, and we Autoconf
punish ourselves to achieve this, I'm sure this WG is on a dead end.

Regards, Teco

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 27 Oct 2009 09:35:28 +0100

Teco,

>   per-interface configuration flag.

Yes, however, this will not be the general case, because we want to
accommodate all kind of radio interfaces in a MANET, not just IEEE
interfaces with unique MAC addresses. So while you are right that in certain
settings DAD can be disabled, that does not help us for mandating the use of
LL in autoconf.

> punish ourselves to achieve this, I'm sure this WG is on a dead end.

I don't agree. We are not dealing with an extremely rare and unusual case,
but simply the fact that we cannot assume uniqueness as per IEEE MAC
address. So we need some kind of DAD. And with LLs, it is difficult to
assure uniqueness over several hops, for all time. So their use is very
limited. The DT address model is thus a practical model: It allows us to
configure unambiguous addresses by using host prefixes and unique addresses
MANET-wide. Mandating the use of LLs is not practical, because we will have
a whole bunch of problems to solve, and so far I have not seen a single
proposition of how to do that.

Ulrich

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 27 Oct 2009 10:01:31 +0100

Agree with Teco,

Carlos

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 11:00:21 +0100

Ulrich Herberg a écrit :
> Teco,
> 
> On Tue, Oct 27, 2009 at 8:58 AM, Teco Boot <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Ryuji wrote:
> 
> accommodate all kind of radio interfaces in a MANET,

Ulrich (and Stan too, 100k$ machines) - please state the names and 
specifications of the kinds of radio interfaces other than IEEE you plan 
to use.  IEEE already covers a wide range of radios, WLAN, WPAN, WMAN. 
They even cover "mesh" and "ad-hoc" stuff.  I am saying this after 
having seen same duplicate effort IEEE/IETF on FMIP and FastBSS.

Please say how your links act.

Until you don't say so - it's all a dark area.

Alex

  not just IEEE
> interfaces with unique MAC addresses. So while you are right that in 
> certain settings DAD can be disabled, that does not help us for 
> mandating the use of LL in autoconf.
> 
>  
> 
> 
> 
> I don't agree. We are not dealing with an extremely rare and unusual 
> case, but simply the fact that we cannot assume uniqueness as per IEEE 
> MAC address. So we need some kind of DAD. And with LLs, it is difficult 
> to assure uniqueness over several hops, for all time. So their use is 
> very limited. The DT address model is thus a practical model: It allows 
> us to configure unambiguous addresses by using host prefixes and unique 
> addresses MANET-wide. Mandating the use of LLs is not practical, because 
> we will have a whole bunch of problems to solve, and so far I have not 
> seen a single proposition of how to do that.
> 
> Ulrich
>  
> 
> 
> ------------------------------------------------------------------------
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 11:00:39 +0100

I agree with Carlos.

Alex

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 27 Oct 2009 11:24:30 +0100

Alex,

On Tue, Oct 27, 2009 at 11:00 AM, Alexandru Petrescu <
[email-masked]> wrote:

> specifications of the kinds of radio interfaces other than IEEE you plan to
> use.  IEEE already covers a wide range of radios, WLAN, WPAN, WMAN. They
> even cover "mesh" and "ad-hoc" stuff.  I am saying this after having seen
> same duplicate effort IEEE/IETF on FMIP and FastBSS.
>

We are not a subgroup of IEEE, limiting our work to IEEE interfaces. Our
work on IP layer and above should allow all kind of interface types. As Stan
mentioned, he knows proprietary interfaces. I am not an expert for radio
interface types, but a quick google search gave me this:

http://en.wikipedia.org/wiki/Category:Packet_radio
http://en.wikipedia.org/wiki/Communications,_Air-interface,_Long_and_Medium_range
http://en.wikipedia.org/wiki/DSRC
http://en.wikipedia.org/wiki/Long_Term_Evolution
http://en.wikipedia.org/wiki/EVDO

Not all of these links may be appropriate, but I think it shows that there
are other interface types than just IEEE.

Ulrich

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 11:37:09 +0100

Ulrich Herberg a écrit :
> Alex,
> 
> On Tue, Oct 27, 2009 at 11:00 AM, Alexandru Petrescu 
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> [...] Ulrich (and Stan too, 100k$ machines) - please state the names
> and specifications of the kinds of radio interfaces other than IEEE
> you plan to use.  IEEE already covers a wide range of radios, WLAN, 
> WPAN, WMAN. They even cover "mesh" and "ad-hoc" stuff.  I am saying 
> this after having seen same duplicate effort IEEE/IETF on FMIP and 
> FastBSS.
> 
> We are not a subgroup of IEEE, limiting our work to IEEE interfaces.
> Our work on IP layer and above should allow all kind of interface
> types. As Stan mentioned, he knows proprietary interfaces. I am not
> an expert for radio interface types, but a quick google search gave
> me this:
> 
> Not all of these links may be appropriate, but I think it shows that
>  there are other interface types than just IEEE.

Ulrich, please first, do not point me to wikipedia, I refuse to be
pointed to wikipedia.  I do use it often but I refuse to be pointed to it.

It's like you tell me to go read thousands of pages that you haven't
read either - why do you do so?

That apart.

Which link layer are _you_ particularly concerned with and whose
behaviour you'd like to see accepted in AUTOCONF?  How does this link
layer behave with respect to IPv6?

There may be a risk that you expect it to behave some way and it does
otherwise.

I am saying this after having experimented with several wireless link 
layers: wavelan, wifi, bluetooth, irda, umts, 3g+, gsm, SLIP 2400bps, 
802.16MAC, USB - to name just a few.  My goal was all the time to see 
how IPv6 runs on it.  I can tell you that I was not deceived and each 
time there was a solution, always involving link-local addresses.

What do you think?  What is that link-layer which does not support IPv6
link-layer addresses?

Is it an imaginary link layer?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 11:39:04 +0100

> What do you think?  What is that link-layer which does not support IPv6

Sorry, I meant ^ IPv6 link-local address of course.

Alex

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 27 Oct 2009 11:52:16 +0100

Alex,

> read either - why do you do so?

Because you asked me to name some non-IEEE interfaces. That's what I did. I
let it up to you to read the specifications, if you desire so.
My purpose was only to tell you that we are not solely focusing on IEEE
interfaces. So all assumptions that IEEE interfaces typically have (such as
unique MAC addresses) do not necessarily hold for other interfaces.

> layer behave with respect to IPv6?

I am not particularly concerned with _any_ link layer. We are working purely
on layer 3 autoconfiguration. We should not work on
IP-over-IEEE-only-interface configuration.

> There may be a risk that you expect it to behave some way and it does

I don't have any particular expectation towards the link layer. It's you who
assumes that MAC addresses are unique (as for IEEE interfaces).  I don't.

> 802.16MAC, USB - to name just a few.  My goal was all the time to see how
> IPv6 runs on it.  I can tell you that I was not deceived and each time there
> was a solution, always involving link-local addresses.
>

That's great! But it worked for you because you were using interfaces with
unique MAC addresses (or am I wrong here?). In that case, you also don't
need DAD as defined in RFC4862.

> [Sorry, I meant ^ IPv6 link-local address of course.]
>
>

I don't understand the question.

Ulrich

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 12:13:07 +0100

Ulrich Herberg a écrit :
> Alex,
> 
> On Tue, Oct 27, 2009 at 11:37 AM, Alexandru Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Ulrich Herberg a écrit :
> 
>         [...]
> 
> 
> Because you asked me to name some non-IEEE interfaces. That's what I 
> did. I let it up to you to read the specifications, if you desire so.
> interfaces. So all assumptions that IEEE interfaces typically have (such 
> as unique MAC addresses) do not necessarily hold for other interfaces.

Well, let's agree.  I agree not all MAC addresses are available 
everywhere.  A typical case is USB which uses 48bit addresses called MAC 
but which are not approved by IEEE and thus may clash with MAC addresses 
of IEEE.

My point is to ask you to mention the link layer which you want to use 
and with which you have experience and on which IPv6 LLs are not used.

In the list you have sent me, about which one do you want me to tell you 
my opinions with respect to LLs?  For example, LTE surely will use LLs.
> I am not particularly concerned with _any_ link layer. We are working 
> purely on layer 3 autoconfiguration. We should not work on 

Remark IEEE is not that small, it covers many.

Please state the link layers you're concerned with otherwise it's all 
pure speculation.

> I don't have any particular expectation towards the link layer. It's you 
> who assumes that MAC addresses are unique (as for IEEE interfaces).  I 
> don't.

I don't assume unique MACs IEEE everywhere.  But when that is not the 
case I do know what I am talking about with respect to the link layers I 
have experience with.

What is the non-MAC-IEEE link layer you have experience with and which 
forbids the LLs?

>     I am saying this after having experimented with several wireless
>     link layers: wavelan, wifi, bluetooth, irda, umts, 3g+, gsm, SLIP
>     2400bps, 802.16MAC, USB - to name just a few.  My goal was all the
>     time to see how IPv6 runs on it.  I can tell you that I was not
>     deceived and each time there was a solution, always involving
>     link-local addresses.
> 
> 
> That's great! But it worked for you because you were using interfaces 
> with unique MAC addresses (or am I wrong here?).

YEs, wrong - SLIP doesn't use MAC addresses from IEEE, USB either, 3g+ 
and gsm either.

> In that case, you also don't need DAD as defined in RFC4862.

On a link, there are more means to ensure uniqueness than just DAD.

For example PPP has a means to negotiate it.

Also, the nature of some links (ptp mostly) make such that only two 
nodes are there and the linked formed has unique link-layer addresses (USB).

Also, some non-IEEE SDOs do offer unique MACs within their scopes.

Now, even if a non-IEEE MAC number clashes with a IEEE MAC number, it is 
often the case that is because the two nodes can't talk to each other at 
link-layer - heterogeneous link-layers.  In these cases one can't make 
IP work at all - you can't invent a new IP which solves the 
incompatibilities of the link layers.

One could not connect a bluetooth node to a wifi node, because the PHY 
frequencies are different.

> I don't understand the question.

I don't understand when you state you want to work on links with 
undetermined connectivity properties.  There exist no such links.

What do you want to do?

Alex

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 27 Oct 2009 13:28:22 +0100

Hi Alex,

On Tue, Oct 27, 2009 at 12:13 PM, Alexandru Petrescu <
[email-masked]> wrote:

> [...]
> Well, let's agree.  I agree not all MAC addresses are available everywhere.
>  A typical case is USB which uses 48bit addresses called MAC but which are
> not approved by IEEE and thus may clash with MAC addresses of IEEE.
>
> My point is to ask you to mention the link layer which you want to use and
> with which you have experience and on which IPv6 LLs are not used.
>
> In the list you have sent me, about which one do you want me to tell you my
> opinions with respect to LLs?  For example, LTE surely will use LLs.

I will try to rephrase what I meant: The address model of the DT tries to be
as general as possible, proposing an address model that does not break
anything and that does not have any special assumptions about connectivity.
This discussion about which link layer I prefer or use, does not lead to
anything. We should not limit ourselves in the addressing model to a
particular link layer. If there were only IEEE interfaces in the world, and
if it was assured that in the next some 50+ years there will only be IEEE
interfaces with unique MAC addresses, [autoconf] would have a much easier
task. The DT draft does not assume this limitation (and neither does IPv6
Stateless Autoconfiguration, by the way...).

> Remark IEEE is not that small, it covers many.

Yes, many. But not all.

>
> Please state the link layers you're concerned with otherwise it's all pure
> speculation.

I tried to explain that before: I am not concerned with any particular link
layer. I am concerned with the IP layer. IP over any kind of radio
interface. IEEE have certain nice properties, but there are other interface
types out there that have fewer assumptions. I want to allow such interfaces
to work within a MANET, too. I did not find a general rule for NIC producers
that they must have unique MAC addresses.

>
>
>  [...]
>>
>
> I don't assume unique MACs IEEE everywhere.  But when that is not the case
> I do know what I am talking about with respect to the link layers I have
> experience with.
>

Good! But then you have some additional assumptions. For example, when you
_know_ that all of the interface MACs in your testbed are unique, the DT
draft does not prohibit you from using LLs. It just says that if you _don't_
have such specific assumptions, LLs are of limited use. And this is the more
general case that applies to MANETs that you don't plan beforehand (such as
your testbed at work).

[Skipping the rest of the email.. maybe I'll come back to that later]

Ulrich

>> unique MAC addresses (or am I wrong here?).
>>
>
> YEs, wrong - SLIP doesn't use MAC addresses from IEEE, USB either, 3g+ and
> gsm either.
>
>
> Also, the nature of some links (ptp mostly) make such that only two nodes
> are there and the linked formed has unique link-layer addresses (USB).
>
> link-layer - heterogeneous link-layers.  In these cases one can't make IP
> work at all - you can't invent a new IP which solves the incompatibilities
> of the link layers.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 14:31:28 +0100

Ulrich,

There is a high risk to work on something that we don't what is.

Blindly hiding behind "IP over anything" without saying what is, and 
ignoring the so many IP-over-foo RFC documents - are indicators for this.

Also, there was a zeroconf WG, "to enable networking in the absence of 
configuration and administration".  Doesn't that sound MANETish enough. 
  Well it gave the IPv4 LLs RFC.

Ffwd to 2009 - discourage LLs...

Alex

Ulrich Herberg a écrit :
> Hi Alex,
> 
> 
> On Tue, Oct 27, 2009 at 12:13 PM, Alexandru Petrescu 
>     everywhere.  A typical case is USB which uses 48bit addresses called
>     MAC but which are not approved by IEEE and thus may clash with MAC
>     addresses of IEEE.
> 
>     My point is to ask you to mention the link layer which you want to
>     use and with which you have experience and on which IPv6 LLs are not
>     used.
> 
>     In the list you have sent me, about which one do you want me to tell
>     you my opinions with respect to LLs?  For example, LTE surely will
>     use LLs.
> 
> 
> 
> I will try to rephrase what I meant: The address model of the DT tries 
> to be as general as possible, proposing an address model that does not 
> break anything and that does not have any special assumptions about 
> connectivity. This discussion about which link layer I prefer or use, 
> does not lead to anything. We should not limit ourselves in the 
> addressing model to a particular link layer. If there were only IEEE 
> interfaces in the world, and if it was assured that in the next some 50+ 
> years there will only be IEEE interfaces with unique MAC addresses, 
> [autoconf] would have a much easier task. The DT draft does not assume 
> this limitation (and neither does IPv6 Stateless Autoconfiguration, by 
> the way...).
> 
>  
> 
> 
>            That apart.
> 
>         I am not particularly concerned with _any_ link layer. We are
>         working purely on layer 3 autoconfiguration. We should not work
>         on IP-over-IEEE-only-interface configuration.
> 
> 
>     Please state the link layers you're concerned with otherwise it's
>     all pure speculation.
> 
> 
> I tried to explain that before: I am not concerned with any particular 
> link layer. I am concerned with the IP layer. IP over any kind of radio 
> interface. IEEE have certain nice properties, but there are other 
> interface types out there that have fewer assumptions. I want to allow 
> such interfaces to work within a MANET, too. I did not find a general 
> rule for NIC producers that they must have unique MAC addresses. 
> 
> 
>  
> 
> 
> 
>         [...]
> 
> 
>     I don't assume unique MACs IEEE everywhere.  But when that is not
>     the case I do know what I am talking about with respect to the link
>     layers I have experience with.
> 
> 
> Good! But then you have some additional assumptions. For example, when 
> you _know_ that all of the interface MACs in your testbed are unique, 
> the DT draft does not prohibit you from using LLs. It just says that if 
> you _don't_ have such specific assumptions, LLs are of limited use. And 
> this is the more general case that applies to MANETs that you don't plan 
> beforehand (such as your testbed at work).
> 
> 
>     What is the non-MAC-IEEE link layer you have experience with and
>     which forbids the LLs?
> 
>  
> 
> 
> 
>         That's great! But it worked for you because you were using
>         interfaces with unique MAC addresses (or am I wrong here?).
> 
> 
>     YEs, wrong - SLIP doesn't use MAC addresses from IEEE, USB either,
>     3g+ and gsm either.
> 
> 
>     Now, even if a non-IEEE MAC number clashes with a IEEE MAC number,
>     it is often the case that is because the two nodes can't talk to
>     each other at link-layer - heterogeneous link-layers.  In these
>     cases one can't make IP work at all - you can't invent a new IP
>     which solves the incompatibilities of the link layers.
> 
>     One could not connect a bluetooth node to a wifi node, because the
>     PHY frequencies are different.
> 
>

---

From: sratliff <[email-masked]>
Date: Tue, 27 Oct 2009 10:53:27 -0400

Alex, 

<sarcasm>I was told not to pay attention to this discussion, no?</sarcasm>

Ulrich is correct. The interfaces are proprietary. I¹m not going to go into
a discussion about them in this forum. Ulrich has supplied pointers to
well-known interface types that don¹t adhere to IEEE specs.

Regards,
Stan

On 10/27/09 6:24 AM, "Ulrich Herberg" <[email-masked]> wrote:

> <[email-masked]> wrote:
>> [...]
>> use.  IEEE already covers a wide range of radios, WLAN, WPAN, WMAN. They even
>> cover "mesh" and "ad-hoc" stuff.  I am saying this after having seen same
>> duplicate effort IEEE/IETF on FMIP and FastBSS.
>> 
> We are not a subgroup of IEEE, limiting our work to IEEE interfaces. Our work
> on IP layer and above should allow all kind of interface types. As Stan
> Not all of these links may be appropriate, but I think it shows that there are
> other interface types than just IEEE.
> 
> Ulrich 
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 16:16:27 +0100

sratliff a écrit :
> Ulrich is correct. The interfaces are proprietary. I’m not going to go 
> into a discussion about them in this forum. Ulrich has supplied pointers 
> to well-known interface types that don’t adhere to IEEE specs.

Stan - I am sorry, I can not help to run IPv6 on proprietary interfaces 
about which you don't want to talk.  Please de-proprietarize them somehow.

It makes no sense for you to say that the DT proposal works with your 
proprietary interface as long as you can't get feedback from the WG 
about it.

If it works within your env - ok, good luck.

But if you bring it here - then please talk about it.

It may very well be that your env does use IPv6 link-local addresses too 
(as some OLSR implementations do use them too).

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 27 Oct 2009 09:17:16 -0700

Hello Teco,

> punish ourselves to achieve this, I'm sure this WG is on a dead end.

You are missing the very important point that
the problem of assigning global addresses in an
ad hoc network, without relying on link-local
addresses, has _already been solved_.  In multiple
ways.  In innovative ways.  In boring ways.

It's not boiling the ocean, which may well
dry up before the LL crew admit the
abovementioned reality.

In fact, convincing the stalwart defenders of
link-local addressing that it can be done, has
proved to be orders of magnitude more difficult
than actually just doing it.

Such is the IETF.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 27 Oct 2009 09:19:06 -0700

Hello Carlos,

> Agree with Teco,

Then you too are denying the fact that we have
already done what needs to be done in many
different ways.  It would be nice for the practitioners
who have done it, to be able to standardize on
one approach.

Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 27 Oct 2009 17:26:35 +0100

> ways.  In innovative ways.  In boring ways.
I must admit I still sometimes miss the point of the discussion.

If the "generate mesh unique IPs without linklocal IPs" is already solved 
(maybe not perfect, but in many different ways, have read a few of them), why 
don't we just suggest to use the SAME algorithms and protocolls to generate 
the linklocal IPs ? Just take the unique postfix and add the linklocal 
praefix. The result should be definitely link-unique.

Henning Rogge

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 27 Oct 2009 09:28:35 -0700

Hello Alex,

Alexandru Petrescu wrote:
> specifications of the kinds of radio interfaces other than IEEE you 
> plan to use.  IEEE already covers a wide range of radios, WLAN, WPAN, 
> WMAN. They even cover "mesh" and "ad-hoc" stuff.  I am saying this 
> after having seen same duplicate effort IEEE/IETF on FMIP and FastBSS.
>
Emmanuel and I wrote an Internet Draft describing the
properties of these links.

You read it.

Shall we post it again?

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 27 Oct 2009 09:29:53 -0700

Hello Alex,

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 27 Oct 2009 09:36:42 -0700

Hello Alex,

> pointed to wikipedia.  I do use it often but I refuse to be pointed to 

Why?

> read either - why do you do so?

What if someone reads the article and then finds
it to be potentially valuable for you?  Why not
offer a readily available source of information?

> layer behave with respect to IPv6?

This is the IETF.  Link-agnostic sorts of folks.

> time there was a solution, always involving link-local addresses.

With three nodes?

> Is it an imaginary link layer?

It's not the link-layer that doesn't support IPv6 addresses.

It's the link layer that doesn't support guaranteed layer-2
unique addresses.

It's the mobility that makes this into a threat against
link-layer address uniqueness.

Which, honestly, I think you could figure out directly
except that it's so much fun to argue.

Regards,
Charlie P.

---

From: sratliff <[email-masked]>
Date: Tue, 27 Oct 2009 12:43:41 -0400

Alex, 

You miss the point. There are other, non-IEEE interfaces that we *can*
discuss. Ulrich has given you a (partial) list. What I'm trying to tell you
is, if we consider those interfaces, and design accordingly, my proprietary
interfaces should work.

So there are things we can openly discuss. I just don't see a lot of
progress when we discuss them.

Regards,
Stan

On 10/27/09 11:16 AM, "Alexandru Petrescu" <[email-masked]>
wrote:

>> Ulrich is correct. The interfaces are proprietary. I¹m not going to go
>> to well-known interface types that don¹t adhere to IEEE specs.
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 27 Oct 2009 09:53:44 -0700

Hello Alex,

> There is a high risk to work on something that we don't what is.

You too are denying the fact that we have
already done what needs to be done in many
different ways.  It would be nice for the practitioners
who have done it, to be able to standardize on
one approach.

> ignoring the so many IP-over-foo RFC documents - are indicators for this.

Blindly assuming MAC-layer uniqueness is an indication
of a bad fit for the [autoconf] working group, I think.
> configuration and administration".  Doesn't that sound MANETish 
> enough.  Well it gave the IPv4 LLs RFC.
I was there.  It was maximally non-MANET.  In fact, it was a single 
extent of Ethernet.

That's not a MANET.

And it was terribly political.  Ohh... well maybe that isn't a difference.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 18:04:10 +0100

> properties of these links.

Sorry which draft?

I will read it again if you need my feedback.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 18:05:03 +0100

> who have done it, to be able to standardize on

Does what you have done involve link-layer addresses or not?  Does it 
allow them to exist or not?

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 27 Oct 2009 10:08:18 -0700

Hello Alex,

> allow them to exist or not?

It did not involve link-layer addresses.  It did not prohibit,
encourage, or validate link-layer addresses in any way.
Not our problem.  We just wanted to achieve a solution
for address assignment in ad hoc networks.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 27 Oct 2009 10:19:08 -0700

Hello Alex,

> I will read it again if you need my feedback.

http://www.potaroo.net/ietf/all-ids/draft-baccelli-multi-hop-wireless-communication-02.txt

Feedback is always appreciated, but the main point is that
I believe you already read this draft, and I think it answers
all of your questions about the kinds of wireless network
interfaces under consideration for [autoconf].

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 18:24:09 +0100

> offer a readily available source of information?

That's easy.

The common tendency when pointing to so many URLs is to google the 
keywords and then paste large body of evidence.  Very often that 
evidence is not read by the posters themselves.  For example (and no 
offence intended) Ulrich pointed to LTE, among others, whereas we're 
almost sure LTE will use link-local addresses.

Pointing someone to google search results as evidence of something is 
alos wrong because the single negative thing about google is that it 
can't offer proofs of non-existence.

I.e. people wrongly believe that because something is not on google then 
it does not exist - and that's people's wrongly using google fault. 
Same with wikipedia - if something is _not_ in wikipedia people tend to 
think it does not exist or, at least, is not important enough.

This means that because wikipedia doesn't have an article saying "Many 
protocols use LLs" then people tend to think I am wrong.

Well, what if I write such a wikipedia article then?  Should I spend 
cycles on that or on IETF?

> This is the IETF.  Link-agnostic sorts of folks.

This is IETF - IPv6-over-foo sorts of folks.

>> time there was a solution, always involving link-local addresses.

Well, more.  If I enumerated that many links there were at least that 
many nodes.

> It's the link layer that doesn't support guaranteed layer-2

Ok!  I know one, it's USB.  USB MAC addresses are "unique" among USBers 
but may clash with IEEE MAC addresses.

That doesn't mean DAD won't spot them.

> except that it's so much fun to argue.

I had a point to make, not only fun to argue.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 18:24:56 +0100

> progress when we discuss them.

LEt's enumerate them.

If we enumerate them you'll see a large number of them do use LLs.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 18:29:53 +0100

> who have done it, to be able to standardize on

Err... go ahead, I won't be part of it.

Started this way there's little incentive to look into it.

> of a bad fit for the [autoconf] working group, I think.

Right.  Let's say I assume DAD could help detecting duplicates.

> I was there.  It was maximally non-MANET.  In fact, it was a single 

At least it has that "adhoc non-planned" nature in it, by saying 
"absence of conf and admin".

> And it was terribly political.  Ohh... well maybe that isn't a difference.

Hmmm... politics.  Yes you can.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 27 Oct 2009 10:34:31 -0700

Hello Alex,

> almost sure LTE will use link-local addresses.
It uses such addresses only after an extended negotiation
that already insures uniqueness, and anyway all such nodes
are equipped with guaranteed unique sub-IP layer addresses.

>
> I.e. people wrongly believe that because something is not on google 
> then it does not exist - and that's people's wrongly using google 
> fault. Same with wikipedia - if something is _not_ in wikipedia people 
> tend to think it does not exist or, at least, is not important enough.

This statement may be true for some people, but I doubt it is
true for Ulrich -- or, indeed, you, or me, or Teco, or Carlos,
or anyone else in this discussion.

> protocols use LLs" then people tend to think I am wrong.

Sorry, Alex, this is purely straw-man argumentation.

> cycles on that or on IETF?

It would be more productive than this recent discussion.

> This is IETF - IPv6-over-foo sorts of folks.

You are missing that _first_ we specified IPv6 to run over
layer-2 without specifying very many particular layer-2
characteristics.  Then the IPv6-over-foo documents laid
out the necessary techniques for adaptation.

But I am pretty sure you knew that, and only make the
remark as a clever sound-bite trying to extend the pointless
argumentation.

> Well, more.  If I enumerated that many links there were at least that 

Links != nodes.

> Ok!  I know one, it's USB.  USB MAC addresses are "unique" among 
> USBers but may clash with IEEE MAC addresses.

Usually I at least understand the context for pointless
argumentation but now I have lost even that meager
thread to what you might have in mind.

> That doesn't mean DAD won't spot them.

Nobody ever claimed that DAD was incapable of
spotting address conflicts.

> I had a point to make, not only fun to argue.

I must have missed that.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 18:35:28 +0100

> encourage, or validate link-layer addresses in any way.

SO your solution does not have anything agains LLs.  So why go 
discourage them in the addressing model draft?  Why even talking about 
them in the draft?

> for address assignment in ad hoc networks.

I have to read that solution now.  Where is it?

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 27 Oct 2009 10:47:34 -0700

Hello Alex,

I think you have very well identified
an interesting point.

> Started this way there's little incentive to look into it.

So let's be clear here.

- People built ad hoc wireless networks.
- They work with statically assigned addresses.
- A method for address autoconfiguration was
  desired.
- Internet Drafts were written for that purpose
- A working group was formed to resolve
   differences in the approaches
- An addressing model was required
- An addressing model was produced that
   enabled solutions in the general solution space
   of the published solutions
- You seem to even disavow the validity of
   considering wireless networks of the sort that
   is of interest to the original practitioners
- You now claim that you won't be part of the
   solution team.

So do you stand in the way of other peoples'
progress?

> Right.  Let's say I assume DAD could help detecting duplicates.

That was never at issue.

>
>>> Also, there was a zeroconf WG, "to enable networking in the absence 
>>> of configuration and administration".  Doesn't that sound MANETish 

There are many unplanned events, no doubt.

> Hmmm... politics.  Yes you can.

You are making fun of me.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 18:52:23 +0100

> are equipped with guaranteed unique sub-IP layer addresses.

Ok - but we can't say LTE doesnt use LL addresses, right?  In this 
sense, the redirection to wikipedia looses a bit of sense. (although 
there are other part sin that redirection which do make sense).

> or anyone else in this discussion.

Ok this.

> Sorry, Alex, this is purely straw-man argumentation.

It's good, so I don't need to do it.  I can persuade without going 
wikipedia.

> It would be more productive than this recent discussion.

All discussion?  DO you agree with at least one of the points Im trying 
to make?

> remark as a clever sound-bite trying to extend the pointless

The point is to show that IPv6 protocols and links _do_ use link-local 
addresses and that disocuraging them makes little sense.

>> Well, more.  If I enumerated that many links there were at least that 

At least two nodes per link, otherwise no need to link anybody.

> thread to what you might have in mind.

The point is to not discorage LLs.

>> I had a point to make, not only fun to argue.

Don't discourage the LLs, my point is.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 18:58:28 +0100

> So do you stand in the way of other peoples'

Right, no, I don't.  Good luck.

>> Right.  Let's say I assume DAD could help detecting duplicates.

But the addressing model draft discards DAD.  IT does not understand how 
DAD works and discards it.  Look at this text:

>   o  Even if tested for local uniqueness at one moment using
>       Duplicate Address Detection [RFC4862], a duplicate link-local
>       address might appear as a neighbor the next moment, without it
>       being an explicit event that would trigger DAD again.  Such
>       duplication would thus go undetected.

There is an explicit event which happens when linking to a network: 
unsolicited NA; NS too.  That may trigger many things.

> You are making fun of me.

Sorry, no intention.  My point is to not discourage the LLs.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 27 Oct 2009 11:06:49 -0700

Hello Alex,

Alexandru Petrescu wrote:
>
>>>
>>> Does what you have done involve link-layer addresses or not?  Does 
>>> it allow them to exist or not?
>>>
>>

Perhaps you missed the first 50 times that I stated I do not have
anything against link-local addresses.  They are useful when there
is a link on which link-local address uniqueness can be maintained.

Oh, by the way.... please keep in mind that I am not against
link-local addresses, just in case you ever feel tempted to
make that false implication in the future.

As far as link-locals in the draft -- I thought they were only
there because of interactions with people who wanted to
include them as part of the address architecture.  If we can
get the draft promulgated without any mention of link
locals and without any mandate for autoconfiguring
addresses based on the properties of link-locals, then
that would be fine with me.

Then we can have a separate informational document,
perhaps purely as an individual submission, which describes
the pitfalls of using link-locals in ad hoc networks.

> I have to read that solution now.  Where is it?
I'm having a little trouble finding my old documents.
This is work done well over five years ago.

I'll send another message when I find them.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 27 Oct 2009 11:30:38 -0700

Hello Alex,

I found a copy of our very old solution.  Perhaps it could
be done better now with _eight years_ experience since
it was published -- and that makes it nearly _ten years_
since the system was implemented.

Please see:
http://www.psg.com/~charliep/txt/ietf76/autoconf.txt

But, instead, we've had oh-so-much fun dallying over
verbiage on link-locals.  I think the repeated discussion
over the same discredited points has been an extraordinarily
poor investment of time.

By the way, I'm not really interested in incorporating
comments on the draft.  It would still be a good basis for
starting work on the solution space, but there are other
ways to do it, and I don't want to get bogged down in
nitpicking over the details of this draft.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 19:37:40 +0100

Thanks for the draft Charles.

I will not hurry to read it then.

Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 27 Oct 2009 19:37:43 +0100

(text skipped)
> I'll send another message when I find them.

Maybe it is included in the survey draft we wrote in the past:

http://tools.ietf.org/html/draft-bernardos-manet-autoconf-survey-04

:-)

Otherwise, let me know to include it in future revisions of the draft.

Thanks,

Carlos

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 27 Oct 2009 12:00:32 -0700

Hello Carlos,

Yes, it is the same protocol that you described in your draft.
I think you draft should be considered important background
material for understanding the issues.

Once we get to work, that is.

Regards,
Charlie P.

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 27 Oct 2009 23:59:41 -0700

Teco,

>   per-interface configuration flag.

If your statement is correct, we don't need DAD at the ethernet link  
(any link).
Do you ever think why IPv6 mandate the DAD even for the ethernet link?  
why?

> punish ourselves to achieve this, I'm sure this WG is on a dead end.

AUTOCONF does not prohibit using LL.. I don't know how you will be  
punished.

regards,
ryuji

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 28 Oct 2009 08:05:33 +0100

>Charles E. Perkins wrote:

Yes. I think this draft is very helpful.
And please correct or leave out exposed node.

Regards, Teco

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 28 Oct 2009 08:07:19 +0100

Can you remind me, Teco, what was wrong with "exposed node"?

Thanks,

Thomas

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 28 Oct 2009 08:15:53 +0100

Hi Charlie,

>interfaces under consideration for [autoconf].

I think Autoconf shall also work on other link types. Link types
with LLs, DAD and all the usual stuff.

Same is true for MANET routing protocols, these shall work also
on a broad range of link types (although OLSR - MPR cannot 
support most of them, see MANET archive for details).

Regards, Teco

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 28 Oct 2009 08:18:30 +0100

On Oct 28, 2009, at 8:15 AM, Teco Boot wrote:

> Hi Charlie,
>
>> http://www.potaroo.net/ietf/all-ids/draft-baccelli-multi-hop- 
>> wireless-
>> communication-02.txt
>>

I can't let an untrue statement stay unanswered, but I think you must  
be doing it wrong if you can't make OLSR or MPRs run correctly. That  
said, I would like to suggest moving the discussions on [manet]  
routing protocols to the [manet] list.

Thanks,

Thomas

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 28 Oct 2009 08:54:56 +0100

Hi Charlie,

>ways.  In innovative ways.  In boring ways.

I made my comment on "all the possible scenarios".
We never will reach this goal.

I'm sure your "solution" will not work in all
cases. What about a MANET merge? This is a
common scenario in my environment. What
about (unneeded) overhead? How to swap
globals when attachment to Internet changes?
Uses it classical flooding? Does it provide
A unique Interface ID, so it provide also
Unique LLs? 

(but please provide pointers, I'll take a look at it). 

((
  I saw the ref to ietf-manet-autoconf. Shall I comment
  on the IPv4 LLs ?  Oeps, I did! OK, IPv4 LLs work
  different as was assumed at that time.
  On answers above:
  - It provides unique LLs, for IPv4 and IPv6
  - MANET merges break guaranteed uniqueness
  - Classical flooding is used, or maybe some
    optimization (not described). Overhead can be
    unacceptable, especially when addresses are defended
    in whole lifetime.
  - IPv6 prefix swap for getting globals is supported, 
    Just like BRDP (and others; BRDP is a method to
    provide the prefix, and is thus complementary).
  And I don't see how parallel duplicate checks are
  handled. This was the goal of the protocol, right?
))

>dry up before the LL crew admit the

I really want to stop the LL discussion ASAP. I suggested
text months ago, which I think can be agreed on by all of us.

>than actually just doing it.

This is your opinion. Accepted.
But please accept LLs are very useful also. 

Regards, Teco

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 28 Oct 2009 09:22:11 +0100

Hi Ryuji,

>Do you ever think why IPv6 mandate the DAD even for the ethernet link?

DAD is *ONLY* required when the flag is set to do so.
On high speed Ethernet, the overhead and delay are low, so DAD is 
not harmful. But on wireless networks, this may be different,
and in some of my use cases, it is very, very different.

I think that DAD for manual configured addresses is far more important
than for EUI-64 or PRN addresses. Even for DHCP assigned, sequenced 
addresses, DAD helps in cases DHCP cannot ensure uniqueness (I do not
like this approach, but I understand the need for it).

So it is not mandating or banishing DAD. DAD is a nice tool, enabled by
default and disabled when it is harmful. 
Even in a MANET, I can think of a MANET wide check for uniqueness during
generation and 1-hop DAD during lifetime. We can use SeND for it.

>AUTOCONF does not prohibit using LL.. I don't know how you will be

I hope you leave configuring each molecule out of scope for Autoconf.

Regards, Teco

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 28 Oct 2009 09:32:52 +0100

On: draft-baccelli-multi-hop-wireless-communication-02

>Thomas Heide Clausen wrote:

Figure 2 is correct now.
When A sends to B, C is prohibited to send to D due to CS.
But if C was not blocked, B still would receive A.
So preventing C sending to D is reducing the capacity
of the wireless channel (spatial reuse is less optimal).
This problem has little to do with IP.

Text in error:
> Even
> though node C cannot hear D, node D can nevertheless hear C, because
> node D is outside node A's radio range.

And:
> the exposed node
> problem is a practical example of the asymmetry
Here, exposed node has little to do with asymmetry (as defined in same
document.

Regards, Teco

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 28 Oct 2009 09:42:32 +0100

Teco,

(I change the subject line, as this really is a new thread of  
discussion)

> This problem has little to do with IP.

Alright.

> Here, exposed node has little to do with asymmetry (as defined in same

What you say makes sense to me.

I'm not an author of that document, and it's not a wg document -- but  
knowing Charlie/Emmanuel I'm almost willing to bet that they'd be  
happy to incorporate a change to reflect this (if they agree, of  
course). Could you propose replacement paragraphs or rewordings?

Any other issues that you would like to see addressed in that document?

Baccelli/Perkins, feel free to bounce an updated I-D to the list, even  
if it can't be submitted to the repositories just yet. In my  
experience, quick turn-around cycles for "alpha's" are a good way of  
getting both eyes on the document and making rapid progress.

We can then discuss in Hiroshima what to do forward?

Thanks,

Thomas

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 28 Oct 2009 09:55:30 +0100

All,

Just to repeat my responses / opinion on WG documents.

I support draft-baccelli-multi-hop-wireless-communication for 
adoption as WG document. I know it is not our charter, but
IMHO the document is very useful. Also, it (partly?) solves
an open issue (MANET link model) in the baccelli-autoconf-adhoc
-addr-model .
I remember an AD saying we are allowed to submit an Informational
Document, if it helps achieving our milestones.

Did authors present this doc at an Autoconf meeting? 

Regards, Teco 

>Van: Thomas Heide Clausen [mailto:[email-masked]]
>Verzonden: woensdag 28 oktober 2009 9:43
>Aan: Teco Boot
>CC: Charles Perkins; [email-masked]; Emmanuel Baccelli
>Onderwerp: Discussion on draft-baccelli-multi-hop-wireless-
>communication-02
>
>Teco,
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 28 Oct 2009 09:56:35 +0100

YEs, I support this draft draft-bernardos-manet-autoconf-survey-04 to 
become a WG item.

It is a comprehensive overview of past descriptions of autoconfiguration 
  mechanisms.

Once it is a WG item I will have more remarks on it.

I will not condition the adoption of this WG item by the deadline of 
when we start to work because this WG already has many WG items about 
which I am not sure whether they have been adopted or not by the WG.

This draft is good work which should be adopted.  It should have been 
adopted long time in the past.  If this WG wanted to deliver only _one_ 
  WG item then I'd prefer it to be this draft.

Alex

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 28 Oct 2009 10:01:54 +0100

Hi,

> Document, if it helps achieving our milestones.

I agree with Teco that the baccelli/perkins document is useful and should
become a WG document. However, I am undecided whether this should happen
_now_ or only after progressing with an address model draft first. I am not
sure whether the IESG would appreciate having a second document right now...
If Teco is right, and the AD agrees on having an informational draft, and if
that draft helps us to progress, we might publish it now (after some rework,
as suggested by Teco in a previous mail).

Ulrich

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 28 Oct 2009 10:15:40 +0100

Teco,

Thanks for the support.

<wg-chair-hat-on>

I think that the first steps should be revival of draft-baccelli-multi- 
hop-wireless-communication (if the authors are willing - it's an  
individual I-D), to bring it up to date, incorporating comments etc.

I also think that if I propose to our AD to add further documents as  
wg documents, he'll look at me weirdly and ask 'so where are we with  
the addressing model, then, the current wg charter item'?

If my answer is "we're making great progress, the addressing model  
actually uses this/these other documents, go look at them on this URL,  
but I feel we're ready to submit to the IESG within a month", then  
he'll probably be quite receptive to the idea. Otherwise, I doubt  
he'll be enthusiastic, considering our spectacular record of not  
making measurable progress thus far.

Therefore, my immediate concern is to get the wg charter item in  
shape. If this -- or any other document -- is needed for that end,  
let's advance those as individuals for now. When the WG is certain  
that there's a strong case for asking the AD to allow us to accept  
further documents, I'll make that case to the AD.

I think that there're no inconveniences to this approach, considering  
that I think that Baccelli/Perkins are receptive to WG input.

To answer your question, I do not think that this document has been  
presented at an autoconf meeting. Should the authors be interested in  
doing so in Hiroshima, and should the WG think that it would help,  
then I don't see any problems in having a slot during the autoconf  
session for that.

Cheers,

Thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 28 Oct 2009 10:23:00 +0100

Without making any comments on the quality and interest in general of  
raft-bernardos-manet-autoconf-survey, the [autoconf] wg is not  
chartered to provide a survey of protocols representing a "snapshot at  
a given time".

We're at a juncture where the choices are either (a) pulling the plug  
on the WG or (b) making progress on the charter item.

Note that "adopting new work directions" are not among the choices.

Thomas

On Oct 28, 2009, at 9:56 AM, Alexandru Petrescu wrote:

> YEs, I support this draft draft-bernardos-manet-autoconf-survey-04  
> to become a WG item.
>
> It is a comprehensive overview of past descriptions of  
> autoconfiguration  mechanisms.
>
> when we start to work because this WG already has many WG items  
> about which I am not sure whether they have been adopted or not by  
> the WG.
>
> This draft is good work which should be adopted.  It should have  
> been adopted long time in the past.  If this WG wanted to deliver  
> only _one_  WG item then I'd prefer it to be this draft.
>
> Alex
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 28 Oct 2009 11:08:23 +0100

Thomas Heide Clausen a écrit :
> raft-bernardos-manet-autoconf-survey, the [autoconf] wg is not chartered 
> to provide a survey of protocols representing a "snapshot at a given time".

I agree it is not now.  If, in the future.

> We're at a juncture where the choices are either (a) pulling the plug on 
> the WG or (b) making progress on the charter item.

I believe making progress on charter item has started badly.

> Note that "adopting new work directions" are not among the choices.

Ok, not now.

Alex

>> adopted long time in the past.  If this WG wanted to deliver only 
>> _one_  WG item then I'd prefer it to be this draft.
>>
>> Alex
>>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Oct 2009 13:13:13 +0200

> Note that "adopting new work directions" are not among the choices.

Thomas is correct in the above. You REALLY need to complete the 
architecture document.

Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 28 Oct 2009 12:41:38 +0100

> Thomas is correct in the above. You REALLY need to complete the 

Jari, please allow me to suggest correction to you.

We talk about an addressing model document, not the architecture document.

I am saying so because there is also an AUTOCONF architecture document 
"Mobile Ad hoc Network Architecture" - which I think is not what you 
mean(?).

Alex

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Oct 2009 13:54:47 +0200

Alex - yes I did mean the addressing model document. Sorry for the 
confusion.

Jari

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 28 Oct 2009 11:44:05 -0700

Hi all,

On 2009/10/28, at 2:15, Thomas Heide Clausen wrote:

> Teco,
>
> Thanks for the support.
>
> <wg-chair-hat-on>
>
> I think that the first steps should be revival of draft-baccelli- 
> multi-hop-wireless-communication (if the authors are willing - it's  
> an individual I-D), to bring it up to date, incorporating comments  
> etc.
>
> actually uses this/these other documents, go look at them on this  
> URL, but I feel we're ready to submit to the IESG within a month",  
> then he'll probably be quite receptive to the idea. Otherwise, I  
> doubt he'll be enthusiastic, considering our spectacular record of  
> not making measurable progress thus far.
>
> I think that there're no inconveniences to this approach,  
> considering that I think that Baccelli/Perkins are receptive to WG  
> input.
>
> presented at an autoconf meeting. Should the authors be interested  
> in doing so in Hiroshima, and should the WG think that it would  
> help, then I don't see any problems in having a slot during the  
> autoconf session for that.

I agree with Thomas, we should first focus on the addressing model and  
complete the only one WG item.
I would like to focus on the one AUTOCONF WG item at this moment.

According to the ML discussion, there are certain interests from WG  
and relationship to the addressing model document.
I am fine with a presentation slot for this work at Hiroshima if  
authors can incorporate the recent WG discussion in the presentation.
The document is also expired a month ago.

regards,
ryuji