Re: [Autoconf] Fwd: WGLC for the AUTOCONF charter

Teco Boot <> Tue, 24 August 2010 20:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36EDC3A694C for <>; Tue, 24 Aug 2010 13:16:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.523
X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nSwghwIM1jV3 for <>; Tue, 24 Aug 2010 13:15:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AAF3B3A694E for <>; Tue, 24 Aug 2010 13:15:56 -0700 (PDT)
Received: by ewy22 with SMTP id 22so3987812ewy.31 for <>; Tue, 24 Aug 2010 13:16:29 -0700 (PDT)
Received: by with SMTP id b14mr5970936ebi.33.1282680989038; Tue, 24 Aug 2010 13:16:29 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id u9sm733019eeh.23.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Aug 2010 13:16:27 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary=Apple-Mail-22--568892277
From: Teco Boot <>
In-Reply-To: <>
Date: Tue, 24 Aug 2010 22:16:25 +0200
Message-Id: <>
References: <> <>
To: Thomas Heide Clausen <>
X-Mailer: Apple Mail (2.1081)
Subject: Re: [Autoconf] Fwd: WGLC for the AUTOCONF charter
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Aug 2010 20:16:03 -0000

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
>> guaranteed by the central node alone.

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 21 aug 2010, om 07:50 heeft Thomas Heide Clausen het volgende geschreven:

> Dear All,
> (sorry, traveling and so only catching up on mails now)
> It appears that this email made it to me, but not onto the 'list - for which we apologize. 
> The original WGLC deadline was set to August 26, in view of the message not making it last time around, the new WGLC deadline is August 30, 2010 (Ryuji, I have edited your email to that effect).
> Kindly provide your feedback, even if it is to express agreement with the proposed charter.
> Sincerely yours,
> Thomas
> Begin forwarded message:
>> From: Ryuji Wakikawa <>
>> Date: August 17, 2010 19:05:04 GMT+02:00
>> Subject: WGLC for the AUTOCONF charter
>> Hi all, 
>> This is another WGLC for our new charter. 
>> We had good consensus at the meeting, but will confirm the consensus on the list again.
>> The deadline for this WGLC is going to be Aug 30.
>> Please give us your opinion.
>> regards,
>> ryuji
>> ps. We'll send out the summary of the another WGLC for RFC5889. 
>> Ad-Hoc Network Autoconfiguration (autoconf)
>> -------------------------------------------
>> Current Status: Active
>> Chairs:
>> Ryuji Wakikawa <>
>> Thomas Clausen <>
>> Internet Area Directors:
>> Ralph Droms <>
>> Jari Arkko <>
>> Internet Area Advisor:
>> Jari Arkko <>
>> Mailing Lists:
>> General Discussion:
>> To Subscribe:
>> Archive:
>> 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:
>> -Dec 2010 First working group draft of the "DHCPv6 operation over MANET"
>> -Dec 2010 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 
> _______________________________________________
> Autoconf mailing list