Subject: [Autoconf] (no subject)

From: [email-masked]
Date: Tue, 22 Sep 2009 10:32:33 +0200 (CEST)

Hi Charlie,

|PS. Again, for the nth time, I am not against link locals.
|       I am against mandating their use, and I am against
|       requiring all solutions to resolve the issues surrounding
|       the assignment of link-local addresses.

I think this is completely in line with my "adjusted" text for the
addressing model document.
So why not include this, and go to the next steps? We have two more open
issues.

|Here are four nodes at time T_0:
|
|                      A --------- B --------- C --------- D
|
|The dashed lines indicate neighborliness at time T_0.
|Assume all bidirectional links.
|
|At time T_1, a second later, the neighborhoods
|are as follows:
|
|                      A --------- C --------- B --------- D
|
|Please explain how you identify the links upon which
|your assignment of link-local addresses are valid,

Link-locals are on-link by definition, and are not forwarded.
LL_A is not seen of C-B and B-D, although if it was, it is valid.

| and
|indicate a compatible assignment of link local addresses,

EUI-64 is one mechanism, especially useful when there is a globally
unique MAC address available. Any unique MAC address on the box
will do.
Another practical approach is using random interface-id and accept
an almost zero chance on a duplicate. One may come up with a
multi-hop DAD.

|and indicate which specs provide you with the protocol
|mechanism for carrying out the proposed assignment.

BRDP is just an example.

|How many links are there in your model of this network?

No limit.

|Do you think your link definition is the only one that should
|be considered valid for work in [autoconf]?

I don't think there is a need to pay so much attention
on link definition. We just need to specify what is
intended. For example, it is clear that with link metrics
we assign a metric to a link between two nodes ("edge"
in relation theory). And the RFC5498 link-local is
one hop away.

I think sub-IP MANETs are out-of-scope for [Autoconf],
as current autoconf mechanisms can be used.

|Narten's answer was "unique MAC-layer addresses".
|Do you agree with that?

Fully agreed.
But I don't think Narten excludes other unique / almost
unique interface-ids.

|  Do you think we should restrict
|work in [autoconf] to be applicable only to such networks
|in which that restriction is valid?

I think [autoconf] should focus on IPv6, and work on a
mechanism that is independent of a MANET routing protocol.

Also, the mechanism shall stay in line with current IETF standards
as much as possible. This implies "link-locals are always there" and
used by for example RA and OSPF-MANET. I don't see a reason why
DYMO won't send messages with link-locals. And there is some
progress on NHDP / OLSR for support of link-locals.

|Do you have any intuition about the scalability of the
|system resulting from your definitions?

With 48-bit MAC addresses, IEEE has address space of 46^2-1.
With random, we have 62^2-1. Even with large or huge MANETs,
the chance on duplicates is almost zero.

|What if you discovered that your definitions resulted in a
|system that was three orders of magnitude less scalable than
|an alternative that did not impose a requirement for assigning
|unique link-local addresses? -- or, a system that, effectively,
|didn't even define any broadcast-oriented links at all?

BRDP provides a mechanism that connects all MANETs on this
globe via the Internet without any problems. Do you need three
orders of magnitude more?

Teco.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 22 Sep 2009 12:56:55 +0200

> the chance on duplicates is almost zero.
This depends on the quality of the random number generator. Especially during 
initialization it's difficult for embedded devices without a unique seed to 
get good random numbers.

Think a manet after a power outage in a city. Most devices boot during the 
same time (when power is back again).

Henning Rogge

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

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 22 Sep 2009 13:39:11 +0200

Hi,

> same time (when power is back again).

I agree with Henning. It is not good enough to assume unique MAC addresses
or good random number generators. I think that this is the reason why DAD is
required in RFC4862. In such a case mentioned by Henning, devices could
indeed use the same seed for the random number generator and create the same
addresses.

Coming back to Charlie's mail, I think he mentioned two important facts:
   -- The proposed addressing model in the draft works in all cases; no-one
so far did show that it would break things.
   -- Requiring link-models have some severe problems, as mentioned in the
text by Erik that will be integrated in the next revision of the draft.
No-one of the proponents of link-locals has answered how to circumvent these
problems (e.g. how to assure uniqueness at all time over several hops in a
mobile scenario). Repeating Charlie, the draft does NOT prohibit the use of
link-locals. It simply does not _require_ such an address.

Ulrich

---

From: Henning Rogge <[email-masked]>
Date: Tue, 22 Sep 2009 13:42:56 +0200

On Tue, Sep 22, 2009 at 13:39, Ulrich Herberg
<[email-masked]> wrote:
> Hi,
>
> On Tue, Sep 22, 2009 at 12:56 PM, Henning Rogge
> <[email-masked]> wrote:
>>
Unique MAC addresses are good enough... random number generator is not.

Henning Rogge

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 22 Sep 2009 10:39:49 -0700

Hello Teco,

Thanks for your explanations. 

> So why not include this, and go to the next steps? We have two more open

I'm not the right person to answer this question :-)

> LL_A is not seen of C-B and B-D,

Check.

> although if it was, it is valid.
>   

I am skeptical about this UNLESS you are already assuming some
scheme like EUI-64 derived link-local addresses, as you mention
shortly below.

> an almost zero chance on a duplicate.

In the past, some random number generators have been "bad",
to use the technical nomenclature.  Perhaps you would like to
make it illegal by international law to enable user-selectable MAC
addresses.

> One may come up with a

Indeed.  This is, in fact, my favored approach -- and
I don't restrict it to ensuring uniqueness only for link-local
addresses.

> |mechanism for carrying out the proposed assignment.

Time to re-read that.

> |How many links are there in your model of this network?

I don't see how, given the connectivity as indicated in
the stick figures.  Can you say more?

> as current autoconf mechanisms can be used.

I was almost agreeing with you, but... what _are_ the
"current" autoconf mechanisms?  Do you mean the
current IPv6 autoconfiguration mechanisms?

> But I don't think Narten excludes other unique / almost

Does this mean that your proposed mechanisms are
applicable only when there are such interface-ids available?

> mechanism that is independent of a MANET routing protocol.

I don't think anyone is disputing this.

> as much as possible.
Check.

>  This implies "link-locals are always there" and
> used by for example RA and OSPF-MANET.

I don't agree that the implication is necessary.  However, I would
agree that it is quite compatible with residence in the universe where
MAC addresses are already known to be unique or astronomically
randomized.

>  I don't see a reason why
> DYMO won't send messages with link-locals.

That one I can answer.  It's because link-locals (almost by definition)
do not contain any information useful for the purposes of DYMO
(i.e., creating routes to destination IP addresses).

>  And there is some

I've already given up on registering further objections to NHDP.
We love big packets, yes we do.  Silly to complain when we are
already assuming big layer-2 headers... we do, don't we?

> the chance on duplicates is almost zero.

Putting aside the birthday paradox, this still only pertains to residence
in the nice universe of nodes that conform to your expectations of either
randomness or uniqueness.

> orders of magnitude more?

Is there any appendix describing the solution to world hunger?

More seriously, extraordinary claims demand extraordinary proof
and invite extraordinary skepticism.  Put another way, I need to
study BRDP to discover what must be a large difference in the
way we mutually view MANETs.

Regards,
Charlie P.

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 22 Sep 2009 20:10:17 +0200

On Tue, Sep 22, 2009 at 1:42 PM, Henning Rogge <[email-masked]>wrote:

> [...]
> Unique MAC addresses are good enough...[...]
>

Yes, *if* they are unique. But this cannot always be asumed.

Ulrich

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 23 Sep 2009 13:43:26 -0700

Hello Teco,

[email-masked] wrote:
> ...

BRDP is, if you'll pardon my simplification, a souped-up version
of Router Advertisement.  So, it isn't designed at all for autonomous
MANETs.

It is not clear from what you said how BRDP can begin to solve the
problem that I outlined whereby four nodes cooperate to form a highly
mobile network.

If I was challenged to make a solution to the problem using BRDP,
I would do so by nominating a distinguished node to define a routing
tree for the network.  On average, the pathlengths would be
reasonable, and the node beaconing BRDP messages would
be the root of the tree.  Disregard for now the difficulty that
BRDP is only specified for networks connected to the Internet.

This model of operation is workable, but it suffers from the obvious
problems of robustness (what if the root wanders away) and selection
of the distinguished node (what if there are multiple contenders).
But this is all speculation -- you may not even desire to offer BRDP
as a solution which might be applicable in the general case.

> orders of magnitude more?

Clearly, BRDP does _not_ connect all MANETs on the globe,
if some are disconnected.  Plus, it is not a property of BRDP that
connects a multiplicity of MANETs.  It is a property of the Internet,
which would be the same whether BRDP or any other gateway
protocol were to be put into service.

Regards,
Charlie P.