Subject: [Autoconf] new charter

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 10 Nov 2010 15:25:05 +0800

Hi all,

Here is the last charter sent to IESG. 

regards,
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. DHCPv6 operation over MANET, including:

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

- 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 from 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; it is expected that address uniqueness is
guaranteed by the central node alone.

2. Analysis of Problem Space for distributed address configuration and
service discovery.

The working group plans to establish design teams for rapidly advancing
towards initial submissions for these two work items.

Goals and Milestones:

- Jan 2011 First working group draft of the "DHCPv6 operation over MANET"
- Jan 2011 First working group draft of the "Analysis of Problem Space"
-Sep 2011 Submission of the "DHCPv6 operation over MANET" to the IESG for publication as BCP
-Sep 2011 Submission of the "Analysis of Problem Space" the IESG for publication as Informational RFC
-Sep 2011 Rechartering or Closing WG

---

From: Teco Boot <[email-masked]>
Date: Wed, 10 Nov 2010 11:07:36 +0100

Hi Ryuji,

I am happy to repeat my comments.
None is picked up, is it?

Regards, Teco

Op 24 aug 2010, om 22:16 heeft Teco Boot het volgende geschreven:

> I am happy with the dual approach.
> 
> Some remarks on the draft text:
> 
> It says that "other nodes will relay messages to the central node".
> On the list is was discussed the relay function could be co-located on the node itself.
> Is such a method rejected?
> 
> Typo: No new duplicate address detection mechanisms are will be specified
> "are" or  "will be". This is duplicate already :-)
> 
> I have problems with:
>>> it is expected that address uniqueness is
> 1) DHCPv6 doesn't work this way. Addresses are managed by the requesting node unique token, the DUID.
> 2) I have seen many DHCP implementations that use (link-local) probing for duplicate detection. This is for some guarantee for non-duplicates after a reboot and NV-storage. Quite often, CPE devices don't have volatile storage.
> 3) RFC 3315 specifies usage of DAD by the clients (18.1.8), e.g. for conflict resolving as result of point 2 above. 
> So the expectation is built on quicksand.
> Still, I think it is the right approach. Maybe just remove this sentence?
>    
> 

Op 10 nov 2010, om 08:25 heeft Ryuji Wakikawa het volgende geschreven:

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