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

[Teco Boot <[e-mail]>]

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?
   

Teco


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 <[e-mail]>
>> 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 <[e-mail]>
>> Thomas Clausen <[e-mail]>
>> 
>> Internet Area Directors:
>> Ralph Droms <[e-mail]>
>> Jari Arkko <[e-mail]>
>> 
>> Internet Area Advisor:
>> Jari Arkko <[e-mail]>
>> 
>> Mailing Lists:
>> General Discussion: [e-mail]
>> 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:
>> 
>> -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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/autoconf