Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal.

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 1 Jul 2010 10:02:55 +0100

Charles Perkins
> I'd be happy if it were possible for [autoconf] to
> be allowed to consider the excellent body of work that
> was seen already years ago -- the same body of work
> that motivated me and others to create and spend a lot
> of time over the last years and years.

If Charlie can find a few like-minded people to work on
that, why not add this as a parallel activity? The
rationale of why two cases should be straightforward to
make, they are almost chalk and cheese in e.g. centralised
versus non-centralised. This is actually added safety to
the group producing something, as if one succeeds and the
other fails, that's still good.

Unfortunately, I can't offer to be one of those people.
Although I should be able to contribute at the read and
comment level, more than that is needed. I only didn't
make the suggestion earlier as it needs people (with
all due respect to Charlie, plural) to do the work.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

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

---

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 1 Jul 2010 11:28:15 +0200

> other fails, that's still good.

I also think this parallel approach could be appropriate too.

> all due respect to Charlie, plural) to do the work.

I'd be happy to help out on the matter. So I guess we have a plural +
contributors ;)

cheers,

Emmanuel

---

From: Teco Boot <[email-masked]>
Date: Fri, 2 Jul 2010 09:36:20 +0200

Zach Shelby:
> There the approach is to enable autoconfiguration with either DHCP or using a multihop DAD technique. 

RFC 3315: client SHOULD perform DAD, so I would not say "or".
I prefer the draft charter text, where DAD is out of scope for now. 

Draft charter text:
>  No new duplicate address detection mechanisms are will be specified as a part of the first item; it is expected that address uniqueness is guaranteed by the central node alone.

Central node duplicate avoidance may be based on globally-unique identifiers on all nodes, such as DHCPv6 DUID.
Let's define our assumption here, to avoid looped discussions.
We assume all nodes have guaranteed globally unique identifiers on forehand, either link-layer addresses or vendor assigned identifiers.
Otherwise, using DHCPv6 is questionable.

Teco.

---

From: Zach Shelby <[email-masked]>
Date: Fri, 2 Jul 2010 11:04:40 +0300

Hi Teco,

> I prefer the draft charter text, where DAD is out of scope for now. 

Ahh, I wasn't suggesting that you do that in Autoconf. Just some background info on the solution in 6LoWPAN. There DAD is also not performed on EUI-64 based addresses. Over there the situation is different as there are sometimes 16-bit short MAC addresses to deal with which require either DHCPv6 or random generation with DAD to use.

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Henning Rogge <[email-masked]>
Date: Fri, 2 Jul 2010 10:10:24 +0200

On Tue June 29 2010 06:20:28 Ryuji Wakikawa wrote:
> Hi all,
> 
> Please find a proposal of a new AUTOCONF charter attached below.
> We need to define our new charter carefully to avoid yet-another 5 years
> discussion. Jari and chairs agreed to narrow down the charter items and go
> straight to solution space.
Just as a general comment, I think it would be a mistake to put DHCPv6 
directly into the charter, even if we decide to go for a centralized sollution 
first.

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-961,   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: "Holtzer, A.C.G. (Arjen)" <[email-masked]>
Date: Fri, 2 Jul 2010 15:21:51 +0200

Hello autoconfers,

I support this "two-case"-approach, Christopher mentions: so
standardizing one centralized and one decentralized solution (or one
stateful and one stateless solution, just like in the current IPv6
standards). I agree that the solution should make use of existing
protocols as much as possible (e.g. DHCP, ND, ...), but my choice would
be not to state in the charter that DHCP must be used in all solutions
coming out of the WG.

draft-bernardos-manet-autoconf-survey-05 shows there are already many
proposals existing, making it a good starting point for going into
solution space. Actually even more than just a starting point since many
of the proposals have already been around for a while. So I support this
doc.

Best regards,
Arjen

> 
> If Charlie can find a few like-minded people to work on that, 
> why not add this as a parallel activity? The rationale of why 
> two cases should be straightforward to make, they are almost 
> chalk and cheese in e.g. centralised versus non-centralised. 
> This is actually added safety to the group producing 
> something, as if one succeeds and the other fails, that's still good.
> 
> 
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 02 Jul 2010 09:41:07 -0700

Hello Emmanuel and all,

Thanks for supporting the consideration
of decentralized approach.  I'm pretty
sure we could get at least one good
working solution in time a lot faster
than it took to agree that not everything
is an Ethernet.

However, it's important to avoid making
a sharp dichotomy between "centralized"
and "decentralized" approaches.  My big
concern was that somehow the DHCP model
was going to be considered the only viable
choice because people (outsiders?) consider
it to be the only known quantity.  There are
other ways to have more centralized or less
centralized procedures, with or without
proxy assistance, perhaps hybridized
approaches, and with improved availability
via elections.

Those are just a few of the options, and
probably all of them are way better than
trying to shoehorn DHCP where it does not
seem to fit.  Flushing years of development
and wisdom down the toilet just because
they doesn't spell DHCP seems really wrong
to me.

Another point to keep in mind -- DHCP was
designed and built from day one to be a
_managed_ solution for autoconfiguration.
It seems quite clear to me that most of the
interesting development and inspiration for
ad hoc networks has gone towards enabling
networking in environments where no such
tightly managed administration is possible.
Thus, in my view, DHCP almost tautologically
disqualifies itself from consideration
without major structural redesign.  How is
it, then, that DHCP keeps cropping up in
the discussion?

Regards,
Charlie P.

On 7/1/2010 2:28 AM, Emmanuel Baccelli wrote:
>
>
> On Thu, Jul 1, 2010 at 11:02 AM, Dearlove, Christopher (UK)
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Charles Perkins
> _______________________________________________
> Autoconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/autoconf

---

From: Teco Boot <[email-masked]>
Date: Sat, 3 Jul 2010 09:13:54 +0200

Charlie,

Are you in for DHCP for getting prefixes (and other parameters),
for ad hoc networks connected to the Internet (or other managed
fixed network)?

If so, the discussion is on addresses only. We have to deal with
bootstrapping, i.e. first step in autoconf getting a routable
address and the address of a DHCP server. After this, we are done.

IMHO multi-hop signaling between address-less DHCP-client and unknown
DHCP-server is a bad idea. Both are needed for smooth operation.

Teco.

---

From: Mark Townsley <[email-masked]>
Date: Fri, 02 Jul 2010 20:59:14 +0200

My kneejerk reaction to this is that walking in with the goal of having
more than one way to autoconfigure a manet is a bad idea.

If we end up with two ways to autoconfigure, then we will have to invent
an automatic mechanism on top to choose which autoconfiguration
mechanism to use.  That doesn't help anyone. In absence of knowledgeable
human configuration, hard choices that narrow functional options
typically far outweigh the potential benefits of one option vs. the
other. So, even if you can prove that A is better than B, B is still
better than A+B.

Let's strive for making a choice, at least within the MANET domain.

- Mark

---

From: Teco Boot <[email-masked]>
Date: Sat, 3 Jul 2010 09:57:12 +0200

Easy to invent the automatic mechanism:
Only need an address? Use ND.
Need more? use ND for getting address, find central server, get more.

Teco.

---

From: Emmanuel Baccelli <[email-masked]>
Date: Sat, 3 Jul 2010 12:17:59 +0200

Hi Charlie,

I agree with you about trying to avoid the dichotomy
centralized/decentralized. If some people want to work on a DHCP-dependent
solution, let them try. If some other people want to work in parallel on a
DHCP-independent solution, why not let them do it too?

In my mind, these two solutions could be pretty complementary.

Emmanuel

---

From: Mark Townsley <[email-masked]>
Date: Sun, 04 Jul 2010 23:17:50 +0200

> Need more? use ND for getting address, find central server, get more.

OK, as described that's still one mechanism per type of information. So,
where does the DNS server address go ;-)

- Mark

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 5 Jul 2010 10:13:18 +0100

I'm still trying to work out how step one works. ND, out of
the box, designed for hosts on non-multi-hop Ethernets
won't give you a MANET-wide unique address. You might even
find someone else with the same address as you on your only
route to the server. Or is there some development of ND
that I have overlooked?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Teco Boot
Sent: 03 July 2010 08:57
To: Mark Townsley
Cc: [email-masked]
Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter
proposal.

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 5 Jul 2010 10:23:42 +0100

I'm going to disagree with that, because there are fundamentally
different requirements - not all MANETs are the same. The
proposed solution in the current draft charter is a single
DHCP server. Putting aside the technical issues in getting that
to work that Charlie and others have pointed out, let's suppose
it can be made to work. But there are several of us whose areas
of interest, and scenarios within that area of interest, would
regard such a single point of failure (or takeover) as not a good
solution. Of course just having a decentralised solution would
not necessarily be sufficient either, hence the comments I've
made about security issues up front. I don't yet know if a
solution that does all I would want it to do exists.

As for how to choose, if one solution is unacceptable, then the
network would clearly be using the other. More generally it's
far from the only administratively configured issue in a MANET
- which routing protocol for example (which also applies in the
fixed Internet, nothing new there).

But perhaps, rather than jumping straight in with one, or even
two, approaches, we need people to indicate what they actually
want/need, and whether the proposal in the draft charter, or
an alternative (the latter having the disadvantage of being
quite vague at this point) would give them what they need.

-----Original Message-----
Behalf Of Mark Townsley
Sent: 02 July 2010 19:59
To: [email-masked]

                    *** WARNING ***

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Mon, 05 Jul 2010 12:23:32 +0200

On 7/5/10 11:23 AM, Dearlove, Christopher (UK) wrote:
> different requirements - not all MANETs are the same. 

Is there a naming convention for all the different MANET types? How do
you tell them apart?

> The

I think of autoconfig as being part of a very basic bootstrapping
procedure. If any one thing needs to be ubiquitous, it's this. After the
device has reached a certain level of configuration and connectivity, it
is more possible to negotiate options and report on mismatches. On the
other hand, if basic bootstrapping fails, then all you may have to
troubleshoot with is a dead device.

> quite vague at this point) would give them what they need.

Certainly putting a scope around that which must be automatically
configured and that which may not would be helpful here.

- Mark

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 5 Jul 2010 11:42:16 +0100

I think asking for a naming convention is missing the point.
It's an issue of requirements. I don't have a name for "sorry,
I can't just use a single DHCP server as someone hostile might
put it out of action".

For the issue of ubiquity, we don't have a single means of
obtaining an IP address in the rest of the Internet, not even
the two of fixed and dynamic.

-----Original Message-----
From: Mark Townsley [mailto:[email-masked]] 
Sent: 05 July 2010 11:24
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter
proposal.

                    *** WARNING ***

- Mark

---

From: Cedric Adjih <[email-masked]>
Date: Mon, 05 Jul 2010 13:25:49 +0200

Hello all,

Sorry to jump in this thread, but I concur with Christopher, and some 
other participants of the working group.

In my opinion, a decentralized solution to autoconfiguration would be 
preferable.

Having worked on MANET autoconfiguration for the French MoD (with 
specification, implementation, and experiments), centralized protocols 
seem to have more drawbacks for tactical networks, such as resilience to 
nodes taken out of combat as Chris. said, and also miscellaneous 
scenarios of network splitting/merging.

-- Cedric

---

From: Teco Boot <[email-masked]>
Date: Mon, 5 Jul 2010 13:54:46 +0200

What happens with duplicate DUIDs?
If they don't exist, why would self-generated duplicate addresses occur?

On the two-step approach, I can think of using the ND address temporally, and
get more info from DHCP, including a "better" address. This address would 
be topologically correct in case of border routers and would better fit 
for packetbb compression.

Teco.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 06 Jul 2010 17:30:58 +0200

Hi Emmanuel,

Le 03/07/2010 12:17, Emmanuel Baccelli a écrit :
> centralized/decentralized.

I agree to try to avoid the dichotomy centralized-decentralized because
DHCP has already many features exhibiting decentralization:

-DHCPv6 dst address is multicast: several servers can be in that group.
-several DHCP Servers running on the the same address with VRRP.
-Several Relays per a DHCP Server.
-DHCP Reconfigure message to let a Server suggest a Client another
  Server.
-RA tell the Node there's a better DHCP Server available.
-there are surely more.

> If some people want to work on a DHCP-dependent solution, let them
> try. If some other people want to work in parallel on a

I don't know, it's too simply put.  I'd evaluate the work quantity
needed for each, and prefer reuse.

Alex

> On Fri, Jul 2, 2010 at 6:41 PM, Charles E. Perkins
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Hello Emmanuel and all,
>
> Thanks for supporting the consideration of decentralized approach.
> I'm pretty sure we could get at least one good working solution in
> time a lot faster than it took to agree that not everything is an
> Ethernet.
>
> However, it's important to avoid making a sharp dichotomy between
> "centralized" and "decentralized" approaches.  My big concern was
> that somehow the DHCP model was going to be considered the only
> viable choice because people (outsiders?) consider it to be the only
>  known quantity.  There are other ways to have more centralized or
> less centralized procedures, with or without proxy assistance,
> perhaps hybridized approaches, and with improved availability via
> elections.
>
> Those are just a few of the options, and probably all of them are way
> better than trying to shoehorn DHCP where it does not seem to fit.
> Flushing years of development and wisdom down the toilet just because
> they doesn't spell DHCP seems really wrong to me.
>
> Another point to keep in mind -- DHCP was designed and built from day
> one to be a _managed_ solution for autoconfiguration. It seems quite
> clear to me that most of the interesting development and inspiration
> for ad hoc networks has gone towards enabling networking in
> environments where no such tightly managed administration is
> possible. Thus, in my view, DHCP almost tautologically disqualifies
> itself from consideration without major structural redesign.  How is
> it, then, that DHCP keeps cropping up in the discussion?
>
> Regards, Charlie P.
>
>
>
>
> <[email-masked]
> <mailto:[email-masked]>
> <mailto:[email-masked]
> <mailto:[email-masked]>>>
>
> wrote:
>
> Charles Perkins
>> I'd be happy if it were possible for [autoconf] to be allowed to
>> consider the excellent body of work that was seen already years ago
>> -- the same body of work that motivated me and others to create and
>> spend a lot of time over the last years and years.
>
> If Charlie can find a few like-minded people to work on that, why not
> add this as a parallel activity? The rationale of why two cases
> should be straightforward to make, they are almost chalk and cheese
> in e.g. centralised versus non-centralised. This is actually added
> safety to the group producing something, as if one succeeds and the
> Unfortunately, I can't offer to be one of those people. Although I
> should be able to contribute at the read and comment level, more than
> that is needed. I only didn't make the suggestion earlier as it needs
> people (with all due respect to Charlie, plural) to do the work.
>
>
>
> I'd be happy to help out on the matter. So I guess we have a plural
> + contributors ;)
>
> cheers,
>
> Emmanuel
>
>
>
> _______________________________________________ Autoconf mailing
> list [email-masked] <mailto:[email-masked]>
> _______________________________________________ Autoconf mailing
> list [email-masked]