Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Oct 2009 23:42:30 +0200

AUTOCONFers,

I just noticed this draft just announced:

[email-masked] a écrit :
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bernardos-autoconf-addressing-model-00.txt

This draft says, among others:

>    MANET interfaces MUST also be configured with IPv6 Link-local
>    addresses (as required by RFC 4861 [RFC4861] and RFC 4291 [RFC4291]).
>    Two main concerns may arise when considering the use of IPv6 Link-
>    local addresses:
> 
>    o  Address uniqueness: the event of having two duplicate addresses in
>       the same link has proved to be very low (EUI64 derived interface
>       identifiers very rarely collide, since MAC addresses are expected
>       to be globally unique), and even some mechanisms have been
>       proposed to reduce the collision probability
>       [I-D.soto-mobileip-random-iids].  Therefore, in most scenarios it
>       is safe to assume that the probability of having two or more
>       duplicated link-local addresses in a MANET is negiglible.  For
>       those scenarios, in which this cannot be safely assumed, we refer
>       to the DAD considerations of Section 3.3.
> 
>    o  Reachability: connectivity among neighbours in wireless links may
>       be intermittent and/or short-lived.  Therefore, the use of link-
>       local addresses may lead to reachability issues, since two nodes
>       that were in direct coverage range at one moment, might not be
>       anymore shortly after.  These problems might also arise in wired
>       networks (nodes going up/down), but it is not the common case.
> 
>    Having brought to attention these concerns, it is further left to the
>    designers of MANET routing protocols (and other protocols) to
>    determine whether link-local addresses can be used in an effective
>    way.

I must say I fully agree with the above text, because it says 
link-locals are "MUST".  It is more positive towards link-locals, I 
agree with it.

I agree with it more than I agree with this text in 
draft-ietf-autoconf-adhoc-addr-model-00.txt:
>    Note that while link-local addresses are assumed to be "on link", the
>    utility of link-local addresses is limited as described in Section 6.

... which has a negative co-notation in that use of the "limited" word.

So - please clarify this situation.

Alex

> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 21 Oct 2009 16:08:20 -0700

Hello Carlos and Ronald,

Intrigued by Alex's email to the [autoconf] mailing list, I read
your draft, which suggests the mandate:
    "MANET interfaces MUST also be configured with
     IPv6 Link-local addresses".

But there is no indication in the draft about why that
mandate might result in anything useful.

What if [autoconf] recommended assignment of a distinguished
link-local address to every MANET node?  We could, for
instance, designate the value fe80::FFFF as the distinguished
useless link-local address designed _solely_ for the purpose
of rigorous compliance with RFC 4861.  Would this be
satisfactory for the purposes you espouse in your draft?

I also note that in your draft you advocate reliance on the
typical (but not guaranteed) uniqueness of IEEE MAC addresses,
and also turning off DAD or hacking the parameters.  Did you
try to calculate the overhead of, say, beaconing NA messages
every 50 milliseconds, and the resulting too-frequent ND
operations?  Do you have any comments on the N^2 nature
of this source of congestion?

Regards,
Charlie P.

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

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 22 Oct 2009 02:10:28 +0200

Hi Charlie,

> your draft, which suggests the mandate:

Thanks for reading the draft. We are working on a -01 version (we
submitted -00 to meet the deadline and we hope to make some changes
before announcing it on the ML), but I'll provide my view on your
questions.

> satisfactory for the purposes you espouse in your draft?

No, this would not be satisfactory. Link locals are not only mandated by
RFC 4861 but also used by some protocols, so that's why we consider
important to configure them (so they can be used) in MANETs.

> typical (but not guaranteed) uniqueness of IEEE MAC addresses,

It's true that it is not guaranteed, but the probability of collision is
so low, that I'm not sure it's worth arguing about the necessity of
using DAD.

> of this source of congestion?

This could be certainly a scalability problem, but "hacking/configuring"
ND is just one proposed mechanism to tackle with fluctuating
reachability issues. There are other ways proposed in the draft (such a
stronger interaction with the routing protocol) and surely there are
more.

Even if globals are used instead, we would have a fluctuating
reachability issue, since the next IP hop used to reach a certain
destination might move out of radio coverage (you need to detect this by
ND or the routing protocol). I think the same kind-of solutions that be
used there can also be used when link-locals are used. Besides, we do
not mandate to use link-locals in the draft, we just think there are use
cases where they are useful and therefore we should not prevent their
use in MANETs.

Again, thanks for reading the draft.

Regards,

Carlos

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

---

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 22 Oct 2009 09:37:17 +0200

Hi Alex,

I also read the draft, and I did not see any fundamental difference in with
the draft the working group has been working on for months, i.e.
draft-ietf-autoconf-adhoc-addr-model. This is quite reassuring: apparently
the working group did not totally waste its time until now ;) More comments
below.

On Wed, Oct 21, 2009 at 11:42 PM, Alexandru Petrescu <
[email-masked]> wrote:

> I must say I fully agree with the above text, because it says link-locals
> are "MUST".  It is more positive towards link-locals, I agree with it.
>

draft-ietf-autoconf-adhoc-addr-model-00 says no different, in section 6.2:
"an IPv6 link-local address is assigned to each interface as per [RFC4291]".
Similarly, in the same section, the draft also mentions concerns with the
use of link local addresses.

The difference is that draft-ietf-autoconf-adhoc-addr-model-00 also
concludes on the matter (a model should offer such conclusion in my mind, if
not, it is not a model). The conclusion is, in section 6.2, that it "should
be encouraged to primarily focus on configuring IP addresses that are not
link-local". So in effect, link-locals are not forbidden, but their use is
discouraged. Note that implicitely, the same conclusion is in
draft-bernardos-autoconf-addressing-model-00.txt.

> ... which has a negative co-notation in that use of the "limited" word.

If you think the term "limitations" is too negative compared to the term
"concerns" (used instead in
draft-bernardos-autoconf-addressing-model-00.txt), swapping such words would
be an easy fix. Personally, I do not have any issues with this.

If anybody has practical suggestions as to how to modify
draft-ietf-autoconf-adhoc-addr-model-00, please let it be  known at this
point.

Appart from word-tweaking here and there, it seems that we essentially all
agree on the model. So let's move on to actually designing solutions...

Regards,

Emmanuel

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Oct 2009 15:15:31 +0200

Hi Emmanuel,

I will go straight to our core issues below:

Emmanuel Baccelli a écrit :
[...]
> concludes on the matter (a model should offer such conclusion in my 
> mind, if not, it is not a model). The conclusion is, in section 6.2, 
> that it "should be encouraged to primarily focus on configuring IP 
> addresses that are not link-local".
 > So in effect, link-locals are not
> forbidden, but their use is discouraged.

We keep talking past each other.

I maintain the use of LL addresses should be encouraged in MANETs.

> Note that implicitely, the same 
> conclusion is in draft-bernardos-autoconf-addressing-model-00.txt.

That draft starts with a clear "MUST LL" and then recommend to 
implementer to use when appropriate.

> draft-bernardos-autoconf-addressing-model-00.txt), swapping such words 
> would be an easy fix. Personally, I do not have any issues with this.
> 

Why should I?  Only to get a reply back saying it is not good?

> Appart from word-tweaking here and there, it seems that we essentially 
> all agree on the model. So let's move on to actually designing solutions...

Not this way, sorry...

Alex

---

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

Hello Carlos,

> important to configure them (so they can be used) in MANETs.

Can you say which protocols are of interest in this connection?

> so low, that I'm not sure it's worth arguing about the necessity of

This is, I think, the major point of disagreement.  So, for instance,
most wireless devices in the world do NOT have IEEE 802 MAC
addresses.   I'd like to enable a world where they can use [autoconf]
protocols and [manet] protocols.

> stronger interaction with the routing protocol) and surely there are

Using a routing protocol to insure uniqueness of
link-local addresses seems, on the face of it, to be
a serious layer violation.  However, I like to keep
an open mind :-).

> cases where they are useful and therefore we should not prevent their

There is a huge difference between global and link-local.  It makes
all the difference in the world.  Namely, global addresses are reasonable
to include in payloads for protocol messages that can be forwarded
across multiple hops.  Link-local addresses do NOT share this
property.

They're _local_ addresses!

Please explain the relationship between the following two sentences:

>       IPv6 Link-local addresses"

and
>                                               "Besides, we do
> use in MANETs."

Regards,
Charlie P.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Oct 2009 10:31:34 -0700

Charlie,

> addresses

The reason some of those wireless devices do not have
IEEE 802 MAC addresses is because carrying two 6-octet
addresses on each packet would waste too much precious
RF transmission resources. But, these are the very same
devices that would prefer to use IPv4 instead of IPv6
for MANET-local communications in order to limit the
overhead for carrying IPv6 addresses when the increased
IPv6 addressing space is not needed.

One other point - you seem to be drawing a hard line that
DAD must be perfect. But, the IP link service model is
best-effort (not reliable delivery) so that DAD failures
are possible on any IP link, and not just the ones we
typically talk about wrt MANET.

Fred
[email-masked]

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 22 Oct 2009 10:55:02 -0700

Hello Fred,

> IPv6 addressing space is not needed.

I hope by this statement you do not intend to exclude that class
of devices from participation in the IPv6 Internet.  As far as the
_internetworking_ aspect is concerned, I reckon that the
addressability and routing ought to be IPv6.  As far as the
delivery over a particular link is concerned, I am sure we can
both think of ways to ameliorate the size of the headers.  The
payloads are more problematic!  So, it is extremely important
to eliminate excess signaling.

My point is that requiring link-locals will engender a great
deal of excess signaling.  And, furthermore, we can achieve
our goals of address autoconfiguration without requiring them.

Delivering user-plane data will still benefit greatly from the
various techniques for header compression that might be
further inspired by the use of IPv6 addresses.

> typically talk about wrt MANET.

This is a good point.  IP is not reliable delivery.  But it doesn't
deliver packets to the _wrong_ endpoint.  And, duplicate addresses
are, in the design universe I am familiar with, totally poison.
I think they are far worse than dropped packets.

Regards,
Charlie P.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Oct 2009 11:00:22 -0700

Charlie,
 
> of devices from participation in the IPv6 Internet

Never would I suggest such a thing; indeed, I am
counting on IPv6 Internet participation.

Fred

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 22 Oct 2009 20:53:26 +0200

Hi Charlie,

> Can you say which protocols are of interest in this connection?

Some routing protocols make use of link-locals, right?

> protocols and [manet] protocols.
	Well, for these scenarios we also propose in the draft to use some of
the mechanisms that have been proposed in the past (such as
draft-soto-mobileip-random-iids)to reduce the collision probability.

> a serious layer violation.  However, I like to keep

I guess I didn't explain myself clearly... I never said that routing
protocols should be used to insure uniqueness of link-local addresses
(though they may be use to detect duplication, as it has been proposed
in several passive "DAD" approaches, such as PACMAN). What I was trying
to say is that a stronger interaction with the routing protocol might be
used to detect that a neighbour is no longer reachable, instead of
purely relying on NUD.

> They're _local_ addresses!

Yes, I know what a link-local address is :-D. I think we were talking
about reachability of a 1-hop node, that is, the next IP hop of a
communication (if we are using link-locals, then next IP hop ==
destination).

> > cases where they are useful and therefore we should not prevent their

The relationship is the following: LLs MUST be configured, but we don't
mandate their use. It is a MUST, because there are IPv6 specs that say
so and because there are IPv6 protocols/applications that may want to
use them, but this does not imply that we force protocols/applications
to use them (it's up to the protocol/application designer to decide
whether to use them or not).

Thanks,

Carlos

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 22 Oct 2009 12:08:04 -0700

Hello Carlos,

> Some routing protocols make use of link-locals, right?

[manet] was started as a working group because OSPF and other routing
protocols were measured to consume well over 100% of the available
bandwidth (data from NRL).

Which protocols would you like to employ?

> draft-soto-mobileip-random-iids)to reduce the collision probability.

This is a great idea... BUT: the solution space should not be
limited to ONLY those solutions that can make use of such
techniques.

> used to detect that a neighbour is no longer reachable, instead of

That is true, but it is by no mean restricted to just routing protocols.
You could also use the lack of TCP acknowledgment for such purposes.
Some solutions make use of promiscuous-mode reception to check
whether the neighbor has relayed your packet to some more distant
destination.

>
>  ...                           I think we were talking

Well, on this point, we are totally on the same page :-).
But, of course, if you happen to know an address for your
neighbor that has larger scope than link-local, you are
free to make use of it.

> whether to use them or not).

I am pretty sure (having been there) that the IPv6 mandates in
question were placed without regard to the realities of ad hoc
networks.  In fact, I think it can be safely said that these mandates
are relevant only to networks where certain subnet structures are
clearly realized.

And anyway I think it is really important in this context to be
clear about which protocols are to be put into service, and just
what is their reliance on link-local addresses.

Regards,
Charlie P.

---

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

Hi Carlos,

> important to configure them (so they can be used) in MANETs.

We have to understand all the protocols using link-local address expect
the uniqueness of LL-address defined as RFC4861.

If LL address cannot be guaranteed uniqueness as RFC4861,
we cannot guarantee the correct behavior of other protocols.

> so low, that I'm not sure it's worth arguing about the necessity of

see above.
AFAIK, It's necessary to make sure the LL address uniqueness if we  
will use it.

regards,
ryuji

---

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

Hi Carlos,

> whether to use them or not).

The differences from the DT draft on this point are
- mandating LL address
- no warning to use it

?

The DT document does not prohibit using LL address, but it clearly  
warn the possible problems (which are MANET specific).
What is your problem of the texts in the DT document?
You can still run existing protocols using the link-local with the  
same condition of your draft (i.e. no DAD).

We should not let this DAD functionality as an optional.
If we want to use LL, we have to provide uniqueness to LL and mandate  
DAD for it.
This is because we shouldn't assume any L1/L2 technology in IP.

regards,
ryuji

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sun, 25 Oct 2009 18:24:08 +0100

Hi Charlie,

Some delayed comments to your e-mail in-line below...

> Which protocols would you like to employ?

Do I need to make a list? do I have to limit only to existing protocols?
there may be also other protocols in the future that what to make use of
link-locals.

> limited to ONLY those solutions that can make use of such

Right, for those that cannot make use of such techniques we could then
develop DAD (or Duplicate Avoidance instead of Detection) mechanisms
that work. Autoconf will hopefully work on solutions some point in time
in the future, working on DAD solutions may be part of the work.

I also want to avoid limiting the solution space of autoconf only to
solutions that do not use LLs :-D

> whether the neighbor has relayed your packet to some more distant

True, there are indeed more ways of doing this.

> neighbor that has larger scope than link-local, you are

True. RFC3484 also says something about this, I guess.

> are relevant only to networks where certain subnet structures are

Then, we should ask to update those standards to reflect this.

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sun, 25 Oct 2009 18:29:02 +0100

Hi Ryuji,

> This is because we shouldn't assume any L1/L2 technology in IP.

I guess we have already addressed this in some other previous e-mails,
but just to avoid leaving e-mails without a reply, I'm providing my view
on this here.

I think there is a difference between draft-bacceli and ours regarding
LL. You might say it is subtle, but I don't think so :-). One draft
says: LLs are not a MUST, but you are free to use them. The other says;
LLs are a MUST, but you are not forced to use them (this is exactly what
IPv6 specs say, in my understanding).

DAD is not mandated for LL, but strongly encouraged. There is again a --
maybe subtle, maybe not -- difference.

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sun, 25 Oct 2009 18:38:49 +0100

Hi Ryuji,

> we cannot guarantee the correct behavior of other protocols.

Sure, but IP is best-effort, so we also need to understand what do we
mean by "guarantee uniqueness"...

> AFAIK, It's necessary to make sure the LL address uniqueness if we  

Sure, but ensuring address "uniqueness" (the level of guarantee that any
protocol running on IP can expect) does not necessarily mean running DAD
(or at least the DAD mechanism defined in IPv6 standards, we can work on
protocols in autoconf).

Thanks,

Carlos

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sun, 25 Oct 2009 18:40:16 +0100

Carlos,

> IPv6 specs say, in my understanding).

I'd say that the truth is as follows:

	o	If you have an LL address [generated by the usual means], it may
		be useless. Use it if you like, but be wary that the properties of  
that
		address are undefined.

I thought that was what the Baccelli/Townsley draft said?

> maybe subtle, maybe not -- difference.

But, DAD [again, the usual DAD] won't (i) get you a usefully unique LL  
address and (ii) even if it does, with DAD being a one-shot operation  
when an interface is brought up, won't ensure LL address uniqueness in  
the future [node mobility would be one cause for such].

Therefore, if you get a LL address using these usual means, it's not  
really useful. I think that's what the Baccelli/Townsley I-D states,  
isn't it ?

Thomas

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sun, 25 Oct 2009 18:52:31 +0100

Hi Thomas,

> I thought that was what the Baccelli/Townsley draft said?

Well, I think that "[generated by the usual means]" can be skipped since
the draft should not go (if possible, know it's hard) into solution
space. I'd make the question: IPv6 mandates LLs, do we really want to
make IPv6 protocols running on MANET be special (in some way) because
this feature of IPv6 is not present in MANETs (i.e. no LLs)? If we say
no, if we want to keep LLs, then we can go into the debate about how to
generate LLs in MANETs (solution space).

> really useful. I think that's what the Baccelli/Townsley I-D states,  

Well, I think I disagree here (see above). Even LL addresses configured
using usual means would probably work in the 99.9% of the scenarios (but
this is just my personal feeling, based on my very limited experience
running IP networks).

Thanks,

Carlos

---

From: Emmanuel Baccelli <[email-masked]>
Date: Sun, 25 Oct 2009 19:02:16 +0100

Hi again Carlos (sending again to the list too this time ;). See below.

2009/10/25 Carlos Jesús Bernardos Cano <[email-masked]>

> IPv6 specs say, in my understanding).
I have a hard time seeing which draft says what, according to you. Neither
draft-ietf, nor draft-bernados I believe, say that "LLs are not a must".
They both say that LLs are assigned to each interface as per [RFC4291]. So
if there is a difference between the drafts on this point, it must be even
more subtle than you thought ;)

Emmanuel

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 25 Oct 2009 11:09:19 -0700

Hello Carlos,

> IPv6 specs say, in my understanding).
The problem with your MUST is that it's silly to mandate
link-locals unless you can guarantee uniqueness, and that
places the bar far too high -- getting in the way of useful
work.
> maybe subtle, maybe not -- difference.

Ins this is where the proponents for manding link-locals
lose their way?   There seems to be a common belief that one can
tacitly rely on uniqueness derived from MAC addresses, but when
this is pointed out, then we fall back on arguing about DAD when
all along the proponents don't plan on implementing DAD in the
first place.

Regards,
Charlie P.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sun, 25 Oct 2009 19:13:06 +0100

Hi Emmanuel,

> Hi again Carlos (sending again to the list too this time ;). See

:-D

> I have a hard time seeing which draft says what, according to you.
> Neither draft-ietf, nor draft-bernados I believe, say that "LLs are
> not a must". They both say that LLs are assigned to each interface as
> per [RFC4291]. So if there is a difference between the drafts on this
> point, it must be even more subtle than you thought ;)

Could be, yes. Well, but if I understood correctly, your draft strongly
discourages the use of LLs and it is not much concerned about the use of
LLs in MANETs (so you are basically putting in the draft what it is
required to not formally contradict IPv6 standards), right? My point was
that our draft is on the side of providing MANET routers with LLs that
_may_ be used if applications/protocols want to (exactly as in the
current non-MANET world).

Thanks,

Carlos

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 25 Oct 2009 11:18:38 -0700

Hello Carlos,

> there may be also other protocols in the future that what to make use of

O.K.  Not an exhaustive list.  How about three examples?

Or one?

> in the future, working on DAD solutions may be part of the work.

This would be terrible.  We can standardize something right now that works
very well.  The only problem is that we must await this interminable 
argument
about something that is known to cause extraordinary difficulty.  Now, even
_after_ we have had consensus and a good document to promulgate.

In all of the argument, I have never seen even the slightest convincing
argument except that link-local is part of the wireline IPv6 addressing
scheme.

> solutions that do not use LLs :-D

This has never been at issue.  If you have a scheme that uses
them, it should receive consideration.  If it only works for
IEEE MAC addresses, perhaps the charter could be expanded
to allow publication of a solution for the restricted problem.

> Then, we should ask to update those standards to reflect this.

Do you really, _really_ want to require [autoconf] to boil the ocean
on this?  We've already consumed years on haggling over what should
have been near-trivial to decide.  If you really believe we need to go
back and accomplish this titanic task before even standardizing the
autoconf use case, I think you should reconsider.

?

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 25 Oct 2009 11:24:52 -0700

> mean by "guarantee uniqueness"...

This argument is absolutely wrong.  You should carefully consider
why IP is "best-effort".  It isn't about allowing address duplication.
I really emphasize that you cannot allow simply any imaginable behavior
and justify the result on the basis of "best-effort".  That's very wrong.

Did I mention that such an argument is quite erroneous and misses
the whole point about why IP is described as "best-effort".

Oh, and one more thing, ...

> (or at least the DAD mechanism defined in IPv6 standards, we can work on

Once again you make reference to treating IP as unreliable.
That is a wrong justification for relaxing uniqueness.

If you want to wrangle this point, I think it should be a long-term
goal, and not get in the way of standardizing some techniques already
known to work.

Regards,
Charlie P.

---

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

Hello Carlos,

Carlos Jesús Bernardos Cano wrote:
>
>  IPv6 mandates LLs, do we really want to

I believe we can safely relax the mandate for creation
of link-locals.  This is not a statement made lightly, but
instead based on a long history of making AODV and DYMO
and other protocols work on IPv6.  It's not that hard to do!

>  ...                          Even LL addresses configured

Your statement is valid for networks with conformant hosts using
IEEE MAC addresses -- but not for all network nodes within the
intended sphere of applicability for IPv6 address.

Regards,
Charlie P.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sun, 25 Oct 2009 19:37:10 +0100

> the whole point about why IP is described as "best-effort".

Current DAD does not prevent a misbehaving/faulty node to configure a
duplicated address and we have to live with that. This is what I tried
to mean. I consider the probability of address duplication very low
(using standard mechanisms, it may even lower if we use something
slightly smarter). I guess current DAD cannot guarantee 100% that
addresses on a link are always unique, this is what I tried to mean by
"best-effort", maybe I didn't use the best possible term.

> goal, and not get in the way of standardizing some techniques already

Well, I think there are ways of statistically ensure address uniqueness
that would work as well.

Thanks,

Carlos

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 25 Oct 2009 11:53:38 -0700

Hello Carlos,

> "best-effort", maybe I didn't use the best possible term.

In my experience, "best-effort" largely refers to what might
otherwise be called "lack of QoS mechanisms".

Your point that we can not absolutely guarantee uniqueness
is still wrong, I think.  When uniqueness isn't guaranteed, the
network breaks.  If DAD is required, but doesn't resolve the
problem, the network breaks.  If DAD is required and kills
the available network bandwidth, just the mandate is already
responsible for killing the network.

When an application misses a packet because of overflow
of an input buffer on the network interface, that's very much
different than when two computers are indistinguishable on
the basis of their IP address.

> Well, I think there are ways of statistically ensure address uniqueness

That's all well and good, but unless there is a good reason to
mandate these burdensome mechanisms, it would be better to
work with the more natural mechanisms that are available.

Regards,
Charlie P.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 26 Oct 2009 00:39:44 +0100

Hi Charlie,

> responsible for killing the network.

Fully agree. However, I think we can avoid duplicates (at least
statistically or just react when they are detected passively) without
using active DAD mechanisms that kill the network.

> the basis of their IP address.

Still, unless SEND is used, there is now guarantee that once a node is
granted an IP address, the node remains being the only one that can use
it.

> work with the more natural mechanisms that are available.

Anyway, we are gonna have also similar problems ensuring address
uniqueness for non-link local addresses, right?

Thanks for the discussion,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 26 Oct 2009 00:41:07 +0100

Hi Charlie,

> intended sphere of applicability for IPv6 address.

True, for those not using MAC addresses, I think using random iids will
just make the work OK.

Thanks,

Carlos

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 25 Oct 2009 17:21:40 -0700

Hello Carlos,

> using active DAD mechanisms that kill the network.

That opinion is in conflict with a very stable consensus during the
design of IPv6, to the effect that that one could not depend on
randomness.  This point has already been discussed in [autoconf]
at least a half-dozen times.

> granted an IP address, the node remains being the only one that can use

Sure, malicious nodes can break a network by masquerading
as another IP address.

That is really drastically different  than designing such pitfalls
into the basic autoconfiguration protocols in the first place.

> uniqueness for non-link local addresses, right?

This has also been discussed many times.  It is very important to
distinguish, because non-local addresses can be meaningfully carried
as fields in a signaling message payload that can be forwarded.   To
do anything similar for link-local addresses is, to put it mildly,
challenging.  Unless you want to do everything at layer 2.  Even
so, I am remembering scatternets.  Not trivial -- and much harder
to really deploy than initially imagined.  Did you ever see one?

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 25 Oct 2009 17:29:38 -0700

Hello Carlos,

> True, for those not using MAC addresses, I think using random iids will

Actually, not.

Please see my other message.

But, one more thing.

This philosophy is especially bad because you
will, statistically, _never_ encounter any bugs in
your lab networks.

Then when your bug shows up in a network
with ten million nodes, you might never find it.

Never.

But maybe you would claim that we must then
rely on the small size of ad hoc networks.
At least it would be easier to find your bug, but
it would be extremely tedious and difficult to
trust any debugging tools or your intuition.

We can't eliminate the need for address
uniqueness by waving the wand of randomness.

Regards,
Charlie P.

---

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

>Thomas Heide Clausen wrote:
>	that address are undefined.

LL may be useful also.
Properties of LL are well defined.

Regards, Teco

---

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

> Properties of LL are well defined.

If by "Well defined [in a MANET]" you mean "unique only within a 1-hop  
radius and also only unique within that 1-hop radius at the very  
instant when DAD is testing uniqueness -- not guaranteed to be unique  
beyond 1-hop and nor even an instant after DAD has completed" then  
yes, LL properties are "well defined [in a MANET]" when using the  
usual means of getting LLs.

I'd question if that's useful, though.

Thomas

---

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

Charlie,

I experienced multiple times a network down in a production network caused
by 
duplicate detection mechanism bugs. These were severity 1 problems, because
all 
nodes were affected.
A duplicate problem primary affects those who have the duplicates. There can
be 
an increased network load or other effects, I do not deny the problem.

Regards, Teco

>-----Oorspronkelijk bericht-----
>Van: [email-masked] [mailto:[email-masked]] Namens
>Charles E. Perkins
>Verzonden: maandag 26 oktober 2009 1:30
>Aan: [email-masked]
>CC: [email-masked]
>Onderwerp: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-
>addressing-model-00.txt
>
>
>Hello Carlos,
>

---

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

>Van: Thomas Heide Clausen [mailto:[email-masked]]
>Verzonden: maandag 26 oktober 2009 9:49
>Aan: Teco Boot
>CC: [email-masked]

Some protocols require a 1-hop scope. LLs are made for this.
DAD problems in a MANET are not specific to LLs at all.

Regards, Teco

---

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

> DAD problems in a MANET are not specific to LLs at all.

Charlie posted considerations on this in a response to Carlos, I think?

Thomas

---

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

> an increased network load or other effects, I do not deny the problem.

If a duplicate occurs on intermediaries (routers) interfaces, this  
certainly will also have the ability to impact other than those who  
have duplicate addresses.

Thomas

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 26 Oct 2009 10:19:32 +0100

Fully agree with Thomas here.

Note that the DT draft says:

"Note that while an IPv6 link-local address is assigned to each interface as
per [RFC4291 <http://tools.ietf.org/html/rfc4291>], in general link-local
addresses are of limited utility on links with undetermined connectivity, as
connnectivity to neighbors may be constantly changing."

So, the draft also says that (per RFC4291) LL are configured on an
interface. It just says that they are not of much use, because it is very
difficult to assure uniqueness beyond 1 hop.

Ulrich

On Mon, Oct 26, 2009 at 9:48 AM, Thomas Heide Clausen <
[email-masked]> wrote:

> radius and also only unique within that 1-hop radius at the very instant
> when DAD is testing uniqueness -- not guaranteed to be unique beyond 1-hop
> and nor even an instant after DAD has completed" then yes, LL properties are
> "well defined [in a MANET]" when using the usual means of getting LLs.
>

---

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

On Oct 26, 2009, at 10:19 AM, Ulrich Herberg wrote:

> "Note that while an IPv6 link-local address is assigned to each  
> interface as per [RFC4291], in general link-local addresses are of  
> limited utility on links with undetermined connectivity, as  
> interface. It just says that they are not of much use, because it is  
> very difficult to assure uniqueness beyond 1 hop.
>

Or even within 1-hop, considering that some interface that (at the  
time of DAD, with DAD being a 1-hop operation) was far away due to  
node mobility has become a neighbor.

Of course, ensuring MANET-wide uniqueness (and, I agree with Charlie's  
consideration on "randomness is not the answer....") of LL addresses  
would address this particular issue. However, in that case, our "LL  
addresses" are not "LL" but "MANET wide", and ULA is likely a better  
term (And address family) to use...

Thomas

> Ulrich
>
> On Mon, Oct 26, 2009 at 9:48 AM, Thomas Heide Clausen <[email-masked] 
> > wrote:
>
> If by "Well defined [in a MANET]" you mean "unique only within a 1- 
> hop radius and also only unique within that 1-hop radius at the very  
> instant when DAD is testing uniqueness -- not guaranteed to be  
> unique beyond 1-hop and nor even an instant after DAD has completed"  
> then yes, LL properties are "well defined [in a MANET]" when using  
> the usual means of getting LLs.
>

---

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

Van: [email-masked] [mailto:[email-masked]] Namens Ulrich Herberg
Verzonden: maandag 26 oktober 2009 10:20
Aan: Thomas Heide Clausen
CC: Teco Boot; [email-masked]
Onderwerp: Re: [Autoconf] I-D
Action:draft-bernardos-autoconf-addressing-model-00.txt

"Note that while an IPv6 link-local address is assigned to each interface as
per [RFC4291 <http://tools.ietf.org/html/rfc4291> ], in general link-local
addresses are of limited utility on links with undetermined connectivity, as
connnectivity to neighbors may be constantly changing."

Same for ULAs and globals to!

Teco.

Ulrich

On Mon, Oct 26, 2009 at 9:48 AM, Thomas Heide Clausen
<[email-masked]> wrote:

LL may be useful also.

Thomas

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 26 Oct 2009 15:08:28 +0100

On Mon, Oct 26, 2009 at 11:56 AM, Teco Boot <[email-masked]> wrote:

>
>
>
>
> *Van:* [email-masked] [mailto:[email-masked]] *Namens *Ulrich
> Herberg
> *Verzonden:* maandag 26 oktober 2009 10:20
> *Aan:* Thomas Heide Clausen
> *CC:* Teco Boot; [email-masked]
> *Onderwerp:* Re: [Autoconf] I-D
> "Note that while an IPv6 link-local address is assigned to each interface
> as per [RFC4291 <http://tools.ietf.org/html/rfc4291>], in general
> link-local addresses are of limited utility on links with undetermined
> connectivity, as connnectivity to neighbors may be constantly changing."
>

ULAs and globals are meant to be managed by mechanisms that are
fundamentally different from the LL mechanisms. ULAs and globals are
naturally unambiguous in a MANET context, contrary to LL addresses.

Could this whole discussion prove once and for all (for the few still not
convinced) that link local addresses are AMBIGUOUS in the context that we
want to address in this working group? Why do we have to discuss this again
and again?

Nobody wants ambiguous standards. So let's keep the boat away from such
rocks, and let's move on!

Emmanuel

---

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

Emmanuel Baccelli a écrit :
> 
> 
> On Mon, Oct 26, 2009 at 11:56 AM, Teco Boot <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      
> 
>      
> 
>     *Van:* [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] *Namens
>     *Ulrich Herberg
>     *CC:* Teco Boot; [email-masked] <mailto:[email-masked]>
>     interface as per [RFC4291 <http://tools.ietf.org/html/rfc4291>], in
>     general link-local addresses are of limited utility on links with
>     undetermined connectivity, as connnectivity to neighbors may be
>     constantly changing."
> 
> Could this whole discussion prove once and for all (for the few still 
> not convinced) that link local addresses are AMBIGUOUS in the context 
> that we want to address in this working group? Why do we have to discuss 
> this again and again?
> 

Emmanuel - how about the LL-MANET-Routers and the link-local multicast 
group RFC5498?

Will the AUTOCONF router join this group at all?  Will it use an ULA to 
join this link-local group?  I'd rather say it would use its link-local 
address to join that group.  But if you discourage it...

Alex

---

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

On Oct 26, 2009, at 3:12 PM, Alexandru Petrescu wrote:

>> On Mon, Oct 26, 2009 at 11:56 AM, Teco Boot <[email-masked] <mailto:[email-masked] 
>> >> wrote:
>> fundamentally different from the LL mechanisms. ULAs and globals  
>> are naturally unambiguous in a MANET context, contrary to LL  
>> addresses. Could this whole discussion prove once and for all (for  
>> the few still not convinced) that link local addresses are  
>> AMBIGUOUS in the context that we want to address in this working  
>> group? Why do we have to discuss this again and again?
>> Nobody wants ambiguous standards. So let's keep the boat away from  
>> such rocks, and let's move on!
>
> Emmanuel - how about the LL-MANET-Routers and the link-local  
> multicast group RFC5498?
>
> Will the AUTOCONF router join this group at all?  Will it use an ULA  
> to join this link-local group?  I'd rather say it would use its link- 
> local address to join that group.  But if you discourage it...
>

When you say "join this link-local group", what do you imagine happen?  
Other than that you tell the kernel in  your OS "hey, if you get  
something destined for group XXXX on this interface, hand me a copy",  
of course?

Thomas

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 26 Oct 2009 15:20:46 +0100

On Mon, Oct 26, 2009 at 3:12 PM, Alexandru Petrescu <
[email-masked]> wrote:

>> On Mon, Oct 26, 2009 at 11:56 AM, Teco Boot <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
>>
>>

These are well known send/listen to addresses. You typically do not "join"
anything, so there is no problem at all.
Emmanuel

---

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

Thomas Heide Clausen a écrit :
>>> that we want to address in this working group? Why do we have to 
>>> discuss this again and again?
>> to join this link-local group?  I'd rather say it would use its 
>> link-local address to join that group.  But if you discourage it...
>>
> 
> something destined for group XXXX on this interface, hand me a copy", of 
> course?

Well, there is also MLD - a more advanced operation than simply setting 
local filters.  With MLD, a node expresses interest in receiving a 
certain group by sending an MLD message.

Do you also discourage MLD?

MLD is what most machines do.

Do you discourage scopes as well?

(and yes, there are implementations and implementations of joing groups,
  sometimes filters - which you imply, work too as you say).

Alex

---

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

Emmanuel Baccelli a écrit :
> 
> 
> On Mon, Oct 26, 2009 at 3:12 PM, Alexandru Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
> 
>            
>            
>         <mailto:[email-masked] <mailto:[email-masked]>>
>            [mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>] *Namens
> 
>            *Ulrich Herberg
>         <mailto:[email-masked] <mailto:[email-masked]>>
> 
>            interface as per [RFC4291
>         <http://tools.ietf.org/html/rfc4291>], in
> 
>         addresses.
>         Could this whole discussion prove once and for all (for the few
>         still not convinced) that link local addresses are AMBIGUOUS in
>         the context that we want to address in this working group? Why
>         do we have to discuss this again and again?
> 
>         Nobody wants ambiguous standards. So let's keep the boat away
>         from such rocks, and let's move on!
> 
> 
> These are well known send/listen to addresses. You typically do not 
> "join" anything, so there is no problem at all.

Typically, a node does join groups of various scopes, link-local scope 
included, by sending MLD Reports.  Recent linux kernels do so.  Setting 
up local filters is an old fashioned way  which does not protect a node 
from noise - its driver is still solicited (the discarding happens at 
the kernel level - too late).

For example, rfc4861 ND says "a node must join" at several places and 
then "Joining the solicited-node multicast address is done using a 
Multicast Listener Discovery such as [MLD] or [MLDv2] protocols."

Do you also discourage this use of groups, scopes and MLD?

Alex

>         [email-masked] <mailto:[email-masked]>

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 26 Oct 2009 15:46:04 +0100

IMO, Alex is right here. Routers have to join multicast groups (although
there might be some exceptions like ff02::1). The RFC that specifies MLDv2
is RFC3810. The Multicast listening state is stored per socket as well as
per interface. I did not find, however, a restriction of scope for a
multicast group based on the unicast address of the interface. There is even
an example in RFC4291 (the mentioned Solicited-Node multicast address) which
creates a link-local multicast group out of a global unicast address:

"For example, the Solicited-Node multicast address corresponding to
the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C."

Please correct me if I am wrong here....

Ulrich

On Mon, Oct 26, 2009 at 3:31 PM, Alexandru Petrescu <
[email-masked]> wrote:

> included, by sending MLD Reports.  Recent linux kernels do so.  Setting up
> local filters is an old fashioned way  which does not protect a node from
> noise - its driver is still solicited (the discarding happens at the kernel
> level - too late).
>
> For example, rfc4861 ND says "a node must join" at several places and then
> "Joining the solicited-node multicast address is done using a Multicast
> Listener Discovery such as [MLD] or [MLDv2] protocols."
>

---

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

On Oct 26, 2009, at 3:46 PM, Ulrich Herberg wrote:

> IMO, Alex is right here. Routers have to join multicast groups  
> (although there might be some exceptions like ff02::1). The RFC that  
> specifies MLDv2 is RFC3810. The Multicast listening state is stored  
> per socket as well as per interface. I did not find, however, a  
> restriction of scope for a multicast group based on the unicast  
> address of the interface. There is even an example in RFC4291 (the  
> mentioned Solicited-Node multicast address) which creates a link- 
> local multicast group out of a global unicast address:
>

As far as I know, you are right -- I do not see a conflict with MLD,  
though. I also note that 4861 and friends are sending to various  
multicast addresses with the undefined address as source....

So I guess I don't grasp the problem that Alex is bringing up?

Thomas
> On Mon, Oct 26, 2009 at 3:31 PM, Alexandru Petrescu <[email-masked] 
> > wrote:
> [...]
> Typically, a node does join groups of various scopes, link-local  
> scope included, by sending MLD Reports.  Recent linux kernels do  
> so.  Setting up local filters is an old fashioned way  which does  
> not protect a node from noise - its driver is still solicited (the  
> discarding happens at the kernel level - too late).
>
> For example, rfc4861 ND says "a node must join" at several places  
> and then "Joining the solicited-node multicast address is done using  
> a Multicast Listener Discovery such as [MLD] or [MLDv2] protocols."
>

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Mon, 26 Oct 2009 15:49:42 +0100

Hi Thomas, Alex, all 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Thomas Heide Clausen
>Sent: maandag 26 oktober 2009 15:16
>To: Alexandru Petrescu
>Cc: [email-masked]; Emmanuel Baccelli
>Subject: Re: [Autoconf]I-D 
>>> <mailto:[email-masked]
>>>    interface. It just says that they are not of much use, 
>because it 
>>> is
>multicast 

But what about the transmitting side? I have just seen it happen in the lab:
NRLOLSRD sends out Hello's to an IPv6 multicast destination address, with an IPv6 link-local source address. I think this is RFC3484, Source Address selection rule #2 ("Prefer appropriate scope") in action.

Regards,
Ronald

>>> Emmanuel
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 26 Oct 2009 15:51:37 +0100

On Mon, Oct 26, 2009 at 3:49 PM, Thomas Heide Clausen <
[email-masked]> wrote:

> though. I also note that 4861 and friends are sending to various multicast
> addresses with the undefined address as source....
>
> "Multicast addresses must not be used as source addresses in IPv6
   packets or appear in any Routing header." [RFC4291]

Ulrich

---

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

On Oct 26, 2009, at 3:51 PM, Ulrich Herberg wrote:

>
>
> On Mon, Oct 26, 2009 at 3:49 PM, Thomas Heide Clausen <[email-masked] 
> > wrote:
>
>> (although there might be some exceptions like ff02::1). The RFC  
>> that specifies MLDv2 is RFC3810. The Multicast listening state is  
>> stored per socket as well as per interface. I did not find,  
>> however, a restriction of scope for a multicast group based on the  
>> unicast address of the interface. There is even an example in  
>> RFC4291 (the mentioned Solicited-Node multicast address) which  
Right - that would be just silly to do ;) But undefined is,  
apparently, quite OK (as per 4861)? And, there're even groups that one  
"joins" even before having an LL address for 4861 to work....

Thomas

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 26 Oct 2009 15:57:14 +0100

On Mon, Oct 26, 2009 at 3:49 PM, Velt, R. (Ronald) in 't <
[email-masked]> wrote:

> NRLOLSRD sends out Hello's to an IPv6 multicast destination address, with
> an IPv6 link-local source address. I think this is RFC3484, Source Address
> selection rule #2 ("Prefer appropriate scope") in action.
>
>
That's possible. However, might not be a good idea. In my OLSRv2
implementation, I set the source address to a global IPv6 address, if such
is available. (if no such address is possible, I think that my
implementation will kill itself... have to check ;-)

Ulrich

---

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

Ulrich Herberg a écrit :
> mentioned Solicited-Node multicast address) which creates a
> link-local multicast group out of a global unicast address:
> 

Right, the solicited-node multicast group derived from the IID of an 
IPv6 global address - that is ok.  It is a local derivation.  It is ok.

I meant this: when node A joins froun ff02::2 by putting its link-local 
address in the MLD src address:
>    An MLDv2 Report MUST be sent with a valid IPv6 link-local source
>    address, or the unspecified address (::), if the sending interface
>    has not acquired a valid link-local address yet.

I think that if AUTOCONF discourages the link-local addresses then 
automatically MLD will use "::" (unspecified address) in its src.

I don't think this is an MLD problem.

I think these things are so much intertwinned that it's hard to simply 
discourage the use of link-local addresses.

Alex

> On Mon, Oct 26, 2009 at 3:31 PM, Alexandru Petrescu 
> [...] Typically, a node does join groups of various scopes,
> link-local scope included, by sending MLD Reports.  Recent linux
> kernels do so. Setting up local filters is an old fashioned way
> which does not protect a node from noise - its driver is still
> solicited (the discarding happens at the kernel level - too late).
> 
> _______________________________________________ Autoconf mailing list
> <mailto:[email-masked] <mailto:[email-masked]>>
> 
> _______________________________________________ Autoconf mailing list

---

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

Thomas Heide Clausen a écrit :
>> mentioned Solicited-Node multicast address) which creates a link-local 
>> multicast group out of a global unicast address:
>>
> 

YEs, these are exceptions.  When no LL address available, use the "::" 
unspecified address.  I think it i smore advantageous to use the LL 
address is used.

> So I guess I don't grasp the problem that Alex is bringing up?

WEll yes, no problem; as long as you discourage the LL addresses let's 
use the "::" address, and not some AUTOCONF configured address - is this ok?

Alex

> 
> Thomas
>> "For example, the Solicited-Node multicast address corresponding to the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C."
>>
>>
>>     and then "Joining the solicited-node multicast address is done
>>     using a Multicast Listener Discovery such as [MLD] or [MLDv2]
>>     protocols."
>>

---

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

Thomas Heide Clausen a écrit :
>> On Mon, Oct 26, 2009 at 3:49 PM, Thomas Heide Clausen 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>>     however, a restriction of scope for a multicast group based on
>>>     the unicast address of the interface. There is even an example in
>>     As far as I know, you are right -- I do not see a conflict with
>>     MLD, though. I also note that 4861 and friends are sending to
>>     various multicast addresses with the undefined address as source....
>>
> Right - that would be just silly to do ;) But undefined is, apparently, 
> quite OK (as per 4861)? And, there're even groups that one "joins" even 
> before having an LL address for 4861 to work....

Yes, that is right.  But when having that LL address - use it.

DO you see it like:

-if not having an LL then use "::" unspecified address instead, and if 
you then obtain an LL address then don't use it.

Alex

---

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

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

> I meant this: when node A joins froun ff02::2 by putting its link- 
> local address in the MLD src address:
> I think these things are so much intertwinned that it's hard to  
> simply discourage the use of link-local addresses.
>

So what you propose is, that LL addresses MUST be globally (or, at  
least, MANET-wide) unique?  I.e. that LL addresses MUST be verified in  
a scope beyond 1 hop?

---

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

Thomas Heide Clausen a écrit :
>> I meant this: when node A joins froun ff02::2 by putting its 
>> link-local address in the MLD src address:
> least, MANET-wide) unique?  I.e. that LL addresses MUST be verified in a 
> scope beyond 1 hop?

Not really, I propose to use the LL addresses as they are originally 
planned to, and not to discourage them.

Alex

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 26 Oct 2009 16:25:39 +0100

On Mon, Oct 26, 2009 at 4:22 PM, Alexandru Petrescu <
[email-masked]> wrote:

>> So what you propose is, that LL addresses MUST be globally (or, at least,
>> MANET-wide) unique?  I.e. that LL addresses MUST be verified in a scope
>> beyond 1 hop?
>>
>>

Originally, they have been planned to wired networks, so with very different
assumptions. So it is not possible to use them as originally planned. If you
want to use them as originally planned, you have the whole lot of problems
that are mentioned in the DT draft.
If you plan to use them, you have to assure exactly what Thomas asked as a
question.

Ulrich

---

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

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

>>> Right, the solicited-node multicast group derived from the IID of  
>>> an IPv6 global address - that is ok.  It is a local derivation.   
>>> It is ok.
>>>
>> least, MANET-wide) unique?  I.e. that LL addresses MUST be verified  
>> in a scope beyond 1 hop?
>

Either:

	o	you render the addresses useful in the MANET context;
	o	or, you discourage their use.

As they are, LL addresses are - for reasons that have been listed,  
enumerated and discussed ad infinitum on this list and in [autoconf]  
in general - not suitable for much in a MANET. I think that the two  
addressing architecture Baccelli/Townsley and Carlos/Ronald (sorry  
guys, your last names are too hard to type ;) ) I-Ds both make that  
clear.

Propose something that will *work*, and is experimentally and  
deployment-wise supported, and I'm sure that we all will be listening.  
Until then, I'm afraid that we're running in circles.

Thomas

---

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

On Oct 26, 2009, at 4:25 PM, Ulrich Herberg wrote:

>
>
> On Mon, Oct 26, 2009 at 4:22 PM, Alexandru Petrescu <[email-masked] 
> > wrote:
> Originally, they have been planned to wired networks, so with very  
> different assumptions. So it is not possible to use them as  
> originally planned. If you want to use them as originally planned,  
> you have the whole lot of problems that are mentioned in the DT draft.
> If you plan to use them, you have to assure exactly what Thomas  
> asked as a question.
>

Or, you have to use them on an Ethernet ;) Which is, then, not  
[autoconf].

Thomas

---

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

Ulrich Herberg a écrit :
> 
> 
> On Mon, Oct 26, 2009 at 4:22 PM, Alexandru Petrescu 
>         So what you propose is, that LL addresses MUST be globally (or,
>         at least, MANET-wide) unique?  I.e. that LL addresses MUST be
>         verified in a scope beyond 1 hop?
> 
> 
> Originally, they have been planned to wired networks,

I doubt this.  I will not tell the contrary to you.

I think IPv6 LLs were designed at a time (1996?) when "Packet Radio" had 
already happened.  I wasn't there, I can't say, but I feel that IPv6 LLs 
were there to work with the "future" Internet ("future" at that time) 
which planned for many small wireless devices moving around.

This is speculation from my part - I wasn't there.

> so with very 
> different assumptions. So it is not possible to use them as originally 
> planned. If you want to use them as originally planned, you have the 
> whole lot of problems that are mentioned in the DT draft.
> If you plan to use them, you have to assure exactly what Thomas asked as 
> a question.

Well ok.

Let's at least make sure that some node using LLs is not disturbed when 
connecting to an adhoc node which is discouraged from using LLs; as the 
Charter requires.

In this sense, it may be that we discourage the adhoc router from 
running OSPF/MLD/DHCP (see list posting); i.e. adhoc router and non 
adhoc aware router can't talk to each other using these protocols.

I think we should write this down.

Alex

---

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

>     o    you render the addresses useful in the MANET context;

I agree on this point - render LL addresses useful for MANET contexts. 
Start with some OLSR implementations.

> enumerated and discussed ad infinitum on this list and in [autoconf] in 
> general - not suitable for much in a MANET. I think that the two 
> addressing architecture Baccelli/Townsley and Carlos/Ronald (sorry guys, 
> your last names are too hard to type ;) ) I-Ds both make that clear.

Well - one of them isn't discouraging the LL addresses.

Alex

---

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

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

>>  <mailto:[email-masked]>> wrote:
> I think IPv6 LLs were designed at a time (1996?) when "Packet Radio"  
> had already happened.  I wasn't there, I can't say, but I feel that  
> IPv6 LLs were there to work with the "future" Internet ("future" at  
> that time) which planned for many small wireless devices moving  
> around.
>
>> so with very different assumptions. So it is not possible to use  
>> them as originally planned. If you want to use them as originally  
>> planned, you have the whole lot of problems that are mentioned in  
>> the DT draft.
> Let's at least make sure that some node using LLs is not disturbed  
> when connecting to an adhoc node which is discouraged from using  
> LLs; as the Charter requires.
>

And, if you return to my message from this morning....as long as that  
"node using LLs" connects as it should, it'll be working just fine.

> adhoc aware router can't talk to each other using these protocols.

SighS....did you read my example from this morning?

Thomas

---

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

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

>>>>> Right, the solicited-node multicast group derived from the IID  
>>>>> of an IPv6 global address - that is ok.  It is a local  
>>>>> derivation.  It is ok.
>>>>>
>>>>> I think that if AUTOCONF discourages the link-local addresses  
>>>>> then automatically MLD will use "::" (unspecified address) in  
>>>>> its src.
>>>>>
>>> Not really, I propose to use the LL addresses as they are  
>>> originally planned to, and not to discourage them.
>>>
>> Either:
> I agree on this point - render LL addresses useful for MANET  
> contexts. Start with some OLSR implementations.

Fine, provide me with MANET-wide unique LL addresses, i.e. verify  
uniqueness across the entire MANET (i.e. beyond 1 hop). But you didn't  
want that....

>> enumerated and discussed ad infinitum on this list and in  
>> [autoconf] in general - not suitable for much in a MANET. I think  
>> that the two addressing architecture Baccelli/Townsley and Carlos/ 
>> Ronald (sorry guys, your last names are too hard to type ;) ) I-Ds  
>> both make that clear.
>

One of them says "discourage" the other says "Two main concerns may  
arise....Having brought to attention these concerns, it is further  
left to the designers of MANET routing protocols (and other protocols)  
to determine whether link-local addresses can be used in an effective  
way."

Same difference.....except that one is taking a honest look at what is  
currently *operational*.....

Thomas

---

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

Thomas Heide Clausen a écrit :
>> that time) which planned for many small wireless devices moving around.
>>
>>> so with very different assumptions. So it is not possible to use them 
>>> as originally planned. If you want to use them as originally planned, 
>>> If you plan to use them, you have to assure exactly what Thomas asked 
>>> as a question.
>>
>> Well ok.
>>
>> when connecting to an adhoc node which is discouraged from using LLs; 
>> as the Charter requires.
>>
> 

What do you mean by "as it should"?  Is it by _not_ using its LL 
address?  It is very hard to impose a non-MANET node to not use its LL 
address, when it has one.

Or do you still allow the non-MANET node to use its LL address when 
connecting to a MANET node?

> SighS....did you read my example from this morning?

The OSPF example?  I said that a non-OSPF router connecting to an OSPF 
router is not disturbed by the latter's HELLOs because both use the same 
addressing mechanisms (multicast groups and joins).

Did you read my reply? :-)

Alex

---

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

> uniqueness across the entire MANET (i.e. beyond 1 hop). But you didn't 

Right, that is not needed.  LL addresses should stay unique within their 
scope and packets with src or dst an LL address should not be forwarded 
beyond 1 hop.

If LLs act this way - is it enough for you to not discourage their use?

> arise....Having brought to attention these concerns, it is further left 
> to the designers of MANET routing protocols (and other protocols) to 
> determine whether link-local addresses can be used in an effective way."
> 

So change the order: put the "discourage LL" part at the end, as an 
optional aspect.

Put the concerns in a list of advantages and disadvantages of LLs:

LL advantages: X, Y and Z.
LL disadvantages: concern A-B-C.

Alex

---

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

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

>>> I think IPv6 LLs were designed at a time (1996?) when "Packet  
>>> Radio" had already happened.  I wasn't there, I can't say, but I  
>>> feel that IPv6 LLs were there to work with the "future" Internet  
>>> ("future" at that time) which planned for many small wireless  
>>> devices moving around.
>>>
>> And, if you return to my message from this morning....as long as  
>> that "node using LLs" connects as it should, it'll be working just  
>> fine.
>
> address?  It is very hard to impose a non-MANET node to not use its  
> LL address, when it has one.
>

Of course. Do you still allow a non-OSPFv3 node to connect to an  
OSPFv3 router?

>>> running OSPF/MLD/DHCP (see list posting); i.e. adhoc router and  
>>> non adhoc aware router can't talk to each other using these  
>>> protocols.
> The OSPF example?  I said that a non-OSPF router connecting to an  
> OSPF router is not disturbed by the latter's HELLOs because both use  
> the same addressing mechanisms (multicast groups and joins).
>

No, that was not the one.

> Did you read my reply? :-)

I saw a message from you, yes. I even read it. But it didn't address  
the issue we're discussing.

Thomas

---

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

Thomas Heide Clausen a écrit :
> Of course. Do you still allow a non-OSPFv3 node to connect to an OSPFv3 
> router?

Ok, in this case, I think the disturbing aspect is when you say "in this 
context, discourage LLs", because it is not clear that context==MANET.

An idea is to reformulate and say:

"Non-MANET nodes connecting to MANET nodes are free to use their LLs as
  specified in RFCs like "IPv6 addressing architecture".  The behaviour
  of MANET nodes will not cause problems to any non-MANET node running
  protocols using LLs, see list of these protocols in Appendix A.

  Also see list of potential problems caused by MANET nodes not using
  LLs, connected to non-MANET nodes using LLs, in Appendix B.

  MANET nodes are discouraged from using LLs, because concerns X and Y,
  see Appendix C."

Does this sound ok?

I can write the Appendices A and B.

>> router is not disturbed by the latter's HELLOs because both use the 
>> same addressing mechanisms (multicast groups and joins).
>>
> 
> I saw a message from you, yes. I even read it. But it didn't address the 
> issue we're discussing.

Re-post then.

Alex

---

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

Emmanuel Baccelli wrote:
> are naturally unambiguous in a MANET context, contrary to LL addresses. 

??????
Maybe you have a different version of IPv6 than I have. My implementations
supports IPv6 Stateless Address Autoconfiguration [RFC 4862].

Regards, Teco

---

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

Hi

> mean by "guarantee uniqueness"...

Come on, IP is best-effort in terms of packet delivery.
If the address uniqueness is not guaranteed, all the IP infrastructure  
might be collapsed.

> (or at least the DAD mechanism defined in IPv6 standards, we can  

The WG decision is not to work on this DAD solution for LL in AUTOCONF.
We have decided to primary focus on non-LL address for its MANET  
operations.
Is that what we've dicussed since AUTOCONF was established, no?
How many time do you repeat the same discussion? Let's move on.

regards,
ryuji

---

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

Hi Carlos,

> maybe subtle, maybe not -- difference.

This LL treatment had been discussed in AUTOCONF and were solved, right?
People agreed what DT document said.
I don't think we should re-visit the same issue so many times.

regards,
ryuji

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 27 Oct 2009 09:05:00 +0100

>Ryuji Wakikawa wrote:

Yes, it might be. But it is reasonable to assume the larger part is not affected
at all.
I'm almost sure duplicate L2 addresses have also a negative effect, and
making sure IPv6 addresses are unique doesn't help much here. So the gain on
avoiding duplicates for these cases could be quite small.

Of course, we all want to avoid duplicates.

Regards, Teco

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 27 Oct 2009 09:10:12 +0100

>I don't think we should re-visit the same issue so many times.

No, we did not agreed. I posted comments at early stages, I repeated
a couple of times. I think the baccelli draft is still wrong. On details,
but still. It seems that I am not the only one. Maybe there is a majority
in the WG.

If I missed a consensus, please provide a pointer in mail archive.

Regards, Teco

---

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

> If the address uniqueness is not guaranteed, all the IP infrastructure 

I agree IP is best-effor mostly in terms of packet delivery.

It is also true that the uniqueness ensuring mechanisms of IP are made 
to the best of one's capabilities - I don't think one can do any better.

AUTOCONF can't do any better than DAD and DNA and DHCP and MAC did with 
respect to uniqueness.  Especially since AUTOCONF is incapable of 
describing what's wrong with DAD, oDAD, DNA, DHCP and MAC.

Be serious you too :-)

Alex

---

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

> I don't think we should re-visit the same issue so many times.

Ryuji - I now fully disagree with the DT document.

I disagree with _all_ of its recommendations.

Alex

---

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

Alex,

On Tue, Oct 27, 2009 at 10:49 AM, Alexandru Petrescu

> I disagree with _all_ of its recommendations.

<irony>Now, that's a very helpful statement for the discussion.</irony>

Could you be a bit more precise?

Ulrich

---

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

Ulrich,

 From a procedural standpoint, two things:

The DT draft has very little inherent validity as a WG item - it was 
forced on the WG without asking the WG.

Additionally, it does not do some things that the Charter asks it to do: 
it doesn't describe how the addressing model impacts or not the 
non-MANET nodes connecting to MANET nodes.

For technical details about what I don't agree in the DT draft:

> Could you be a bit more precise?

Seriously, here are the draft statements I disagree with:

In the section 4 IP Subnet Prefix COnfiguration:
[...]
>   o  no two such interfaces in the network should be configured with
>       the same subnet prefix.
[...]

This ignores the presence of LL prefix fe80::/10.

In section 6.1 IPv4 model:
>    Note that the use of IPv4 link-local addresses [RFC3927] in this
>    context should be discouraged for most applications,

This ignores the existence and widespread use of applications using IPv4 
LLs behind NAT.

In section 6.2 IPv6 Model:
>    o  A subnet prefix configured on this interface should be of length
>       /128.

This is completely out of scope, because /128 prefixes make no sense in 
terms of subnet and multicast.

>    Therefore MANET autoconfiguration solutions should be encouraged to
>    primarily focus on configuring IP addresses that are not IPv6 link-
>    local.

This says what should not be done, but it does not say what should be done.

After writing all this text, are you going to agree with me?

Alex

---

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

Moreover, I disagree with this part of the document:

> routers which connect to links with undetermined connectivity
> properties.

These links simply don't exist.

All links deployed have determined connectivity properties, suffices it 
to test them according to their spec.

Were they undetermined nobody would use them - run away from them.

Alex

Alexandru Petrescu a écrit :
> Additionally, it does not do some things that the Charter asks it to
> do: it doesn't describe how the addressing model impacts or not the 
>> [...] Ryuji - I now fully disagree with the DT document.
>> 
> In the section 4 IP Subnet Prefix COnfiguration: [...]
> This ignores the existence and widespread use of applications using
> IPv4 LLs behind NAT.
> 
> This is completely out of scope, because /128 prefixes make no sense
> in terms of subnet and multicast.
> 
>>  primarily focus on configuring IP addresses that are not IPv6
>> link- local.
>

---

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

Hello Alex,

Alexandru Petrescu wrote:
>> If the address uniqueness is not guaranteed, all the IP 
>> infrastructure might be collapsed.
>

This exhibits a lack of understanding.

It is NOT the case that IP was designed with any sort of
lackadaisical approach to address uniqueness.

And, if the goal of the design of IP were assured
packet delivery, it COULD have been done differently.

Discussions like these, I am sure, have caused enormous
grief to whoever coined the term "best effort".

>
>
> AUTOCONF can't do any better than DAD and DNA and DHCP and MAC did 
> with respect to uniqueness.

If one cares about scalability in the face of mobility and wireless 
connectivity,
then yes we can, and people have.

>   Especially since AUTOCONF is incapable of describing what's wrong 
> with DAD, oDAD, DNA, DHCP and MAC.

Perhaps you are incapable of digesting the descriptions
that have been offered many times.

> Be serious you too :-)

In my opinion, you make that into a difficult assignment.

Regards,
Charlie P.

---

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

Hello Alex,

> forced on the WG without asking the WG.

Perhaps we should verify consensus.

> non-MANET nodes connecting to MANET nodes.

By my reading it does not have to do this.  The solutions have to
obey that charter requirement.

> This ignores the presence of LL prefix fe80::/10.

For good reason!

> This ignores the existence and widespread use of applications using 

Maybe they won't work in an ad hoc network.

> in terms of subnet and multicast.

I don't have a problem with that.

> This says what should not be done, but it does not say what should be 

It says that you should pick long prefixes unless you
have a reason to make less restrictive choices.

Therefore your statement is false.

Regards,
Charlie P.

---

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

Charles E. Perkins a écrit :
>>> Come on, IP is best-effort in terms of packet delivery. If the
>>> address uniqueness is not guaranteed, all the IP infrastructure
>>> might be collapsed.
>> 
>> It is also true that the uniqueness ensuring mechanisms of IP are
>> made to the best of one's capabilities - I don't think one can do
>> any better.
> 
> And, if the goal of the design of IP were assured packet delivery, it
> COULD have been done differently.
> 
> Discussions like these, I am sure, have caused enormous grief to
> whoever coined the term "best effort".
> 
>> 
>> 
> connectivity, then yes we can, and people have.

Too generic Charles, too generic to my reading.  And ingeniously takes 
advantage of recent real politics verbiage - yes you can.

Let's talk protocols and problems of protocols and link layers with 
names on them.

> Perhaps you are incapable of digesting the descriptions that have
> been offered many times.

Let's talk again the ABC problem.

Alex

> Regards, Charlie P.

---

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

Hello Alex,

> advantage of recent real politics verbiage - yes you can.

I didn't even notice.

But IP is pretty generic.  I think that's a feature.

> Let's talk protocols
Check.

> and problems of protocols

Check.

> and link layers with names on them.

Strong disagreement.

> Let's talk again the ABC problem.

Are these the three nodes?

I don't remember which problem it is.

Regards,
Charlie P.

---

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

Hello Alex,

> These links simply don't exist.

Perhaps you could offer a constructive improvement?

Perhaps you'd prefer:
    "routers which connect via links with connectivity
     properties not conducive to supporting link-local
     addresses"...?

Regards,
Charlie P.

---

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

> Perhaps we should verify consensus.

Yes - let's start by removing it from the group and making it back a DT 
document - and only then verify consensus.  Otherwise it makes no sense 
to make a consensus call on a draft already a WG item.

> obey that charter requirement.

I doubt that.  The Charter was designed specifically for the addressing 
model draft only.

The current Charter is only about the addressing model draft.

Alex
PS: let me paste its relevant 2nd half below for everybody else's quick 
view:

http://www.ietf.org/dyn/wg/charter/autoconf-charter.html
[...]
> The main purpose of the AUTOCONF WG is to describe the addressing model
> for ad hoc networks and how nodes in these networks configure their
> addresses. It is required that such 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. This group's effort may include the development of new protocol
> mechanisms, should the existing IP autoconfiguration mechanisms be found
> inadequate. However, the first task of the working group is to describe
> one practical addressing model for ad hoc networks.
> 
> Once this sole work item is completed, the group can be rechartered to
> work on additional issues.

---

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

Hello Alex,

Alexandru Petrescu wrote:
> Yes - let's start by removing it from the group and making it back a 
> DT document - and only then verify consensus.  Otherwise it makes no 
> sense to make a consensus call on a draft already a WG item.

What does it mean to remove it from the group?
And, I think the design team has completed its task.

> I doubt that.  The Charter was designed specifically for the 
> addressing model draft only.
>
> PS: let me paste its relevant 2nd half below for everybody else's 
> quick view:
>

The solutions that I am familiar with would fit within the
solution space defined by the DT addressing model draft,
and they do allow connectivity to non-MANET nodes
within the MANET as suggested.

So this is a non-issue.

Regards,
Charlie P.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 27 Oct 2009 18:26:21 +0100

On Oct 27, 2009, at 5:32 PM, Charles E. Perkins wrote:

>> The DT draft has very little inherent validity as a WG item - it  
>> was forced on the WG without asking the WG.
>
>> Additionally, it does not do some things that the Charter asks it  
>> to do: it doesn't describe how the addressing model impacts or not  
>> the non-MANET nodes connecting to MANET nodes.
>

Dear Charlie,

I think that what your correspondent doesn't fully get is, that MANET  
describes "what goes on between routers", not "what goes on between  
hosts and routers", and so therefore doesn't get what the "MANET  
aware" and "non-MANET aware" parts are.

In part, I think that this is due to general confusion as to "what is  
a router": there are, at least, three diverging views on that,  
depending on whom you ask, and I think that if one focuses narrowly on  
one of these views one won't capture what it is we're talking about  
when we say "MANET aware" and "non-MANET aware".

Thomas

>> This is completely out of scope, because /128 prefixes make no  
>> sense in terms of subnet and multicast.
>
>>> link-

---

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

> I don't remember which problem it is.

The problem was described like this: three nodes A-B-C each having one 
wireless interface.  Because A and C can't hear each other then DAD cant 
detect duplicates.  Worse, duplicates are likely to appear because MAC 
IEEE does not guarantee uniqueness across non-IEEE.

That was the problem described.

Alex

---

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

>     properties not conducive to supporting link-local

Hmm... sounds better than "undetermined connectivity properties".

But, a link-local address is not necessarily derived from the link-layer 
connectivity properties.  It could be fe80::1 - would you agree with 
those LL addresses not derived from the link-layer properties?

Alex

---

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

Hello Alex,

Alexandru Petrescu wrote:
> wireless interface.  Because A and C can't hear each other then DAD 
> cant detect duplicates.  Worse, duplicates are likely to appear 
> because MAC IEEE does not guarantee uniqueness across non-IEEE.
>

This is discussed in the previously cited document:

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

Which I am almost sure you had already read.

Regards,
Charlie P.

---

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

> And, I think the design team has completed its task.

Charles - this is politics - your way of tempting me into believing a 
consensus could be called on something already adopted.

Retire it first and then we talk consensus call, especially in the light 
of the existence of draft-bernardos.

> within the MANET as suggested.

Well that is ok - say so in the draft - that we allow the connectivity 
of non-MANET nodes to MANET.  And this will include the LLs.

That will mean that the MANET router does not behave badly when 
presented with a LL of somebody.

Alex

---

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

Thomas Heide Clausen a écrit :
> hosts and routers", and so therefore doesn't get what the "MANET aware" 
> and "non-MANET aware" parts are.

Thomas - you forget that I wrote and implemented text and code precisely 
about that, i.e. a Router sometimes acting as a Host on its egress 
interface.  About which I had some consensus.

I think I know what I'm talking about.

Alex

> 
> In part, I think that this is due to general confusion as to "what is a 
> router": there are, at least, three diverging views on that, depending 
> on whom you ask, and I think that if one focuses narrowly on one of 
> these views one won't capture what it is we're talking about when we say 
> "MANET aware" and "non-MANET aware".
> 
> Thomas
> 
> 
>

---

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

Hello Alex,

Alexandru Petrescu wrote:
> But, a link-local address is not necessarily derived from the 
> link-layer connectivity properties.  It could be fe80::1 - would you 
> agree with those LL addresses not derived from the link-layer properties?

I don't care.  This is useless argumentation.

I only care that this has been
such a monstrous waste of time and effort,
for so precious little gain except to have a
bit of practice in saying the same things over
and over again to people who otherwise do
not even care to solve the problem of
interest to the practitioners.

Regards,
Charlie P.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 28 Oct 2009 10:51:22 +0100

Hi Charlie,

> uniqueness by waving the wand of randomness.

One question? what is less likely to happen? two IPv6 addresses with
iids randomly generated to be unique or that the DAD message (NS sent to
the solicited-node multicast address of the target address) is not
received (when sent over wireless)?

I just want to understand how good is current DAD in current non-MANET
wireless networks.

Thanks,

Carlos

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 28 Oct 2009 11:00:06 +0100

Carlos,

2009/10/28 Carlos Jesús Bernardos Cano <[email-masked]>

> received (when sent over wireless)?

The answer is: it depends. ;-) If you have a good random number generator
(i.e. using an unambiguous seed), then the collision probability is
extremely low. (I let you calculate it using the birthday theorem). However,
if you have small embedded devices, without persistent memory, good random
number generator, etc., you can have collisions with a much higher
probability.

Ulrich

---

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

>The answer is: it depends. ;-) If you have a good random number 
>generator (i.e. using an unambiguous seed), then the collision 
>probability is extremely low. (I let you calculate it using the 
>birthday theorem). 

Are birthdays random ??

>However, if you have small embedded devices, without persistent 
>memory, good random number generator, etc., you can have collisions
>with a much higher probability.   

Why? 
It is easy to build a pretty good PRN generator with radio HW.
I would say it is much, much, much, much easier than uniqueness
guarantee with try and error duplicate detection. Not even
mentioning total network meltdowns after a first MANET merge.

And I don't have those devices, I want to stay far, far from them.
And I don't want to run protocols for it in my MANETs.
Please provide refs to equipment that you have in mind. First,
I'll check why good PRN can't be supported. If not, I can stay 
far away from these (also having security in mind).

Still waiting on answers on DHCP DUID, key generation etc.

Regards, Teco

---

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

Teco Boot a écrit :
> guarantee with try and error duplicate detection.

I agree.  Moreover, there is an RFC talking how to select good entropy 
sources such that the PRN generator is good.

(small embedded devices, such as sensors, can constitute good sources of
  randomness when sampling the temperature, for example - that RFC says).

Alex

> Not even

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 28 Oct 2009 12:43:04 +0100

Alex, Teco,

On Wed, Oct 28, 2009 at 11:54 AM, Alexandru Petrescu <
[email-masked]> wrote:

>  [..]
>>> extremely low. (I let you calculate it using the birthday theorem).
>>>
>>
>> Are birthdays random ??
>>
>

Probably not... I can imagine that there are some peeks 9 months after
extremely cold and rainy days ;-) I will not dig deeper into this issue :-)

>
>>
>>  However, if you have small embedded devices, without persistent memory,
>>> good random number generator, etc., you can have collisions
>> Why? It is easy to build a pretty good PRN generator with radio HW.

Do you mean RFC 4086? Yes, as you say, but all depends on selecting a good
entropy source. The RFC says:

"Is there any hope for true, strong, portable randomness in the future?
There might be. All that's needed is a physical source of unpredictable
numbers."

It also says that if no good hardware entropy sources are available, "there
are other possibilities. These include system clocks, system or input/output
buffers, user/system/hardware/network serial numbers or addresses and
timing, and user input. Unfortunately, each of these sources can produce
very limited or predictable values under some circumstances."

So it really depends on the kind of hardware we are talking about. I could
imagine very small sensors without persistent state or other hardware source
such as mentioned in the RFC. Using such a device could lead to collisions
when calculating random numbers.

>  randomness when sampling the temperature, for example - that RFC says).

yes. But can we guarantee that each MANET router has a good entropy source?
Please point me to some reference saying that each device that can be used
in a MANET must have a good entropy source.

Ulrich

>> I'll check why good PRN can't be supported. If not, I can stay far away
>> from these (also having security in mind).
>>

---

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

Ulrich Herberg a écrit :
> Alex, Teco,
> 
> On Wed, Oct 28, 2009 at 11:54 AM, Alexandru Petrescu 
>             The answer is: it depends. ;-) If you have a good random
>             number generator (i.e. using an unambiguous seed), then the
>             collision probability is extremely low. (I let you calculate
>             it using the birthday theorem).
> 
> 
>         Are birthdays random ??
> 
> 
> 
>             However, if you have small embedded devices, without
>             persistent memory, good random number generator, etc., you
>             can have collisions
>     I agree.  Moreover, there is an RFC talking how to select good
>     entropy sources such that the PRN generator is good.
> 
> 
> Do you mean RFC 4086? Yes, as you say, but all depends on selecting a 
> good entropy source. The RFC says:
> 
> It also says that if no good hardware entropy sources are available, 
> "there are other possibilities. These include system clocks, system or 
> input/output buffers, user/system/hardware/network serial numbers or 
> addresses and timing, and user input. Unfortunately, each of these 
> sources can produce very limited or predictable values under some 
> circumstances."
> 
> So it really depends on the kind of hardware we are talking about.

Yes, certainly.

> I could imagine very small sensors without persistent state or other 
> hardware source such as mentioned in the RFC. Using such a device
> could lead to collisions when calculating random numbers.
> 
> 
> 
> yes. But can we guarantee that each MANET router has a good entropy 
> source? Please point me to some reference saying that each device that 
> can be used in a MANET must have a good entropy source.

Well, if there is one, then use it.

Just don't discourage them.

Alex

---

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

Hi Ulrich,

Few things.

Please realize your rich text mails is becoming a mess, when 
replied with other tools. This troubles the already troubled
discussion. I stop cleaning up.

Then on the small stuff: we are working on MANET stuff, OK?
We have a radio, right?
We can use this radio for catching background noise, right?
This is either thermal noise, human made noise, interference, timing, 
timing of packets received, just to come up with a few.
Please let me know this does not make sense. Because then, I want
to be warned and want to stay far, far away from such devices.

You were active on MANET and security. Spend some cycles on
PRN for small embedded devices with radios? I don't want to push you,
but it would help us if you do.

Regards, Teco

Van: Ulrich Herberg [mailto:[email-masked]] 
Verzonden: woensdag 28 oktober 2009 12:43
Aan: Alexandru Petrescu
CC: Teco Boot; [email-masked]
Onderwerp: Re: [Autoconf] I-D
Action:draft-bernardos-autoconf-addressing-model-00.txt

Alex, Teco,
On Wed, Oct 28, 2009 at 11:54 AM, Alexandru Petrescu
<[email-masked]> wrote:
Teco Boot a écrit :

[..]

Are birthdays random ??

However, if you have small embedded devices, without persistent memory, good
random number generator, etc., you can have collisions
with a much higher probability.   

Ulrich

Alex
Not even

And I don't have those devices, I want to stay far, far from them.
And I don't want to run protocols for it in my MANETs.
Please provide refs to equipment that you have in mind. First,
I'll check why good PRN can't be supported. If not, I can stay far away from
these (also having security in mind).

Regards, Teco

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 28 Oct 2009 14:07:06 +0100

Hi Teco,

> discussion. I stop cleaning up.

I did not realize that. If I just answer like now (without changing the
font), is it readable? If not, I can also change to plain text for future
mails.

> Then on the small stuff: we are working on MANET stuff, OK?

I hope so :-)

> We have a radio, right?

yes

> We can use this radio for catching background noise, right?

yes

> timing of packets received, just to come up with a few.

Yes, I am aware that a radio can be good enough as entropy source. The
question is: can we _always_ assume that it is good enough (or accessible to
the device)? Is there an RFC that claims something like: "All devices that
are used in a MANET MUST be able to provide a sufficiently good entropy
source". (for whatever meaning of "sufficient")

Because, if we don't have that, I am not sure we can rely on good random
numbers. Maybe we want to add this somewhere, or we have a common
understanding that all devices have a good enough entropy source.

> to be warned and want to stay far, far away from such devices.

And still such devices might exist if we don't exclude their use in MANETs.

> but it would help us if you do.

For security purposes, evidently the requirements for PRNs are very high. I
admit that I am not an expert on PRNs, so I cannot tell you much. I will try
to ask our cryptographers in the department, hopefully they can enlighten
this issue.
To my knowledge, there are sufficiently good PRNs (even for small embedded
devices), but they depend on very good entropy sources. So when specifying,
say, a security extension to a MANET routing protocol, that document should
probably mention some requirements of the entropy source and the PRN.

Ulrich

> good

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 28 Oct 2009 14:22:45 +0100

Ulrich Herberg a écrit :
> Hi Teco,
> 
> On Wed, Oct 28, 2009 at 1:13 PM, Teco Boot <[email-masked] 
> font), is it readable? If not, I can also change to plain text for 
> future mails.

Ulrich - I see your mails are in variable-size font format, including 
this one. (and not fixed-font like Courrier).  Also, I see a strange "|" 
citation sign instead of the usual ">".  This makes me incapable of 
properly citing your messages.

Now, looking at the source code of your messages it seems that you use 
MIME and:
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable

Not using MIME at all would help (although there may be 
Transfer-Encoding schemes other than quoted-printable which may allow to 
still use MIME yet not have this problem)

Could you please try to fix this?  (I can help) - it should happen via 
the list, though.

Alex

> question is: can we _always_ assume that it is good enough (or 
> accessible to the device)? Is there an RFC that claims something like: 
> "All devices that are used in a MANET MUST be able to provide a 
> sufficiently good entropy source". (for whatever meaning of "sufficient")
> 
> For security purposes, evidently the requirements for PRNs are very 
> high. I admit that I am not an expert on PRNs, so I cannot tell you 
> much. I will try to ask our cryptographers in the department, hopefully 
> they can enlighten this issue.
> To my knowledge, there are sufficiently good PRNs (even for small 
> embedded devices), but they depend on very good entropy sources. So when 
> specifying, say, a security extension to a MANET routing protocol, that 
> document should probably mention some requirements of the entropy source 
> and the PRN.
> 
> 
> Ulrich
> 
>  
> 
> 
> 
>     Regards, Teco
> 
> 
> 
> 
> 
>     Van: Ulrich Herberg [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     CC: Teco Boot; [email-masked] <mailto:[email-masked]>
>     generator
>     memory, good
>     "there
>     source?

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 28 Oct 2009 14:27:07 +0100

Hi Ulrich,

Van: Ulrich Herberg [mailto:[email-masked]] 
Verzonden: woensdag 28 oktober 2009 14:07
Aan: Teco Boot
CC: [email-masked]
Onderwerp: Re: [Autoconf] I-D
Action:draft-bernardos-autoconf-addressing-model-00.txt

Hi Teco,

Few things.

I did not realize that. If I just answer like now (without changing the
font), is it readable? If not, I can also change to plain text for future
mails.
T: Please use ascii and > prefix character 

I hope so :-)
 
We have a radio, right?

yes

yes

Yes, I am aware that a radio can be good enough as entropy source. The
question is: can we _always_ assume that it is good enough (or accessible to
the device)? Is there an RFC that claims something like: "All devices that
are used in a MANET MUST be able to provide a sufficiently good entropy
source". (for whatever meaning of "sufficient")
T: No-one ever claimed a protocol works in all cases. I have MANET products
nearby that cannot support OLSR. Or Java. Do I discourage those??

Because, if we don't have that, I am not sure we can rely on good random
numbers.
T: If PRN is good, we can rely. Why not?

Maybe we want to add this somewhere, or we have a common understanding that
all devices have a good enough entropy source.
T: Not again the "all". And yes, I say a radio is typically a pretty good
entropy source. So we are lucky this time.

For security purposes, evidently the requirements for PRNs are very high. I
admit that I am not an expert on PRNs, so I cannot tell you much. I will try
to ask our cryptographers in the department, hopefully they can enlighten
this issue.
To my knowledge, there are sufficiently good PRNs (even for small embedded
devices), but they depend on very good entropy sources. So when specifying,
say, a security extension to a MANET routing protocol, that document should
probably mention some requirements of the entropy source and the PRN.
T: I'm pretty sure your cryptographers will tell you that if the radio /
demodulator ADC provides digitized thermal noise, and the implementation for
getting a PRN is OK, you are done. But I can tell you key generation is a
somewhat dark area. Extreme highly unique address generation in open
standards is doable.

Regards, Teco

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 28 Oct 2009 14:27:57 +0100

Alex,

I use the Google mail interface (I know, now you can blame me for
trusting Google my mails ;-)
This email is written in plain text. Better now? Otherwise, I can also
try to use Thunderbird, the Mac mail program etc for mails to IETF
lists.

Ulrich

On Wed, Oct 28, 2009 at 2:22 PM, Alexandru Petrescu
<[email-masked]> wrote:
>
> Ulrich Herberg a écrit :
>>
>> Hi Teco,
>>
>> On Wed, Oct 28, 2009 at 1:13 PM, Teco Boot <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>    Hi Ulrich,
>>
>>    Few things.
>>
>> I did not realize that. If I just answer like now (without changing the font), is it readable? If not, I can also change to plain text for future mails.
>
> Ulrich - I see your mails are in variable-size font format, including this one. (and not fixed-font like Courrier).  Also, I see a strange "|" citation sign instead of the usual ">".  This makes me incapable of properly citing your messages.
>
> Now, looking at the source code of your messages it seems that you use MIME and:
>>
> Not using MIME at all would help (although there may be Transfer-Encoding schemes other than quoted-printable which may allow to still use MIME yet not have this problem)
>
> Could you please try to fix this?  (I can help) - it should happen via the list, though.
>
> Alex
>
>
>>
>>
>> Yes, I am aware that a radio can be good enough as entropy source. The question is: can we _always_ assume that it is good enough (or accessible to the device)? Is there an RFC that claims something like: "All devices that are used in a MANET MUST be able to provide a sufficiently good entropy source". (for whatever meaning of "sufficient")
>>
>> Because, if we don't have that, I am not sure we can rely on good random numbers. Maybe we want to add this somewhere, or we have a common understanding that all devices have a good enough entropy source.
>>
>>
>> For security purposes, evidently the requirements for PRNs are very high. I admit that I am not an expert on PRNs, so I cannot tell you much. I will try to ask our cryptographers in the department, hopefully they can enlighten this issue.
>> To my knowledge, there are sufficiently good PRNs (even for small embedded devices), but they depend on very good entropy sources. So when specifying, say, a security extension to a MANET routing protocol, that document should probably mention some requirements of the entropy source and the PRN.
>>
>>
>> Ulrich
>>
>>
>>
>>
>>    Regards, Teco
>>
>>
>>
>>
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 28 Oct 2009 15:25:42 +0100

> try to use Thunderbird, the Mac mail program etc for mails to IETF

Yes Ulrich, this is much better, thank you.  I believe in this way we 
can better understand each other, easier to cite text and follow discussion.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 28 Oct 2009 08:56:02 -0700

Hello Teco,

> Still waiting on answers on DHCP DUID, key generation etc.

Your wait is over, at least
for my answer.

- DHCP DUID isn't going to help if you don't already have DHCP.
  My strong recommendation, for scalability and robustness, would
  be to avoid any requirement for DHCP.

- For key distribution, you didn't like my long key?  Why not?
   Well then, pick a shorter one.  It becomes a matter of engineering.

- For "etc." -- I don't think there were any other open issues
   in my queue.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 28 Oct 2009 09:02:06 -0700

Hello Alex,

>  randomness when sampling the temperature, for example - that RFC says).

Maybe it is time for an "Errata" for the RFC?  Of course
it depends on the temperature sensitivity of, say, the
accelerometer or moisture sensor.

And if there are people who are only interested in
solutions utilizing such randomizations, maybe they should
first propose a new look at the entire IPv6 protocol
design for address uniqueness.  Maybe the state of the
are has progressed sufficiently that the previous discussions
have lost some of their validity.

In the meantime, can we go forward here?

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 28 Oct 2009 17:14:20 +0100

Hi Charlie,

>  be to avoid any requirement for DHCP.

I guess you understand my point very well. There are IETF protocols that
assume nodes have a unique ID, and there was no discussion on getting the
id that I can remember. But I was not there, I assume.

I hope your recommendation applies only for MANETs.

I think DHCP can be very useful for attached MANETs, for getting
"additional information", i.e. other than addresses.

>   Well then, pick a shorter one.  It becomes a matter of engineering.

Some do not like pre-shared keys.
And if it was a private, a good PRN can be generated very easily.
Or just pre-load a guaranteed unique global address.

Regards, Teco

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 28 Oct 2009 09:33:40 -0700

Hello Teco,

> I hope your recommendation applies only for MANETs.

Yes.  Obviously DHCP has a strong role in the administration
of fixed networks and even infrastructure-based networks with
mobile nodes.

> "additional information", i.e. other than addresses.

I agree.  I just don't think it fits very well in networks composed
of highly mobile wireless nodes, especially when the network has
no point of attachment to the Internet.

> Or just pre-load a guaranteed unique global address.

The latter choice makes the whole discussion moot,
but of course when that is available I think it is the right
thing to do.

Regards,
Charlie P.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 Oct 2009 11:33:28 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles E. Perkins
> Sent: Wednesday, October 28, 2009 9:34 AM
> To: Teco Boot
> Cc: [email-masked]
> Subject: Re: [Autoconf] answers on DHCP DUID, key generation etc.
> 
> 
> Hello Teco,
> 
> Teco Boot wrote:
> > Hi Charlie,
> >
> >

DHCP is for enterprise networks in which there is some
modicum of distributed network administration and a
commonality of interests (which may be as basic as the
collaborative provisioning of connectivity itself). This
model fits well not only with infrastructure-based
networks but also with many MANET scenarios with which
I am familiar. 
 
> no point of attachment to the Internet.

Like maybe me and a couple of buddies going to a remote
ski area with hand-held multi-hop walkie-talkies when
there is no cellular coverage? Even then, unless we all
get together beforehand and key our L2 access codes what
we get is "anarchy-net", and anyone can crash the party.

> but of course when that is available I think it is the right

This brings up again a point which I have made in the past 
that this group could significantly benefit from a detailed
MANET use-case analysis before saying what the addressing
architecture for *all* MANETs ought to look like.

Fred

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 28 Oct 2009 12:07:05 -0700

Hello Fred,

Comments below...

> networks but also with many MANET scenarios with which

I agree there are wireless mobile networks that support
DHCP.  It's nicer, however, when the server and the relays
have stable availability and connectivity.

> we get is "anarchy-net", and anyone can crash the party.

As you know, even enterprise DHCP had security problems
for a really long time.

There are many flavors of ad hoc networks between the ski-slope
anarchy-net and the attached wireless stubs most conducive
to supporting DHCP.  My main point is that we can't just wave
the DHCP wand and declare mission accomplished.

But as an interesting point of distraction, consider: (a) mutual
face-to-face setup of security association (cellphones are cool)
and (b) terabytes of storage in your snowboard.

> architecture for *all* MANETs ought to look like.

But nobody is doing that, Fred.  Right now we have just about
the most minimalistic document you could imagine.  Other more
specialized applications should be derivable from the general model
hypothesizing appropriate characterizations for the more specialized
model.

For instance, if we have a system that works when there aren't
any guaranteed unique MAC addresses, then that system CAN
be specialized to the case of unique MAC addresses.

The other way around, is often impossible.  It is unlikely that you
would be able to generalize a guaranteed-unique MAC address
solution to fit the needs of systems that do not guarantee such uniqueness.

Frankly, I think this should be considered very obvious.
Too bad we've been bogged down for years now explaining
it over and over again.  It's like claiming that we cannot
go about designing solutions for x+y = 4 because a lot of
times x is equal to 0.

Regards,
Charlie P.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 Oct 2009 12:24:02 -0700

Charlie,

> But nobody is doing that, Fred.

Use case documents aren't all that hard to write; in
fact, here is one now:

http://tools.ietf.org/html/draft-russert-rangers-01

Fred