Subject: [Autoconf] Protocols involving link-local addresses

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 16:33:37 +0100

In several earlier discussions question was raised about which protocols 
use link-local addresses.

IPv4
----
mDNS
ARP (the parts in IPv4 LL RFC)

IPv6
----
DHCP
OSPF
RIPng
MLD
OLSR (a particular implementation)

If you know any other, feel free to add.  I think it may be useful to 
add to the AUTOCONF addressing model draft(s).

(I think Teco may have already written such a list but I have hard time
  finding it).

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 16:56:45 +0100

Updated list: added PPP IPv6, ND, ICMPv6, MIPv6 family.

IPv4
----
mDNS

IPv6
----
DHCP
OSPF
RIPng
MLD
ND
PPP IPv6
ICMPv6
SLAAC
FMIPv6
MIPv6/NEMOv6/PMIPv6

Alex

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

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 26 Oct 2009 17:04:20 +0100

That's great and these all run fine across a MANET. That's the beauty  
of end-to-end, you see, as long as the routers present "just an IP  
hop", then applications on end systems are happy.

Thomas

On Oct 26, 2009, at 4:56 PM, Alexandru Petrescu wrote:

>> In several earlier discussions question was raised about which  
>> protocols use link-local addresses.
>> IPv4
>> ----
>> mDNS
>> If you know any other, feel free to add.  I think it may be useful  
>> to add to the AUTOCONF addressing model draft(s).

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 17:09:47 +0100

Thomas Heide Clausen a écrit :
> That's great and these all run fine across a MANET. That's the beauty of 
> end-to-end, you see, as long as the routers present "just an IP hop", 
> then applications on end systems are happy.

I don't understand you.  Please add a protocol to my list; that is the 
goal of the list.

Presenting "just an IP" hop is like routers acting at L2.  Is this some 
sort of a layer violation?

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 26 Oct 2009 17:10:22 +0100

On Oct 26, 2009, at 5:09 PM, Alexandru Petrescu wrote:

>> That's great and these all run fine across a MANET. That's the  
>> beauty of end-to-end, you see, as long as the routers present "just  
>> an IP hop", then applications on end systems are happy.
>
> I don't understand you.  Please add a protocol to my list; that is  
> the goal of the list.
>
> Presenting "just an IP" hop is like routers acting at L2.  Is this  
> some sort of a layer violation?
>

No, it's actually exactly what a router is supposed to do.

Thomas

>>>> If you know any other, feel free to add.  I think it may be  
>>>> useful to add to the AUTOCONF addressing model draft(s).

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 26 Oct 2009 17:12:39 +0100

> I don't understand you.  Please add a protocol to my list; that is  

Ok, I'll try:

	http

I am not sure I understand the game, shall it just be any odd protocol  
that works fine across a MANET? Then, it'll be a long list ;)

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 17:19:47 +0100

>> I don't understand you.  Please add a protocol to my list; that is the 

Well thanks, let me just make sure: does http use link-local addresses? 
  Some times?  IPv6 LL? IPv4 LL?

> that works fine across a MANET? Then, it'll be a long list ;)

Protocols working fine across MANET and using link-local addresses?  Er? 
So why do you discourage the LLs then?

My goal is not a game, is to build a list by AUTOCONF members of 
protocols using IPv6 link-local addresses which risk be affected if the 
recommendation is to discourage LLs.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 17:23:21 +0100

> No, it's actually exactly what a router is supposed to do.

Hmm... no doubt we are in contradiction.

Two routers --R1--R2-- don't present an IP hop, there are three subnets 
and two IP hops.

I think you don't agree with this model at all and you propose

   ---|----|---
      R1   R2

where R1 and R2 IP forward with host-based routes.  I know.  I just 
don't see it that way.

I believe both views should be accepted.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 26 Oct 2009 17:24:03 +0100

I would limit the list to protocols that are applicable to MANETs.
This is a non-empty list. For IPv6:
  OSPF-MANET
  NDP RA
  MLD
And I have my own middleware products that use LL for Peer discovery
or 1-hop message disctribution (I could use hop-limit=1).

Teco.

>-----Oorspronkelijk bericht-----
>Van: [email-masked] [mailto:[email-masked]] Namens
>Alexandru Petrescu
>Verzonden: maandag 26 oktober 2009 16:34
>Aan: [email-masked]
>Onderwerp: [Autoconf] Protocols involving link-local addresses
>

I would limit the list to protocols that are applicable to MANETs.
This is a non-empty list. For IPv6:
  OSPF-MANET
  NDP RA
  MLD
And I have my own middleware products that use LL for Peer discovery
or 1-hop message disctribution (I could use hop-limit=1).
I would prefer LLs for OLSR also.

Teco.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 26 Oct 2009 17:26:13 +0100

On Oct 26, 2009, at 5:19 PM, Alexandru Petrescu wrote:

>>>> beauty of end-to-end, you see, as long as the routers present  
>>>> "just an IP hop", then applications on end systems are happy.
>>>
> Well thanks, let me just make sure: does http use link-local  
> addresses?  Some times?  IPv6 LL? IPv4 LL?
>
>> I am not sure I understand the game, shall it just be any odd  
>> protocol that works fine across a MANET? Then, it'll be a long  
>> list ;)
>
> Protocols working fine across MANET and using link-local addresses?   
> Er? So why do you discourage the LLs then?

Stuff that uses "link-local addresses" usually work across a *link*  
not across a *network*, correct?

> protocols using IPv6 link-local addresses which risk be affected if  
> the recommendation is to discourage LLs.

But it just doesn't make sense what you write.

Most of what you list runs on end-systems, not between routers.

If your "router cloud" is a MANET or an IS-IS or an OSPF system  
doesn't make an iota of difference. The end-systems (hosts) have no  
idea of what's happening inside that cloud, how the links between  
routers look etc. All they care about is the link between themselves  
and the router -- which.....is just a good-ol' IP-link. All the end- 
systems see is an IP-link to the router. Just as in OSPF. Just as in  
IS-IS.....just as in.....the rest of the Internet.

Are you sure you did see my example-email from this morning?

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 17:30:16 +0100

Updated: limit to protocols relevant to MANET which use IPv6 link-local 
addresses.

Protocols applicable to MANET which use IPv6 LLs
------------------------------------------------
OSPF-MANET
NDP RA
MLD

-------------------------------------------------
IPv4 optional protocols using LLs
---------------------------------
mDNS
ARP (the parts in IPv4 LL RFC)

IPv6 optional protocols using LLs
---------------------------------
DHCP
OSPF
RIPng
MLD
OLSR (a particular implementation)
ND
PPP IPv6
ICMPv6
SLAAC
FMIPv6
MIPv6/NEMOv6/PMIPv6

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 17:33:54 +0100

Thomas Heide Clausen a écrit :
>>> protocol that works fine across a MANET? Then, it'll be a long list ;)
>>
> Stuff that uses "link-local addresses" usually work across a *link* not 
> across a *network*, correct?

Right.  There are ways of expressing this (stay on link, don't move 
out); they shouldn't simply be "discouraged".

> But it just doesn't make sense what you write.

Thomas.

You have now three people: you, myself and Teco who contributed to the 
list.  That sounds as a good candidate for inclusion.

Or are you going to ignore this too?

> Most of what you list runs on end-systems, not between routers.

Well, talk to PMIP/OSPF/MIP/NEMO people and you'll be convinced differently.

> If your "router cloud" is a MANET or an IS-IS or an OSPF system doesn't 
> make an iota of difference. The end-systems (hosts) have no idea of 
> what's happening inside that cloud, how the links between routers look 
> etc.

LLs are not for end-systems only (hosts) they are for routers too.

> All they care about is the link between themselves and the router 
> -- which.....is just a good-ol' IP-link. All the end-systems see is an 
> IP-link to the router. Just as in OSPF. Just as in IS-IS.....just as 
> in.....the rest of the Internet.
> 

Did you reply to Ronald in 't Velt about OLSR using link-local addresses?

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 26 Oct 2009 17:36:04 +0100

On Oct 26, 2009, at 5:23 PM, Alexandru Petrescu wrote:

> Two routers --R1--R2-- don't present an IP hop, there are three  
> subnets and two IP hops.
>

No, Alex, that's neither how it is. Nor is it how I see matters.

h1----R1--- ........ --Rn----h2

Presents the host (h1) with one IP hop towards the router (R1).  
Whatever happens between R1 and Rn is purely transparent to h1. It can  
be avian carries, for all that h1 cares.

The link between h1 and R1 is whatever we usually have on the edge.  
You can run NDP, mdns, ... over it, you can define subnets on that  
link -- the link h1--R1. It's just a classic IP link. All works well

Between R1 and Rn there may be a lot of "magic" going on. Strange  
links, complicated routing protocols. It's a "routing domain" --  
almost like magic ;)

h1 won't know. h1 shouldn't know -- because the interface of h1 to the  
rest of the world is....an IP hop to R1. h1 will use R1 to connect "to  
the rest of the world".

R1 should (on the interface towards the other routers) be aware of  
that "magic", including those advanced algorithms working on  
complicated data structures to find paths towards (in this case) h2.  
That's alright, R1 is build for that purpose - to do exactly that  
magic ;)

In the Internet, R1 and all the other R's would run OSPF or ISIS,  
usually. In a MANET, it'd run a MANET protocol such as AODV, DYMO,  
OLSR, ....

If you disagree with that then -- I'm sorry to say -- you disagree  
with the Internet.

I'm not sure how much clearer I can make it, so I'll jump out of this  
discussion now.

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 17:36:59 +0100

Teco, AUTOCONFers,

Do you agree with adding a list of IP protocols using link-local 
addresses, in the AUTOCONF addressing model, and which may be pertinent 
to MANET?

-yes
-no

Thanks,

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 17:41:17 +0100

> Presents the host (h1) with one IP hop towards the router (R1).

On which side of R1 do you discourage LLs?

> Whatever 
> happens between R1 and Rn is purely transparent to h1. It can be avian 
> carries, for all that h1 cares.
> 
> The link between h1 and R1 is whatever we usually have on the edge. You 
> can run NDP, mdns, ... over it, you can define subnets on that link -- 
> the link h1--R1. It's just a classic IP link.

Ok!  Say so in the addressing model draft.

> All works well
> 
> Between R1 and Rn there may be a lot of "magic" going on. Strange links, 
> complicated routing protocols.

DO you discourage LLs on this "magic"?  Say so in the draft.

> It's a "routing domain" -- almost like 
> magic ;)
> 
> R1 should (on the interface towards the other routers) be aware of that 
> "magic", including those advanced algorithms working on complicated data 
> structures to find paths towards (in this case) h2. That's alright, R1 
> is build for that purpose - to do exactly that magic ;)
> 
> usually. In a MANET, it'd run a MANET protocol such as AODV, DYMO, OLSR, 

But some OLSR does use LLs - do you discourage that?

> ....
> 
> If you disagree with that then -- I'm sorry to say -- you disagree with 
> the Internet.

No, I agree with Internet.

> I'm not sure how much clearer I can make it, so I'll jump out of this 

But we were on the point to converge!

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 26 Oct 2009 17:44:27 +0100

On Oct 26, 2009, at 5:41 PM, Alexandru Petrescu wrote:

>>>>> I don't understand you.  Please add a protocol to my list; that  
>>>>> is the goal of the list.
>>>>>
>>>>> Presenting "just an IP" hop is like routers acting at L2.  Is  
>>>>> this some sort of a layer violation?
>>>>>
>>> where R1 and R2 IP forward with host-based routes.  I know.  I  
>>> just don't see it that way.
>>>

I'll let you take a wild guess.....no, actually, I won't. The links  
between R's...

>> Whatever happens between R1 and Rn is purely transparent to h1. It  
>> can be avian carries, for all that h1 cares.
>> link -- the link h1--R1. It's just a classic IP link.
>

No, this document is not about defining the properties of a classic IP  
link. That's done before (and better than this WG could) elsewhere by  
other people.

>> links, complicated routing protocols.
>

That's what the draft says already, and which you have been disputing  
for days now......

EOD.

Thomas

>
>> It's a "routing domain" -- almost like magic ;)
>> h1 won't know. h1 shouldn't know -- because the interface of h1 to  
>> the rest of the world is....an IP hop to R1. h1 will use R1 to  
>> connect "to the rest of the world".
>> complicated data structures to find paths towards (in this case)  
>> h2. That's alright, R1 is build for that purpose - to do exactly  
>> that magic ;)
>> OLSR,
>> I'm not sure how much clearer I can make it, so I'll jump out of  
>> this discussion now.
>
>>>>>>>> In several earlier discussions question was raised about  
>>>>>>>> which protocols use link-local addresses.
>>>>>>>> IPv4
>>>>>>>> ----
>>>>>>>> mDNS

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 17:46:56 +0100

Thomas, it is not clear your first occurence of "discourage LL".

If I insist, it is for that reason.  Were you to put it last, maybe it 
would have been ok.

You seem ready to spend hours of discussion but don't touch that 
document.  Why?

Why does that OLSR implementation use LLs?

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 26 Oct 2009 17:49:12 +0100

On Oct 26, 2009, at 5:46 PM, Alexandru Petrescu wrote:

> If I insist, it is for that reason.  Were you to put it last, maybe  
> it would have been ok.
>

The above makes no sense?

> You seem ready to spend hours of discussion but don't touch that  

I'm not an author.

But, I agree with the document content.

> Why does that OLSR implementation use LLs?

Not my code, I do not know which implementation you're talking about  
-- I don't know.

But this time, EOD for real from my side.

Thomas

>>>>>>>> That's great and these all run fine across a MANET. That's  
>>>>>>>> the beauty of end-to-end, you see, as long as the routers  
>>>>>>>> present "just an IP hop", then applications on end systems  
>>>>>>>> are happy.
>>>>>>>
>>>>>>> I don't understand you.  Please add a protocol to my list;  
>>>>>>> that is the goal of the list.
>>>>>>>
>>>> Whatever happens between R1 and Rn is purely transparent to h1.  
>>>> It can be avian carries, for all that h1 cares.
>>>> The link between h1 and R1 is whatever we usually have on the  
>>>> edge. You can run NDP, mdns, ... over it, you can define subnets  
>>>> on that link -- the link h1--R1. It's just a classic IP link.
>>>
>> No, this document is not about defining the properties of a classic  
>> IP link. That's done before (and better than this WG could)  
>> elsewhere by other people.
>>>
>>>> All works well
>> That's what the draft says already, and which you have been  
>> disputing for days now......
>> EOD.
>> Thomas
>>>
>>>> h1 won't know. h1 shouldn't know -- because the interface of h1  
>>>> to the rest of the world is....an IP hop to R1. h1 will use R1 to  
>>>> R1 should (on the interface towards the other routers) be aware  
>>>> of that "magic", including those advanced algorithms working on  
>>>> If you disagree with that then -- I'm sorry to say -- you  
>>>> disagree with the Internet.
>>>

---

From: sratliff <[email-masked]>
Date: Mon, 26 Oct 2009 12:50:00 -0400

No.

I think this discussion has become circular in nature, and is not
productive. 

Regards,
Stan

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 26 Oct 2009 17:55:38 +0100

> I think this discussion has become circular in nature, and is not

+1
Emmanuel

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 17:57:23 +0100

Thomas, the OLSR implementation I talked about was reported in an email 
today.

Strange you don't want to talk about OLSR and LLs.

Alex

Thomas Heide Clausen a écrit :
> Not my code, I do not know which implementation you're talking about -- 
> I don't know.
> 
>>> IP link. That's done before (and better than this WG could) elsewhere 
>>> by other people.
>>>>
>>>>> All works well

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 17:57:36 +0100

Well yes, discussion may sound circular in nature.

You could ignore it.

You may also wonder why am I posting tones of messages when I'm 
otherwise very silent on many lists where I look, including this one.

Alex

Emmanuel Baccelli a écrit :
> 
> 
> On Mon, Oct 26, 2009 at 5:50 PM, sratliff <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     No.
> 
>     On 10/26/09 12:36 PM, "Alexandru Petrescu"
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
> 
>      > Teco, AUTOCONFers,
>      >
>      >>> Van: [email-masked]
>     <mailto:[email-masked]> [mailto:[email-masked]
>     <mailto:[email-masked]>] Namens
>      >>> Alexandru Petrescu
>      >>> Aan: [email-masked] <mailto:[email-masked]>
>     useful to
>      >>> [email-masked] <mailto:[email-masked]>
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 26 Oct 2009 17:59:42 +0100

Yes, I think it is quite useful.

Carlos

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 26 Oct 2009 10:09:57 -0700

Hello Teco,

Your list is much more sensible and to the point.

I have some comments.

> This is a non-empty list. For IPv6:

Ouch.  I've been trying to avoid the necessity to go
study that document.  Does OSPF-MANET really
require verification that link-local addresses are
unique across the entire MANET?

>   NDP RA

I really doubt we could have any sizable MANET
networks if every node is beaconing RAs and running
NUD.  This would be a good topic for a research
paper, but my guess is that anything over a couple
of dozen nodes at low speed would just not work.

>   MLD

But, see  below...

> or 1-hop message disctribution (I could use hop-limit=1).

I am firmly in the "hop-limit == 1", or, even better,
"hop-limit received as 255" camp.

It really works.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 26 Oct 2009 10:16:04 -0700

Hello Alex,

> out); they shouldn't simply be "discouraged".

This seems to make your point of view much clearer.
You'd like to have a network of wireless nodes that
don't move in relation to their link.

I really don't see why we should hold up the rest of the
work that needs to be done in order to conform to that
model.

> Or are you going to ignore this too?

Sounds pretty aggressive.  With as much attention
that has been paid to that list (which missed the point)
I don't understand why you claim it was ignored.

>> routers look etc.

The fact is that routing protocols need to be modified in order
to work well with ad hoc networks.  And as we have discovered
so do the address autoconfiguration protocols.

Or else we can be satisfied with tiny, very slow networks.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 26 Oct 2009 10:18:30 -0700

Hello Alex,

If MIPv6 is on that list, then the
list is really entirely irrelevant, and
yet another ring attraction in the
circus of pointless distractions.

Regards,
Charlie P.

Alexandru Petrescu wrote:
> addresses, in the AUTOCONF addressing model, and which may be 
> pertinent to MANET?
>
> -yes
> -no
>
> Thanks,
>
> Alex
>
> Teco Boot a écrit :

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 18:20:44 +0100

> circus of pointless distractions.

Sorry for distracting you, Charles, but... anyways...

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 26 Oct 2009 18:51:14 +0100

Hi Charlie,

>Your list is much more sensible and to the point.
Thanks.

>unique across the entire MANET?

There are three of them.
The base spec says OSPF messages are send with LL source address,
unless <skipped, see [RFC 5340] for details>.
OSPF-MANET RFCs / draft do not say otherwise.
I could think of an implementation that use ULA or global,
but this would be against IETF standards.

The LL addresses doesn't need to be unique in the OSPF routing domain.
It is link-local. For OSPF-MANET, this means xxx-local (replace xxx
with segment, channel, medium, etc., I have posted many proposals for
term and definition).
Two OSPF interfaces on the same xxx MAY have connectivity, two interfaces
on different xxx does by definition NOT have connectivity, because they are
on distinct xxx.

>of dozen nodes at low speed would just not work.

Beaconing RAs is no problem. It is similar to beaconing hellos.
I agree on NUD. A hello protocol would perform better. And running
both for the same purpose is all overhead.

We could encapsulate RA payload in NHDP, but I'm not sure if we want
to go into that direction. Or we could take over all RA capabilities
in the MANET protocol. Not sure on going that way either.

>"hop-limit received as 255" camp.

????
The link-local protects against forwarding.
Checking "hop-limit received as 255" is for protection against spoofers 
multiple hops away.
We need both.

OK, we could use global/ULA source and LL destination with hop-limit sent
and received as 255. This is not how the "long Alex LL list" works today.

Regards, Teco

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 19:02:18 +0100

Charles - the point of mentioning this list of protocols is not how they
don't work for MANET - it is how MANETs make sure they don't disturb
somebody running these protocols and connecting to them.

Don't you think we should do something about this Charter text:
> It is required that such [addressing] models do not cause problems
> for ad hoc-unaware parts of the system, such as standard applications
> running on an ad hoc node or regular Internet nodes attached to the
> ad hoc nodes.

Don't you think we should describe what these "problems" the Charter 
talks about might be?

Don't you think we should mention how the addressing model does not 
create these problems?

Otherwise - why do we have a Charter?  Do we have a Charter only to have 
a Chairman explaining his understanding of it?

Do we have a Charter only to have a few members of the variable-geometry 
Design Team understand it they want to?

Why do you need a WG at all?

Alex

Charles E. Perkins a écrit :
>> This is a non-empty list. For IPv6: OSPF-MANET
>> 
> 
> Ouch.  I've been trying to avoid the necessity to go study that
> document.  Does OSPF-MANET really require verification that
> link-local addresses are unique across the entire MANET?
> 
>> NDP RA
>> 
> 
> I really doubt we could have any sizable MANET networks if every node
> is beaconing RAs and running NUD.  This would be a good topic for a
> research paper, but my guess is that anything over a couple of dozen
> nodes at low speed would just not work.
> 
> 
>> MLD
>> 
> 
> But, see  below...
> 
>> And I have my own middleware products that use LL for Peer
>> discovery or 1-hop message disctribution (I could use hop-limit=1).
>> 
>> 
> 
> I am firmly in the "hop-limit == 1", or, even better, "hop-limit
> received as 255" camp.
> 
> It really works.
> 
> Regards, Charlie P.
> 
> _______________________________________________ Autoconf mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/autoconf
>

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 26 Oct 2009 19:05:16 +0100

I say no.

It will do if we recognize LLs are fact of life. So I think
there is no need to list LL-usage in a draft or RFC.
Moreover, the focus of Autoconf is not LL, but ULA and Global.

Also, there is no need to "discourage" LLs, as written in the 
baccelli draft. I suggested text for a clean-up, but unluckily
this did not make it. With this terrible overheated discussion
as result.

I prefer transfer the discussion on LLs to 6MAN, as I think in
the common case, usage of LLs for general applications is not
preferred over ULA / globals also. I can describe a scenario
where a node has multiple paths to another node, and links are
not that stable, connectivity between these nodes is better using
"routable addresses".
Still, I think LLs should be used for those protocols that require
a scope of a single hop. MANET protocols are an example. At cost
of a ULA / global in the payload (e.g. RouterID).

Regards, Teco.

>Van: Alexandru Petrescu [mailto:[email-masked]]
>Verzonden: maandag 26 oktober 2009 17:37
>Aan: Teco Boot
>CC: 'Alexandru Petrescu'; [email-masked]
>Onderwerp: Re: Adding list of LL protocols for-against (was: [Autoconf]
>Protocols involving link-local addresses)
>
>Teco, AUTOCONFers,
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 19:13:28 +0100

> I say no.

Ok - it dies out.

[...]

> this did not make it. With this terrible overheated discussion

Teco - if you propose new text for a clean-up towards avoiding that 
"discourage LL"s, I agree with it from the start.

As I agree with most of the draft-bernardos with respect to LL.

That says - please take it into account.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 26 Oct 2009 19:13:05 +0100

>Charles E. Perkins wrote:

In my case, I can generate LLs and ULAs using existing specs.
And I can generate globals, if a prefix is provided.
The problem: RAs are single hop and the prefix is not advertised
all over the place in the MANET. And there can be multi-homing,
making things worse.

By the way, can you tell more on your devices, which cannot 
generate a good PRN? How is L2 addressing implemented? What 
happens when there are L2 duplicates?
Maybe I should stay far away from these, but for the discussion it
might help to understand your problem.

Yes, we need MANET protocols.

Regards, Teco

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 26 Oct 2009 11:31:21 -0700

Hello Alex,

> somebody running these protocols and connecting to them.

I don't think so.  I think that some things are going to
have to be broken in order to run reasonable-sized ad hoc
networks.  Mobile IPv6 is a good example.  It's just _not_
going to work automatically.  Even more to the point, it
was designed and built to run in networks that do NOT
conform to the operational model of an ad hoc network.

Jumping up and down and insisting that it does work is
tantamount to declaring that you have no interest in ad hoc
networks.

>> running on an ad hoc node or regular Internet nodes attached to the

This is fine with me.  We can have an ad hoc network that doesn't
mess up the Internet.  It can get addresses.  Those addresses do
not mess up the Internet.  The network can be attached to a gateway
providing connectivity to the Internet.  You can even have a subnet
attached to an ad hoc node, and have the ad hoc node managing
as a default router for the other nodes on that subnet.  Those subnet-
attached nodes may not even notice that they are being served as
nodes within an ad hoc network.

That's drastically and totally different than saying you should be
able to take absolutely any Internet node today, stick it anywhere
withiin an ad hoc network, and expect it to work.

If you disagree with this, then we really have to go back to
first grade and have some more basic discussions.

> Don't you think we should describe what these "problems" the Charter 

It seems to me that the problems and solutions I have pointed out
many many times are not of interest to you, as you insist on being able
to maintain unique link-local addresses in environments where such
uniqueness is quite difficult to guarantee.  In effect, you exclude useful
environments for networking, and only wish to serve environments
which look to IP exactly like an Ethernet.

So why do you bother with [autoconf]?  Your problem is solved
elsewhere.

> Don't you think we should mention how the addressing model does not 

Problems, problems.  Right now our problem is managing
a discussion about the realm of applicability for unique
link-local addresses.  It seems to be based almost purely
on dogmatism instead of engineering tradeoffs.

>
> Otherwise - why do we have a Charter?  Do we have a Charter only to 
> have a Chairman explaining his understanding of it?
I'm not a chair of anything.  Do I count as a potential
person that might have understanding?

>
>
> Do we have a Charter only to have a few members of the 
> variable-geometry Design Team understand it they want to?

If you insist on fixed geometry networks, I really think you are
in the wrong working group.

> Why do you need a WG at all?

To solve problems of variable geometry networks.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 26 Oct 2009 11:41:29 -0700

Hello Teco,

> In my case, I can generate LLs and ULAs using existing specs.

Is this the case of BDRP?  But the world is still hungry :-).

Don't you think we should have a design team to develop
recommendations in the case of IEEE-style MAC addresses,
for which uniqueness can be assumed?

Then we could have a general solution for non-unique
link-locals, which should be compatible with the specific
solution.  The general solution could even admit the
specific solution as a special case.  As it should be.

> all over the place in the MANET. And there can be multi-homing,

Exactly.  These are the problems we should have been
discussing years ago.  Some of the problems are not hard,
some (e.g., multi-homing) are much harder.

> happens when there are L2 duplicates?

I am not currently a practitioner of this excellent school
of engineering, but I have experience with devices that
have terribly small power budgets and unusual layer-2
addressing schemes.

> might help to understand your problem.

But this discussion has gone on many times.  I think I remember
some messages from John Mullen on the matter a while back.
And then there is the historical matter of the development
process for IPv6.  There were strong proponents that we should
rely on layer-2 uniqueness, but the consensus was quite broad
that we needed to allow IPv6 to serve environments where that
assumption is not true.  And yet there is the universal agreement
that in some restricted environments of the obvious sort, we can
get better performance with Optimistic DAD and so on.

Except that it seems all this wealth of experience gets left at
the door when entering into the discussions on [autoconf].

> Yes, we need MANET protocols.

I see that we have many points of agreement :-)

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 20:04:49 +0100

Ha! :-)

> have to be broken in order to run reasonable-sized ad hoc

And then let's mention those things which risk being broken.  Which 
protocol, which implementaiton risks being broken.  Go ahead.  I have my 
ideas about what might break if LLs are discouraged.

> Mobile IPv6 is a good example.  It's just _not_ going to work
> automatically.  Even more to the point, it was designed and built to
> run in networks that do NOT conform to the operational model of an ad
> hoc network.

Yes, right.

MN is, however, a node which may want to connect to an adhoc network 
which may represent its "home" network, and thus use its LL address. 
And to that home network there may be a HA which should use ND to defend 
the HoA of the MN, which may be LL.

If that adhoc network "discourages LLs" - how will it work?

> tantamount to declaring that you have no interest in ad hoc

Well, I have interest in networks that may behave as you say, but which 
I don't want to call neither MANET nor "adhoc networks".  BEcause once I 
call them so everybody forcefully feeds me a good dose of OLSR and DYMO.

And that whatever I call "adhoc" - once I talk about it it's no longer 
adhoc, it's planned.

> not mess up the Internet.

There are few addresses which don't mess up the Internet: link-locals, 
globals, multicast, etc.  You discourage the LLs, the globals are not 
mentioned, neither the multicast.

> The network can be attached to a gateway
> providing connectivity to the Internet.

No such gateway mentioned in the draft.

Charles - all that the draft is saying is this:
-dont LL
-do /128 prefixes
-do unique addresses

That's all!

No mentioning of gateway, or how other non-MANET nodes work ok with 
MANET nodes.

> You can even have a subnet

Picture it and paste it in the draft, instead of "dont LL" and "/128 
prefixes".

> withiin an ad hoc network, and expect it to work.

Well, if your intention is to not allow any Internet node to connect to 
the MANET then what is the Gateway?

> first grade and have some more basic discussions.

More discussions?  I will not refuse the invitation though.

> uniqueness is quite difficult to guarantee.

Ok.

I don't maintain that keeping LLs unique is easy.

Let's just don't discourage them.

I guess you want to invent a new way of keeping them unique, but not to 
discourage them.

> In effect, you exclude useful environments for networking, and only
> wish to serve environments which look to IP exactly like an Ethernet.

It would be easier - yes.

Adhoc MANETs is not the first time people encountered 
Ethernet-unfriendly places.  Often the use is PPP/SLIP in such places. 
Often it suffices.  PPP uses link-local addresses too.

Remark too that recently more and more links try to offer an 
Ethernet-friendly IP, that is at least WLAN, WPAN and WMAN.  WPAN 
802.15.4, for example pertains to both "MANET" and to "Ethernet".  WLAN 
802.11s "mesh" also pertains to both EThernet _and_ to MANET.

I don't understand why you say I exclude useful environments...

> So why do you bother with [autoconf]?  Your problem is solved

Well, let's say that I have a green light from the Chairs saying my 
opinion is welcome.

Chairs have means to make me shut up, if they so decided.

> on dogmatism instead of engineering tradeoffs.

Avoid dogmatism - I want too.

LEt's go practical and mention protocol names and practical problems and 
follow Charter.

> person that might have understanding?

Charles - you too don't see any problem in the Charter saying the 
non-MANET nodes should not be affected by the MANET nodes.

I think - on a personal speculating note - that you believe Charter is 
so-and-so-relatively-so as long as it does not forbid you anything.

To me, there is a huge difference between what Charter says and what DT 
does.

> in the wrong working group.

Well, sorry, variable-geometry might be a bad translation.

I meant to say that the Design Team had a variable geometry (like the 
F14 plane) in that it changed members at one time, and that one of the 
members does not currently seem to be heard.

> To solve problems of variable geometry networks.

Ok variable geometry networks, not variable geometry DTs.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 26 Oct 2009 20:22:20 +0100

Hi Charlie,

>Van: Charles E. Perkins [mailto:[email-masked]]
>Verzonden: maandag 26 oktober 2009 19:41
>Aan: Teco Boot
>CC: [email-masked]
>Onderwerp: Re: [Autoconf] Protocols involving link-local addresses
>
>
>Hello Teco,
>
>Teco Boot wrote:

World hungry is getting worse. Not sure on Autoconf... .
 
However, BRDP could help. For me, it is the holy grail. But still
in the embryo stage. Didn't MANET protocols stay that way over 10 years?
I mean: BRDP works great in simulation !!

>specific solution as a special case.  As it should be.

I've to think on this. 
Just some thoughts:
 - If it were IEEE-style MAC addresses, why not using IEEE MAC addresses?
They don't have to be globally unique (universally/locally administered 
Address set to 1). Good to know IEEE ULA means Universal LAN Address.
So IEEE is always just the opposite (like the U/L bit).
 - Deviations from IEEE could have to do with overhead. I know of
L2 addresses that are only a few bits long. Still, these radios are
capable of transmitting IP packets. Payload is compressed by
application, L2-header is highly optimized. IP header compression is
on the todo list (or "beta", or just out there). If we come up
with something, it must interact with L2&L3 header compression.
 - The multiple hop uniqueness test need more thoughts. I'll write
this on a piece of paper and put it under my pillow tonight. 

>some (e.g., multi-homing) are much harder.

Multi-homing is (partly) solved by BRDP based routing.
Just kill the default gateway and send packets to the BR that
"owns" the SA prefix.
What is left is address handover for apps. MIP/NEMO can do this,
HIP, SHIM6 and multipath TCP, just to name a few.
And of course SA selection. BRDP provides great metrics for it.

>have terribly small power budgets and unusual layer-2

OK, you are in the IEEE camp right now! Great!!
Or have devices by hand, that can come up with real good PRNs.

I had the opinion you worked for a museum. Sorry for that, I was wrong.

>the door when entering into the discussions on [autoconf].

I think no one wants to take DAD out of the specs. I have my doubts,
for security reasons. On wired networks we can handle overhead and accept
small delays. In a MANET, this is different and we are allowed to disable
DAD. I remember the posting from Thomas Narten on this (September 2nd).

Do we agree on a goal, having MANET unique InterfaceIDs and go from there?
And forming a DT on a protocol for some assurance on uniqueness, for those
who need it? I'm not candidate. But I support such an approach if it would
rescue Autoconf.

Regards, Teco

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 26 Oct 2009 20:34:14 +0100

On Oct 26, 2009, at 8:04 PM, Alexandru Petrescu wrote:

> protocol, which implementaiton risks being broken.  Go ahead.  I  
> have my ideas about what might break if LLs are discouraged.
>
> And to that home network there may be a HA which should use ND to  
> defend the HoA of the MN, which may be LL.
>

It's getting tiresome to repeat it: because your "mobile node" (I  
assume NEMO) will NOT connect to the "ad hoc side" of the network.

Am I not saying it right?

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 20:35:53 +0100

Thomas Heide Clausen a écrit :
>> protocol, which implementaiton risks being broken.  Go ahead.  I have 
>> my ideas about what might break if LLs are discouraged.
>>
> It's getting tiresome to repeat it: because your "mobile node" (I assume 
> NEMO) will NOT connect to the "ad hoc side" of the network.

And what if it does - what will break?

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 26 Oct 2009 12:53:56 -0700

Hello Alex,

> Ha! :-)

I am starting off being confused already.

> my ideas about what might break if LLs are discouraged.

Let's say that link-locals are broken, and it will take
effort to re-establish them for useful purposes.  Then
your list of protocols would serve notice for people to
take a look and determine whether or not each item
on that list might require modification.

> If that adhoc network "discourages LLs" - how will it work?

Mobile IP _can_ be made to work.  It was, fortunately,
designed to allow a home agent on a virtual network.  That
model applies immediately.  You can also have a physical
network employing techniques much like fixed hosts in NEMO.
Too bad that in a MANET the home agent may frequently
be unreachable due to network partition, but that isn't too
much different than hiccups in Internet connectivity.

Several Internet Drafts were published years ago with details.
I could probably dig them up, but honestly I feel it would be to
almost no benefit to you.

> Well, I have interest in networks that may behave as you say, but 
> which I don't want to call neither MANET nor "adhoc networks".  
> BEcause once I call them so everybody forcefully feeds me a good dose 
> of OLSR and DYMO.
>

That is probably appropriate, as long as you describe networks
with core forwarding nodes within a single hop of all other nodes,
or single links.  I might be wrong on this point.  Can you suggest
a model for ad hoc networks that is sufficiently general for all of
your purposes?  What if your model is then considered far too
restrictive for the purposes of other people?  Should we conform
to your model, or enable development of protocols for the more
general models desired by other people?

> mentioned, neither the multicast.

Here I entirely miss your point.

What if the draft "mentions" globals?

And it is not at all unusual for initial work
on address autoconfiguration to delay the
consideration of multicast.  In my opinion,
it is highly appropriate for [autoconf] to
delay multicast address allocation.

> No such gateway mentioned in the draft.

Why should the draft mention the gateway?

> Charles - all that the draft is saying is this:
I strongly encourage you to be accurate on
this point.  Namely, as I remember it anyway,
the draft specifies that we not mandate the use
of link-local addresses.

"not mandate" != "prohibit".

As has been said many many times.

> -do /128 prefixes
... unless one knows how to use shorter prefixes ...

> -do unique addresses

Any protocol with flooding operations will find
great benefit and simplification if it has the ability
to rely on unique addresses.

It turns out to be not absolutely required, but
the additional design considerations are really
quite nontrivial.  That would be like learning to
run before learning to crawl or walk.

> No mentioning of gateway, or how other non-MANET nodes work ok with 

Since we have currently zero solutions on the standards track,
I fail to see how we can specify how the solution will work with
a non-MANET node.

At least we can say that all of our current solutions so far
are completely compatible with non-MANET nodes.

Is that a good start?

> Picture it and paste it in the draft, instead of "dont LL" and "/128 

(a) your characterization is wrong and
(b) it would require illustration of a particular solution.

> Well, if your intention is to not allow any Internet node to connect 
> to the MANET then what is the Gateway?

Alex, please re-read your question and
try to realize that it is solely argumentative
without any possibility of increasing understanding.

Wrong characterization of my intention, pretense that
you don't know what a gateway might be, etc. etc.

> Let's just don't discourage them.
Do you mean, let's not describe their problems?

Why would such pretense be beneficial to anyone?

>
> I guess you want to invent a new way of keeping them unique, but not 
> to discourage them.

No.  I want _you_ to invent a new way of keeping them unique
before you ask others to mandate their use.

> Often it suffices.  PPP uses link-local addresses too.

Your example proves my point.  Mobile PPP?

> 802.15.4, for example pertains to both "MANET" and to "Ethernet".  
> WLAN 802.11s "mesh" also pertains to both EThernet _and_ to MANET.

Did we have any discussion yet about whether or not all [autoconf]
nodes were blessed with unique MAC addresses?

Hmm....  I'm trying to remember?  Can you help?

> I don't understand why you say I exclude useful environments...

Because you do.

> Chairs have means to make me shut up, if they so decided.

My acquaintance of the chairs of this group is that they encourage
thoughtful participation.  And, they welcome constructive advice.

> Avoid dogmatism - I want too.

Try on for size to disengage from requiring link-locals.

> so-and-so-relatively-so as long as it does not forbid you anything.

I might flatly say this is wrong, but I don't know what it means.

>
> To me, there is a huge difference between what Charter says and what 
> DT does.

If there is ambiguity in the Charter, maybe it should be clarified.

> members does not currently seem to be heard.

If you are referring to Teco, then I can assure you that I heard
him, and I honestly think his opinions were not only heard but
frequently solicited.  For my own part I read practically all of his
messages and his BDRP draft, made comments, and participated
with him.

Everyone can get a little bit frustrated that things don't go their
way, and nevertheless try to achieve the best possible outcome.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 21:16:51 +0100

HEllo Charles,

I want to answer not leave unanswered quyestions.

> Let's say that link-locals are broken, and it will take effort to
> re-establish them for useful purposes.  Then your list of protocols
> would serve notice for people to take a look and determine whether or
> not each item on that list might require modification.

Makes sense.

[...]
>> And that whatever I call "adhoc" - once I talk about it it's no
>> longer adhoc, it's planned.
> 
> That is probably appropriate, as long as you describe networks with
> core forwarding nodes within a single hop of all other nodes, or
> single links.  I might be wrong on this point.

No, you are right.  I can not describe something which I can't describe.

> Can you suggest a model for ad hoc networks that is sufficiently
> general for all of your purposes?

No - I can't.  I can only describe networks for specific purposes.  YEs, 
you will disagree.

>  What if your model is then
> considered far too restrictive for the purposes of other people?
> Should we conform to your model, or enable development of protocols
> for the more general models desired by other people?

Right.  But let's see these models.  Until now we only leave the door 
open.  Spend time, keep the door open.

>>>>> It is required that such [addressing] models do not cause
>>>>> problems for ad hoc-unaware parts of the system, such as
>>>>> standard applications running on an ad hoc node or regular
>>>>> Internet nodes attached to the ad hoc nodes.
>>> 
>> There are few addresses which don't mess up the Internet:
>> link-locals, globals, multicast, etc.  You discourage the LLs, the
>> globals are not mentioned, neither the multicast.
> 

It would be easier to read for someone used to RFCs: "global addresses" 
as in rfc4291, or anycast addresses as in RFCXXXX.  Easier to see the 
implementation aspects too.

> And it is not at all unusual for initial work on address
> autoconfiguration to delay the consideration of multicast.  In my
> opinion, it is highly appropriate for [autoconf] to delay multicast
> address allocation.

I agree.  But how about the use?

Since the draft tends to discourage LLs, is it going to tend to 
discourage the solicited-node multicast addresses as well (Ulrich talked 
about those today).  For LLs they're self-formed, no need to allocate 
them.  They're there.  If you plan on discouraging those too...

Does the draft have an opinion on these self-formed solicited-node 
multicast addresses?  Are they discouraged?  Allowed?  Not mandated? 
SIlence about them?

But they are there on all nodes running IPv6.

> Why should the draft mention the gateway?

To have a topology drawned, to descirbe some model.  It has no picture now.

>> Charles - all that the draft is saying is this: -dont LL
> I strongly encourage you to be accurate on this point.  Namely, as I
> remember it anyway, the draft specifies that we not mandate the use 
> of link-local addresses.

I think it comes from my IPv4 reading of it, which comes before IPv4:
>    Note that the use of IPv4 link-local addresses [RFC3927] in this
>    context should be discouraged for most applications

> "not mandate" != "prohibit".

Think that I think of IP as IPv4/6, excuse me.

I agree with you on "not mandating" LLs.

> Any protocol with flooding operations will find great benefit and
> simplification if it has the ability to rely on unique addresses.

Ok, known.

> It turns out to be not absolutely required, but the additional design
> considerations are really quite nontrivial.  That would be like
> learning to run before learning to crawl or walk.
> 
>> 
>> That's all!
>> 
> Since we have currently zero solutions on the standards track, I fail
> to see how we can specify how the solution will work with a non-MANET
> node.
> 
> At least we can say that all of our current solutions so far are
> completely compatible with non-MANET nodes.
> 
> Is that a good start?

Were we to say upfront we don't discourage neither IPv4 nor IPv6 LLs.

>>> You can even have a subnet attached to an ad hoc node, and have
>>> the ad hoc node managing as a default router for the other nodes
>>> on that subnet.  Those subnet- attached nodes may not even notice
>>> that they are being served as nodes within an ad hoc network.
>> 
>> Picture it and paste it in the draft, instead of "dont LL" and
>> "/128 prefixes".
> 
> (a) your characterization is wrong and (b) it would require
> illustration of a particular solution.

...

> 
> 
>> 
>>> That's drastically and totally different than saying you should
>>> be able to take absolutely any Internet node today, stick it
>>> anywhere withiin an ad hoc network, and expect it to work.
>> 
>> Well, if your intention is to not allow any Internet node to
>> connect to the MANET then what is the Gateway?
> 
> Alex, please re-read your question and try to realize that it is
> solely argumentative without any possibility of increasing
> understanding.
> 
> Wrong characterization of my intention, pretense that you don't know
> what a gateway might be, etc. etc.
> 
> 
>> 
>>> 
>>>  many many times are not of interest to you, as you insist on
>>> being able to maintain unique link-local addresses in
>>> environments where such uniqueness is quite difficult to
>>> guarantee.
>> 
>> Ok.
>> 

If LLs have a DAD problem then globals have it too.  I believe there may 
be a problem solely with uniqueness when things move so fast that 
uniqueness is impossible.

>> I guess you want to invent a new way of keeping them unique, but
>> not to discourage them.
> 
> No.  I want _you_ to invent a new way of keeping them unique before
> you ask others to mandate their use.

Right, I do not mandate them.  I dont want them discouraged.

I do not work towards uniqueness.  Nowadays I hardcode the uniqueness on 
machines and dynamically propagate routes to follow that hardcodedness.

(I am even open to people proposing non-unique addresses).

[...]

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 26 Oct 2009 13:39:21 -0700

Hello Teco,

Teco Boot wrote:
>
>  
>   ...   BRDP could help. For me, it is the holy grail. But still

I think it is safe to say that MANET protocols have moved out of the
lab and into real networks.  However, I think they still have a long way
to go.  They are "widely" deployed, but not at all universally available.
As I remember, BRDP really relies on a particular model of network,
but now I would need to go review the details.

> with something, it must interact with L2&L3 header compression.

But this really isn't the point.  The point is that IP is supposed to 
work over
a great many kinds of media.  Not only those media for which layer-2 address
uniqueness can be assumed.

Before you try to enforce such a restriction, I think you should try to 
update
RFC 791 and RFC 2460 to specify that they are only supposed to work on
networks that obey that restriction.

> this on a piece of paper and put it under my pillow tonight.

Yes, it would be good to identify your position on multi-hop networks.

> And of course SA selection. BRDP provides great metrics for it.

I did not in any way mean to suggest that solutions for multi-homing
were unknown.  Just that it's quite a bit more difficult.

> I had the opinion you worked for a museum. Sorry for that, I was wrong.

Right now I am in the LTE camp.  Somehow your comment about
the museum is hard for me to interpret in any flattering way, sigh.

> DAD. I remember the posting from Thomas Narten on this (September 2nd).

I am not sure about what specs DAD would be taken out of.  And, the 
design of
DAD will depend on what we can do to "substitute" for link-local 
addresses when
the latter are determined to be unsuitable for use in the general case.

> Do we agree on a goal, having MANET unique InterfaceIDs and go from there?

For address autoconfiguration, address uniqueness is part of the 
_process_, not automatically
given as one of the hypotheses.

> who need it? I'm not candidate. But I support such an approach if it would

The design team would submit (1) a document about how to configure addresses
given the existence of a unique MAC address and, if they are brave, (2) 
a protocol
to guarantee link-local address uniqueness when the MAC address assumption
does not hold.  Document (2) might impose other restrictions, weaker 
than the
MAC address assumption, but stronger than the general unrestricted case.

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 26 Oct 2009 23:03:20 +0100

Hi Charlie,

>Verzonden: maandag 26 oktober 2009 21:39
>Aan: Teco Boot
>CC: [email-masked]

I'll set up a test network at home, and maybe at a far more important
environment after next. I'll asked IPv6 connectivity from my provider.
Still waiting for a positive response. For now, BRDP is IPv6 based.
I'll go for native IPv6. A bit principle, but it gives me some time to
implement :-). Or get someone working it out for me. Volunteers?

>uniqueness can be assumed.

Good PRN will do. Based on EMSI / EMEI or MAC address borrowed from
another interface. Or use the radio Rx circuit as pretty good PRN seed.
You were a bit kidding on the huge pre-shared key. And you did not
respond on DHCP DUID. Or missed my question on this one? Did I miss
an answer?

As said, I'm fine with a protocol that helps multi-hop unique InterfaceIDs.
I've no clue how to do it, but it is a nice design goal.

>networks that obey that restriction.

I'll stick to IPv6. 

RFC 2460 needs an update anyway (the, 6 pages on RH :-)
But RFC4862 gives us all that we need. 

We have to decide spending cycles on good PRN (and some cents / 
pennies on HW) or the uniqueness protocol. Do you remember your 
strong opinion on saving each bit sent out, at costs of CPU cycles? 
I think the same is true for generating good PRN instead of try and 
error a duplicate test.

>MAC address assumption, but stronger than the general unrestricted case.

For (1), it is about unique InterfaceIDs, agreed? And implementers may 
use the mechanism for highly unique InterfaceIDs, at own risk.
(BRDP is an example output, could be used as input)

Then, we can indeed take a next step (2), working on multi-hop duplicate
detection, either by purpose (spoofing) or accident (bad PRN) and 
switch-over to an alternative address. This would work together with
private addresses and / or SeND. Great.

Regards, Teco

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 27 Oct 2009 11:15:39 -0000

> I think this discussion has become circular in nature, and is not

Having just come back from a short break which exactly corresponded
with this storm of 200+ messages, so I'm seeing it all at once (and
have got this far, not finished yet) I can absolutely agree with this
statement.

I'm waiting to finish all of the postings before considering if I
have anything useful to say, or if anything useful can be said.

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 27 Oct 2009 07:54:49 -0700

Add LLMNR as a link-local candidate protocol.

---

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

> Add LLMNR as a link-local candidate protocol.

Updated to include LLMNR:

LLMNR

LLMNR

Alex