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

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 28 Jun 2010 21:20:28 -0700

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. 

This charter is not the final version. Please review it and provide us your comments.  
The discussion before the coming IETF is very important to set our charter ready soon.

Please give us your feedback before July 9th. 

thanks,
ryuji

Ad-Hoc Network Autoconfiguration (autoconf)
-------------------------------------------

Current Status: Active

Chairs:
Ryuji Wakikawa <[email-masked]>
Thomas Clausen <[email-masked]>

Internet Area Directors:
Ralph Droms <[email-masked]>
Jari Arkko <[email-masked]>

Internet Area Advisor:
Jari Arkko <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf
Archive: http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html

Description of Working Group:

RFC 5889 presents one possible IPv6 addressing model for ad hoc nodes. In this model the ad hoc routers need to configure their network interface(s) with addresses valid in the ad hoc network, and may configure additional prefixes for use by attached nodes.

After completing the work on RFC 5889, the main purpose of the AUTOCONF WG is to standardize how existing IPv6 address configuration tools can be used for address configuration:

1. A DHCPv6-based mechanism for configuring required interface addresses for the routers in the ad hoc network. This mechanism is expected to produce addresses with properties outlined in RFC 5889. This mechanism uses the existing DHCPv6 protocol unchanged, and assumes a central node that can allocate addresses on a first-come-first-served basis. Other nodes in the ad hoc network will relay messages to the central node in order to help a new node get an address for itself. This mechanism is only suitable for deployments were a central node can be set up. It should be noted that many existing deployments employ Internet gateways that can act as such a central node as well. Future extensions such as central node election may make this mechanism suitable for also for stand-alone ad hoc networks.

2. A DHCPv6-based mechanism for delegating a prefix(es) to each router for use by applications running on the routers themselves, or for configuration of attached hosts/networks. This mechanism works in a similar manner to the one above, but allocates prefixes instead of addresses.

Both mechanisms should be independent on operation of any specific MANET routing protocol, although may exploit information maintained by such a routing protocol, if available.

The working group will adapt and/or reuse existing protocols whenever reasonable and possible. 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.

Goals and Milestones:

Dec 2010 First working group draft of the address configuration mechanism
Apr 2011 First working group draft of the prefix configuration mechanism
Sep 2011 Submission of the address configuration mechanism to the IESG for publication as a Proposed Standard
Sep 2011 Submission of the prefix configuration mechanism to the IESG for publication as a Proposed Standard

---

From: Henning Rogge <[email-masked]>
Date: Tue, 29 Jun 2010 08:03:28 +0200

On Tue June 29 2010 06:20:28 Ryuji Wakikawa wrote:
> RFC 5889 presents one possible IPv6 addressing model for ad hoc nodes. In
> this model the ad hoc routers need to configure their network interface(s)
> with addresses valid in the ad hoc network, and may configure additional
> prefixes for use by attached nodes.
> 
> After completing the work on RFC 5889, the main purpose of the AUTOCONF WG
> is to standardize how existing IPv6 address configuration tools can be
> used for address configuration:
> 
> 1. A DHCPv6-based mechanism for configuring required interface addresses
> for the routers in the ad hoc network. This mechanism is expected to
> produce addresses with properties outlined in RFC 5889. This mechanism
> uses the existing DHCPv6 protocol unchanged, and assumes a central node
> that can allocate addresses on a first-come-first-served basis. Other
> nodes in the ad hoc network will relay messages to the central node in
> order to help a new node get an address for itself. This mechanism is only
> suitable for deployments were a central node can be set up. It should be
> noted that many existing deployments employ Internet gateways that can act
> as such a central node as well. Future extensions such as central node
> election may make this mechanism suitable for also for stand-alone ad hoc
> networks.
I don't think elections are a good way to add redundancy for an address 
configuration system. The dependency of a single node in the whole network to 
configure the addresses will be a bottleneck for larger mesh networks.

> 2. A DHCPv6-based mechanism for delegating a prefix(es) to each router for
> use by applications running on the routers themselves, or for
> configuration of attached hosts/networks. This mechanism works in a
> similar manner to the one above, but allocates prefixes instead of
> addresses.

I don't see a difference between 1 and 2, for IPv6 case 1 is just case 2 with 
a prefix length of 128 (or 64 if we use the IPv6 autoconf postfix).

--------------
Does this proposal mean the autoconf group will not work on a distributed 
address configuration scheme for mesh networks ?

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: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 29 Jun 2010 10:04:24 +0100

> address configuration scheme for mesh networks ?

Same question, except I'd stick with the terminology ad hoc network.
A centralised distribution mechanism is a very poor fit to much of
what's attractive about an ad hoc network, and a very poor fit (due
to having a single point of failure) to many application areas for
ad hoc networks.

This is not the direction I for one had hoped that the Autoconf WG
would go in. I note the reference to "future extensions", but first
I assume that this is not chartered work, and second that forces
decentralised work into a certain shape, rather than working from
the problem more generally.

I appreciate that the WG can only work on solutions that people are
prepared to work on, and unfortunately I can't offer the effort needed
to make a concrete alternative proposal. I think however I've put in
at least my share of work in the Manet WG.

Incidentally the charter refers to RFC 5889, which is not yet published.
I see that is in AUTH48, but noted as on hold for a technical issue.
AUTH48 seems rather late for a technical issue, unless meaning a
publication technical issue rather than an engineering technical issue.

********************************************************************
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: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 29 Jun 2010 13:15:32 +0200

Hi Ryuji, all,

I have some comments:

- Why are we assuming a DHCP-based solution? or a more general question:
why are we pushing for a centralized solution? I'm neutral on this at
this point, but I think it'd be good to analyze the different pros and
cons before taking such an important decision.

- Related with the former, I strongly believe that analyzing the
existing solution space is a step that would help a lot in designing a
solution. We have been working in the past on solutions surveys and
problem space analysis:

http://tools.ietf.org/html/draft-bernardos-manet-autoconf-survey-05
http://tools.ietf.org/html/draft-bernardos-autoconf-solution-space-02

I think it is worth adding an item in the charter for an informational
document that analyzes the solution space. What do people think? do you
think it is worth adding an item in the charter for this? we have
already some documents that could serve as starting point and their
authors are willing to work on this to make it progress. Would do other
people contribute to that effort (e.g., suggesting updates, reviewing
it)?

Thanks,

Carlos

On Mon, 2010-06-28 at 21:20 -0700, Ryuji Wakikawa wrote: 
> _______________________________________________
> Autoconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/autoconf

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

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 29 Jun 2010 13:15:54 +0200

> to having a single point of failure) to many application areas for

Agree.

Carlos

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 29 Jun 2010 14:34:41 +0200

> configure the addresses will be a bottleneck for larger mesh networks.

But elections is what gets rid of central node bottlenecks... if that 
single node fails then elect another.

> a prefix length of 128 (or 64 if we use the IPv6 autoconf postfix).

To my quick reading 2) does prefixes too whereas 1) does addresses only.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 29 Jun 2010 14:39:36 +0200

Le 29/06/2010 06:20, Ryuji Wakikawa a écrit :
> 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.
>
> This charter is not the final version. Please review it and provide
> us your comments. The discussion before the coming IETF is very
> important to set our charter ready soon.
>
> thanks, ryuji
> Chairs: Ryuji Wakikawa<[email-masked]> Thomas
> Clausen<[email-masked]>
>
> Internet Area Directors: Ralph Droms<[email-masked]> Jari
> Arkko<[email-masked]>
>
> Internet Area Advisor: Jari Arkko<[email-masked]>
>
> Mailing Lists: General Discussion: [email-masked] To Subscribe:
> https://www.ietf.org/mailman/listinfo/autoconf Archive:
> http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html
>
> RFC 5889 presents one possible IPv6 addressing model for ad hoc
> nodes. In this model the ad hoc routers need to configure their
> network interface(s) with addresses valid in the ad hoc network, and
> may configure additional prefixes for use by attached nodes.
>
> After completing the work on RFC 5889, the main purpose of the
> AUTOCONF WG is to standardize how existing IPv6 address
> configuration tools can be used for address configuration:
>
> 1. A DHCPv6-based mechanism for configuring required interface
> addresses for the routers in the ad hoc network. This mechanism is
> expected to produce addresses with properties outlined in RFC 5889.
> This mechanism uses the existing DHCPv6 protocol unchanged, and
> assumes a central node that can allocate addresses on a
> first-come-first-served basis. Other nodes in the ad hoc network
> will relay messages to the central node in order to help a new node
> get an address for itself. This mechanism is only suitable for
> deployments were a central node can be set up. It should be noted
> that many existing deployments employ Internet gateways that can act
> as such a central node as well. Future extensions such as central
> node election may make this mechanism suitable for also for
> stand-alone ad hoc networks.
>
> 2. A DHCPv6-based mechanism for delegating a prefix(es) to each
> router for use by applications running on the routers themselves, or
> for configuration of attached hosts/networks. This mechanism works
> in a similar manner to the one above, but allocates prefixes instead
> of addresses.

Charter proposal looks like a good basis for further discussion, I agree.

I suggest to add point "3) RA-based mechanism for exchanging existing
prefixes and updating routing tables such that paths are set up ok."

I can post an updated draft for Maastricht about a solution for this 
point 3.

For point 1) and 2) I suggest to couple the design of address assignment
to the specification of how the route state is updated when an address
or prefix has been assigned.

Alex

>
> Both mechanisms should be independent on operation of any specific
> MANET routing protocol, although may exploit information maintained
> by such a routing protocol, if available.
>
> The working group will adapt and/or reuse existing protocols
> whenever reasonable and possible. 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.
>
> Goals and Milestones:
>
> Dec 2010 First working group draft of the address configuration
> mechanism Apr 2011 First working group draft of the prefix
> configuration mechanism Sep 2011 Submission of the address
> configuration mechanism to the IESG for publication as a Proposed
> Standard Sep 2011 Submission of the prefix configuration mechanism
> to the IESG for publication as a Proposed Standard
> _______________________________________________ Autoconf mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/autoconf
>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 29 Jun 2010 14:44:15 +0200

On Tue June 29 2010 14:34:41 Alexandru Petrescu wrote:
> > configuration system. The dependency of a single node in the whole
> > network to configure the addresses will be a bottleneck for larger mesh
> > networks.
> 
Elections are a real complex thing in MANETs, better have redundancy and "no 
bottlenecks" by allowing multiple redundant address providers.
 
> > I don't see a difference between 1 and 2, for IPv6 case 1 is just case 2
> > with a prefix length of 128 (or 64 if we use the IPv6 autoconf postfix).
> 
Which make it a waste of time to develop sollution 1, because it's only a 
special case of sollution 2.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 29 Jun 2010 15:08:05 +0100

Henning
> bottlenecks" by allowing multiple redundant address providers.
 
The extreme case of which is that all nodes are address providers.

Note that I'm not however saying that is the way to go, just that
that's an option.

There is also the IPv4 vs. IPv6 issue. While the IETF would like
everything new to be IPv6, back in the real world IPv4 is currently
still more important.

-- 
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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 29 Jun 2010 23:52:11 +0300

Carlos,

> I strongly believe that analyzing the

I think a solution analysis document would be a useful output from the 
working group, particularly if we already have a good start an existing 
paper or draft. Thanks for the suggestion! I think we should add it to 
the charter.

(I'm a little reluctant to tie the completion of such a document to the 
start of solution work, however. Particularly if we can identify a 
simple first step solution such as DHCP that requires no new protocols.)

Jari

---

From: Teco Boot <[email-masked]>
Date: Tue, 29 Jun 2010 23:55:58 +0200

Ryuji, all

Thanks for the new draft charter.

I agree with other postings, that selecting DHCPv6 with a central node is not that obvious.
I think a core attribute of an ad hoc network / MANET is cooperation between equal nodes.
Especially on item 1, I am worried on dependency, election mechanisms, multi-hop (un)reachability and DHCP relay explosions. 
On the other hand, I have a solution for this. I can rename BRDP to DSDP (DHCP Server Discovery Protocol). There are other (minor) changes needed.

Using DHCPv6 for prefixes (and other parameters) makes sense to me. There are some prerequisites, like addresses / reachability and a pointer to a DHCPv6 server. 
I suggest adding "and other parameters".

On IPv4, I can think of getting an IPv4 address with DHCPv6 or "DHCP over IPv6".
Ditto for prefix and other parameters.
A charter item could be the analysis how to support IPv4 on the IPv6 solution. The result could be used for rechartering.

On:
> It should be noted that many existing deployments employ Internet gateways that can act as such a central node as well. Future extensions such as central node election may make this mechanism suitable for also for stand-alone ad hoc networks.

Many more networks have more than one Internet gateway. Speaking for myself, I don't see single homed MANETs in real world. Maybe it is my reading, and the text was not intended to be restrictive.

I support adding an overview document as charter item.
 
Regards, Teco

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 29 Jun 2010 15:16:22 -0700

Hi Henning and all,

> bottlenecks" by allowing multiple redundant address providers.

From the proposed charter, election part is just "future extension" and not the item we will work on right away.

In this charter we try to recycle existing IP autoconfiguration protocols for MANET environment. 

This was clearly noted in the previous charter. see below.
"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."

DHCP is a protocol supporting prefix delegation and address assignment now.
RA based approach (Alex's proposal) may be an option, too.
However, 6LowPAN WG is working on this subject based on the AUTOCONF address arch.

Why not stick to the existing IP autoconfiguration mechanism as a starting point
so that we can directly go to the solution space discussion.  
Do you want to spend a few years to define protocol requirements of a solution(s)?
I specially concern the endless activity cycle in AUTOCONF from the WG's history.

> special case of sollution 2.

Why waste of time? These two items should be tightly related, but each solution (1 and ) should work independently. 
For instance, we may use a manet routing protocol to assign an address and use DHCP for PD in the future.
To support these future extension, we should separate these two items.

regards,
ryuji

---

From: Jari Arkko <[email-masked]>
Date: Wed, 30 Jun 2010 01:22:54 +0300

Christopher,

Does this proposal mean the autoconf group will not work on a

distributed

Just so that you know who to blame :-) I was the one who asked Thomas
and Ryuji to consider a simple solution with no new protocols.

But back to your feedback on the charter. I would like to respond in
two ways. First, I am by no means wedded to the particular solution
details. Do you have a suggested edit?

But, second, I will defend the idea that the working group needs to
learn to walk before running. We've been through a five year exercise
just to define the addressing model. When we attempted to define the
architecture as a general model we realized that it was hard, and
explaining the model to non ad hoc networking experts was even harder.
But when we described a concrete addressing model that some deployments
are using we did finally get an RFC. Or almost have, at least. I would
like to continue on the same path. I'm told that there are deployed
autoconfiguration mechanisms and that some level of support is doable
even with existing protocols.

I would like to avoid repeating the experience we had earlier on trying
to describe the autoconf problem. One way of avoiding it is to describe
either a deployed autoconfiguration mechanism or describe how to employ
standard protocols and components to provide autoconfiguration for an
ad hoc network. Once this work is complete, we can describe the
limitations of this mechanism as the remaining autoconfiguration
problem, and work on that. But I do not look forward to more years of
discussion of complex routing protocol/neighbor discovery extensions
and a constant stream of questions from the outsiders about why ND or
DHCP cannot do the job.

I do get that a solution with a central node (and perhaps any solution
with DHCP) does not solve all needs. Would you be happier if the
charter had four work items:

1. Design space survey (Informational)

2. The simple solution (such as DHCP) (PS)

3. Limitations of the simple solution (Informational)

4. Recharter for work on the more general solution

Jari

---

From: Zach Shelby <[email-masked]>
Date: Wed, 30 Jun 2010 09:41:17 +0300

On Jun 30, 2010, at 1:22 AM, Jari Arkko wrote:

> I do get that a solution with a central node (and perhaps any solution with DHCP) does not solve all needs. Would you be happier if the charter had four work items:
> 

+1. I support this approach. As Ryuji mentioned, we are almost finished with work in 6LoWPAN on optimizing ND so that it works in such a low-power and lossy network. There the approach is to enable autoconfiguration with either DHCP or using a multihop DAD technique. Autoconf might be able to extend or reference that work in item 2. above and consider both DHCP and ND as parts of a simple solution. For now I think it is enough to say in the charter that DHCP and ND mechanisms will be applied (with minimal extensions) for the simple solution.

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: Alexandru Petrescu <[email-masked]>
Date: Wed, 30 Jun 2010 09:41:29 +0200

Innserting some comments although I'm not addressed.

Le 30/06/2010 00:16, Ryuji Wakikawa a écrit :
>>>> I don't think elections are a good way to add redundancy for an
>>>> address configuration system. The dependency of a single node
>>>> in the whole network to configure the addresses will be a
>>>> bottleneck for larger mesh networks.
>>>
>>> But elections is what gets rid of central node bottlenecks... if
>>>  that single node fails then elect another.
>> Elections are a real complex thing in MANETs, better have
>> redundancy and "no bottlenecks" by allowing multiple redundant
>> address providers.
>
>> From the proposed charter, election part is just "future extension"
>> and not the item we will work on right away.
>
> This was clearly noted in the previous charter. see below. "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."
>
> DHCP is a protocol supporting prefix delegation and address
> assignment now. RA based approach (Alex's proposal) may be an option,
> too. However, 6LowPAN WG is working on this subject based on the
> AUTOCONF address arch.

Well, an RA-based prefix exchange and route update would not be
dedicated to 802.15.4 only (6LoWPAN), and not to PAN either.  I run it
on wifi between Mobile Routers, supposedly between vehicles, and not on
a PAN.

> Why not stick to the existing IP autoconfiguration mechanism as a
> starting point so that we can directly go to the solution space
> discussion. Do you want to spend a few years to define protocol
> requirements of a solution(s)? I specially concern the endless
> activity cycle in AUTOCONF from the WG's history.

Hmmm... I tend to agree to stick with existing IP address
autoconfiguration mechanisms in AUTOCONF.

>>>> I don't see a difference between 1 and 2, for IPv6 case 1 is
>>>> just case 2 with a prefix length of 128 (or 64 if we use the
>>>> IPv6 autoconf postfix).
>>>
>> Which make it a waste of time to develop sollution 1, because it's
>>  only a special case of sollution 2.
>
> Why waste of time? These two items should be tightly related, but
> each solution (1 and ) should work independently. For instance, we
> may use a manet routing protocol to assign an address and use DHCP
> for PD in the future.

(I set aside what you are saying, explicitly the part suggesting that
maybe the MANET routing protocol may assign an address... if so then, by
symmetry, the address autoconfiguration mechanism could also exchange
routing information and update the routing information databases -
necessary for DHCP sometimes).

> To support these future extension, we should separate these two

I agree I think we should follow the existing separation of prefixes vs
addresses when it comes to address autoconfiguration mechanisms DHCPv6
and DHCPv6 PD.

I need a new term like "address and prefix autoconfiguration mechanism",
something like SLPAC (prefix autoconf instead of SLAAC), something like
DRCP (Dynamic Router Configuration Protocol instead of DHCP).

Alex

>
> regards, ryuji
>
>
>>
>
>>
>> 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
>> _______________________________________________ Autoconf mailing
>> list [email-masked]
> _______________________________________________ Autoconf mailing
> list [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 30 Jun 2010 09:45:58 +0200

Le 30/06/2010 08:41, Zach Shelby a écrit :
>> I do get that a solution with a central node (and perhaps any
>> solution with DHCP) does not solve all needs. Would you be happier
>> if the charter had four work items:
>>
>> 1. Design space survey (Informational) 2. The simple solution (such
>> as DHCP) (PS) 3. Limitations of the simple solution
>> (Informational) 4. Recharter for work on the more general solution
>
>
> +1. I support this approach. As Ryuji mentioned, we are almost
> finished with work in 6LoWPAN on optimizing ND so that it works in
> such a low-power and lossy network.

Well I need RA-based prefix exchanges and route updates not only on 
low-power and lossy networks.  I don't consider 6LoWPAN neither RoLL 
appropriate for RA-based prefix exchanges. (not to paint them in a 
corner but their applicability domain is not WiFi neither Mobile Router).

Alex

  There the approach is to enable
> autoconfiguration with either DHCP or using a multihop DAD technique.
> Autoconf might be able to extend or reference that work in item 2.
> above and consider both DHCP and ND as parts of a simple solution.
> For now I think it is enough to say in the charter that DHCP and ND
> mechanisms will be applied (with minimal extensions) for the simple
> solution.
>
> Zach
>

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 30 Jun 2010 09:49:36 +0200

Hi,

> +1. I support this approach. As Ryuji mentioned, we are almost finished with work in 6LoWPAN on optimizing ND so that it works in such a low-power and lossy network. There the approach is to enable…

I also agree with Jari's proposition. While I personally think that we
eventually have to work on a more general solution, it may be a good
start rechartering for a simple solution now. Considering how much
time has passed for the address architecture document, we should aim
to progress in small, doable steps rather than aiming for a
"all-in-one" solution right now. As we already have a few ideas that
could be integrated (e.g. Teco's and Zach's documents), the time frame
seems to be doable for me.

I will still continue do work on my distributed approach in the
meantime, though, so that it progresses and could be considered once
we will recharter again.

Ulrich

---

From: Zach Shelby <[email-masked]>
Date: Wed, 30 Jun 2010 11:09:18 +0300

On Jun 30, 2010, at 10:45 AM, Alexandru Petrescu wrote:

> Well I need RA-based prefix exchanges and route updates not only on low-power and lossy networks.  I don't consider 6LoWPAN neither RoLL appropriate for RA-based prefix exchanges. (not to paint them in a corner but their applicability domain is not WiFi neither Mobile Router).

Exactly, which is why that work is just an example of optimizing ND for such an environment. Obviously in some MANETs you also have prefix delegation to worry about, which we don't have in a LoWPAN. 

Zach

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 30 Jun 2010 10:25:48 +0100

Just a brief comment for the moment. My current thoughts in ad hoc
nedworks relate to security. And I think the interactions of security
and address configuration will turn out to be critical. There are
numerous solutions to address configuration that turn out to be
pointless when combined with security configuration issues. I'm
interested in more than just "assume all nodes have a shared secret
X unknown to anyone else".

________________________________

From: Jari Arkko [mailto:[email-masked]] 
Sent: 29 June 2010 23:23
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; [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.
 
Christopher,

		Does this proposal mean the autoconf group will not work
on a

	distributed 

	
	Same question, except I'd stick with the terminology ad hoc
network.
	A centralised distribution mechanism is a very poor fit to much
of
	what's attractive about an ad hoc network, and a very poor fit
(due
	to having a single point of failure) to many application areas
for
	ad hoc networks.
	
	This is not the direction I for one had hoped that the Autoconf
WG
	would go in. I note the reference to "future extensions", but
first
	I assume that this is not chartered work, and second that forces
	decentralised work into a certain shape, rather than working
from
	the problem more generally.
	
	I appreciate that the WG can only work on solutions that people
are
	prepared to work on, and unfortunately I can't offer the effort
needed
	to make a concrete alternative proposal. I think however I've
put in
	at least my share of work in the Manet WG.

But back to your feedback on the charter. I would like to respond in two
ways. First, I am by no means wedded to the particular solution details.
Do you have a suggested edit?

I would like to avoid repeating the experience we had earlier on trying
to describe the autoconf problem. One way of avoiding it is to describe
either a deployed autoconfiguration mechanism or describe how to employ
standard protocols and components to provide autoconfiguration for an ad
hoc network. Once this work is complete, we can describe the limitations
of this mechanism as the remaining autoconfiguration problem, and work
on that. But I do not look forward to more years of discussion of
complex routing protocol/neighbor discovery extensions and a constant
stream of questions from the outsiders about why ND or DHCP cannot do
the job.

I do get that a solution with a central node (and perhaps any solution
with DHCP) does not solve all needs. Would you be happier if the charter
had four work items:

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 30 Jun 2010 13:07:30 +0300

Christopher,

Just a brief comment for the
moment. My current thoughts in ad hoc

nedworks relate to security. And
I think the interactions of security

and address configuration will
turn out to be critical. There are

numerous solutions to address
configuration that turn out to be

pointless when combined with
security configuration issues. I'm

interested in more than just
"assume all nodes have a shared secret

Absolutely. To begin with, its kind of pointless to talk about "ad hoc"
(as in "unplanned") and then suddenly assume there was lots of
preconfiguration.

I am hopeful though that there are clever ways to address the biggest
security issues without causing too much pain. For instance, FCFS type
of address and prefix allocation in the large IPv6 address space seems
amenable for some proof-of-ownership solution.

Jari

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 30 Jun 2010 12:00:40 +0100

Jari
> I am hopeful though that there are clever ways to address
> the biggest security issues without causing too much pain.

I'm interested of course, but always sceptical. Pain-free
security is elusive.

> For instance, FCFS type of address and prefix allocation
> in the large IPv6 address space seems amenable for some
> proof-of-ownership solution.
 
Any references? Right now I don't follow how that would work.
But willing to be educated.

The problem in a wireless network in particular is that a
bad guy can send any pattern of bits he feels like, including
any addresses he feels like using. The address(es) may be good,
but he's not. That means the good guy needs to include something
in a message that the bad guy can't reproduce (apart from replays,
and they can be solved). It would appear that to do so the good
guy must be preconfigured with something. If that something is
specific to that device, couldn't the something include an
address, or at least something to help the address problem? If
the something is common to all devices, that's less security
than I'd like (compromise one device, compromise them all).

But the key point is I think that security really needs to be
up front, part of the requirements/problem statement, and hence
in the charter. This really is a case where security cannot be
an afterthought.

This is actually quite separate from the issue of whether
centralised DHCP is what the WG should study. It's been noted
that at least this way the WG might accomplish something, which
is an issue. The question is whether it accomplishes anything
really useful, given that even multiple DHCP servers are just
for the future. I guess that needs people to stand up and say
that if they had this, this would be what they need, and that
they'd be quite happy with having to wait quite a while (a
couple of years?) before any work in the WG was spent on
anything decentralised. If enough people say that, that justifies
the work (and provides some people who might be prevailed on to
help). However I'm not standing up.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 30 Jun 2010 14:18:29 +0300

Christopher,

> But willing to be educated.

I'm just waving my hands and I have no references. But RFC 3971 does 
something similar for SLAAC. Its not the only approach, over the years 
people have looked at different ways in allocating mobile IPv6 home 
addresses as well.

> in the charter. This really is a case where security cannot be

OK. That makes sense.

Jari

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 30 Jun 2010 13:27:44 +0200

Hi Jari,

> paper or draft. Thanks for the suggestion! I think we should add it to 

Thanks.

> simple first step solution such as DHCP that requires no new protocols.)

Agree on that.

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 30 Jun 2010 13:30:41 +0200

On Wed, 2010-06-30 at 01:22 +0300, Jari Arkko wrote:

(text skipped)

> 4. Recharter for work on the more general solution

+1. I support this approach.

Thanks,

Carlos

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 30 Jun 2010 12:40:49 +0100

>From RFC 3971

   To protect Router Discovery, SEND requires that routers be authorized
   to act as routers.  This authorization is provisioned in both routers
   and hosts.  Routers are given certificates from a trust anchor, and
   the hosts are configured with the trust anchor(s) to authorize
   routers.  

That's both significant pre-configuration, and problematic in an ad hoc
network. (The rest of section 6 has a whole lot more complexity.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jari Arkko
Sent: 30 June 2010 12:18
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter
proposal.

                    *** WARNING ***

Christopher,

OK. That makes sense.

Jari

---

From: HyungJin Lim <[email-masked]>
Date: Wed, 30 Jun 2010 20:44:25 +0900

Hi all,

I would like to make some input to AUTOCONF WG by a related paper.
The paper is as follows;
*"Route Optimization in Nested NEMO: Classification, Evaluation and Analysis
from NEMO Fringe Stub Perspective"*,* **IEEE Transactions on Mobile
Computing, *, VOL. 8, NO. 11, Nov. 2009

Although this paper considers address configuration issues in NEMO
viewpoint, the issues and result will be became nice input in AOTOCONF WG I
think.

We also need analysis about address configuration solutions like works
inNEMO WG.

Thanks,
Hyung-Jin, Lim

2010/6/30 Carlos Jesús Bernardos Cano <[email-masked]>

---

From: Henning Rogge <[email-masked]>
Date: Wed, 30 Jun 2010 15:08:04 +0200

> network. (The rest of section 6 has a whole lot more complexity.)

Address configuration security will need at least some kind of certificate 
system.
Hmm, maybe a selfsigned certificate would work (nodes generate an identity for 
themselves, then get their address bound to this identity)...

I agree we should not forget security aspects, they are very difficult to add 
on this protocol layer (similar to security for routing protocols).

Henning Rogge

-- 
1) You can't win.
2) You can't break even.
3) You can't leave the game.
— The Laws of Thermodynamics, summarized

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 30 Jun 2010 15:42:40 +0200

Hi all,

I also support a "walk-before-run" approach. To focus on the specific case
where a DHCP server is reachable somewhere in the MANET is somewhat
restrictive, but to me, it makes sense to solve this particular "simple"
case before tackling "hairy" cases.

I want however to point out that an informational RFC documenting the
observed weird characteristics of ad hoc wireless communications would be a
useful companion document for the solution to be designed for AUTOCONF (as
well as for other mechanisms currently being designed in other working
groups, including 6lowpan, ROLL). In that respect, the draft we have worked
on with Charlie is a candidate to consider:

http://ietfreport.isoc.org/all-ids/draft-baccelli-multi-hop-wireless-communication-04.txt

Regards,

Emmanuel

On Tue, Jun 29, 2010 at 6:20 AM, Ryuji Wakikawa <[email-masked]>wrote:

> Archive:
> is to standardize how existing IPv6 address configuration tools can be used
> for address configuration:
>
> for the routers in the ad hoc network. This mechanism is expected to produce
> addresses with properties outlined in RFC 5889. This mechanism uses the
> existing DHCPv6 protocol unchanged, and assumes a central node that can
> allocate addresses on a first-come-first-served basis. Other nodes in the ad
> hoc network will relay messages to the central node in order to help a new
> node get an address for itself. This mechanism is only suitable for
> deployments were a central node can be set up. It should be noted that many
> existing deployments employ Internet gateways that can act as such a central
> node as well. Future extensions such as central node election may make this
> mechanism suitable for also for stand-alone ad hoc networks.
>
> use by applications running on the routers themselves, or for configuration
> of attached hosts/networks. This mechanism works in a similar manner to the
> one above, but allocates prefixes instead of addresses.
>
> Both mechanisms should be independent on operation of any specific MANET
> routing protocol, although may exploit information maintained by such a
> routing protocol, if available.
>
> The working group will adapt and/or reuse existing protocols whenever
> reasonable and possible. 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.
>
> Goals and Milestones:
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 30 Jun 2010 16:50:10 +0300

Christopher,

> network. (The rest of section 6 has a whole lot more complexity.)

I did not mean to imply that SEND would directly be a good fit for your 
problem. In fact, I was not thinking of SEND's router authorization part 
at all. I was thinking of SEND host's ability to create addresses 
securely and defend them from other hosts, all without any 
pre-configuration, or reliance on routers.

Jari

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 30 Jun 2010 15:13:45 +0100

Jari
> pre-configuration, or reliance on routers.

But one thing that the almost interminable autoconf discussions have
made clear is that ad hoc nodes are routers, and if a SEND-like
mechanism requires much of its routers, it would require much of the
routers in an ad hoc network, i.e. all the nodes.

For security we are also, unfortunately, defending against Machiavelli,
not just against Murphy. If you pick an address, and I'm a bad guy,
observing you using the address is a reason for me to use that address,
not a reason to avoid it.

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 30 Jun 2010 10:19:39 -0400

On Jun 30, 2010, at 2:41 AM, Zach Shelby wrote:

> such a low-power and lossy network. There the approach is to enable  
> autoconfiguration with either DHCP or using a multihop DAD  
> technique. Autoconf might be able to extend or reference that work  
> in item 2. above and consider both DHCP and ND as parts of a simple  
> solution. For now I think it is enough to say in the charter that  
> DHCP and ND mechanisms will be applied (with minimal extensions) for  
> the simple solution.
>

  +2. I can support this approach as well.

Regards,
Stan

---

From: Jari Arkko <[email-masked]>
Date: Wed, 30 Jun 2010 18:21:08 +0300

Christopher,

> routers in an ad hoc network, i.e. all the nodes.

Please do not take the SEND model literally here. I am trying to suggest 
that some ideas similar to those used in other parts of SEND might be 
useful for protecting address autoconfiguration, which is what this WG 
is about. Other parts of SEND do not IMHO appear suitable. But again, 
I'm just handwaving so I could be wrong.

> not a reason to avoid it.

Right. And that is precisely the type of an attack that the address 
configuration security mechanisms could protect against.

Of course, in ad hoc networking the full scope of security problems is 
wider. Presumably there are Byzantine security issues, for instance. But 
technically those are part of the routing protocol. I'm not sure what 
MANET or ROLL has done in this space, for instance. Do you know? I do 
not believe these are for this working group, however.

Anyway, I think we've debated long enough about this particular topic. 
If I believe there are clever ways to deal with the address 
autoconfiguration security problem I need to write it up and then we can 
have a more in-depth discussion. Lets do that later.

Jari

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 30 Jun 2010 17:14:08 +0100

> technically those are part of the routing protocol.

If having an address is a pre-requisite of the routing protocol, then
leaving everything to the routing protocol is too late.

> I'm not sure what 

MANET has just agreed to accept work on specifying authentication TLVs
for the packet/message format RFC 5444 (which itself outlines the
concept).
That's the main work, i.e. it is limited.

> Anyway, I think we've debated long enough about this particular topic.

If the conclusion is that the issues of address configuration and
security configuration are intertwined (really both are also part
of the wider issue of identity) and that therefore this needs to be
considered by the WG and should be mentioned in the charter, then OK.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 30 Jun 2010 19:01:50 +0200

> considered by the WG and should be mentioned in the charter, then OK.
I agree to this.

The identity of a router is a very important part of a security concept of a 
MANET/mesh. If the network is compromised during the address configuration, it 
might be difficult or impossible to secure it later.

Henning Rogge

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 30 Jun 2010 10:34:19 -0700

Hello folks,

I find the proposed charter extremely disappointing.
Comments below.

> and Ryuji to consider a simple solution with no new protocols.

If there's anything I've learned while working on
ad hoc networks, it was that existing protocols
just plain don't do the job.

> Do you have a suggested edit?

I think we should consider solutions that have
a chance to work in general ad hoc networks, and
in my view DHCP is quite unlikely to do so in
any scalable way, for reasons that we've discussed
on the list seemingly dozens of times.

> learn to walk before running.

This analogy, if accepted as accurate, pretty much
ends the discussion.

But I do not think it is accurate.  We've had solutions
on the table for years now.  These solutions are known
to work.  There are multiple good ideas, based on
sound understanding of the problem, then built and
checked.

>                        We've been through a five year exercise

The way I see it, we spent five years trying to stop
treating everything like an Ethernet.  I wouldn't have
wasted so much time on it, except that I thought the
result would be that we could then specify an address
autoconfiguration protocol that didn't pretend everything
was an Ethernet.  Maybe I was wrong, too wildly optimistic,
in that regard.

> even with existing protocols.

The addressing model as recently completed does
support a decentralized approach.

> to describe the autoconf problem.

Didn't we finish doing that by now?  The next step would be
to specify an autoconfiguration protocol that could work in
ad hoc networks.  We have several candidates, and we could
compare them for applicability, performance, etc.

> .... But I do not look forward to more years of discussion of

Ahh... I guess you mean that the outsiders are now
controlling the destiny of [autoconf] because they
can soak up so much time asking about why we aren't
interested in programming virtual Ethernets.

> 4. Recharter for work on the more general solution

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 I had known at the outside that the answers were
"DHCP" and "avoid constant questions from outsiders",
I would have had a lot more time at my disposal for
other things.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 30 Jun 2010 10:38:35 -0700

Hello folks,

Typo in my previous message (sigh)...

> If I had known at the outside that the answers were

"outside" --> "outset".

Regards,
Charlie P.