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

From: Thomas Heide Clausen <[email-masked]>
Date: Sat, 21 Aug 2010 07:50:17 +0200

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 <[email-masked]>
> 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 <[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:
> 
> -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 
>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 23 Aug 2010 09:19:50 +0200

Hi all,

I generally agree with the proposed charter, with the comment I
mentioned in the meeting:

- Opening the door for service discovery, in addition to address
autoconfiguration, might be a bit too much, especially given our
performance in the past.

Thanks,

Carlos

On Sat, 2010-08-21 at 07:50 +0200, Thomas Heide Clausen wrote:
> 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).
> 
> 
> > Archive:
> > http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html
> > 
> _______________________________________________
> 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: Emmanuel Baccelli <[email-masked]>
Date: Mon, 23 Aug 2010 10:51:19 +0200

Hi Carlos,

I was about to send the exact same email to the list ;) I also think the
charter is OK, but would scrap service discovery.

cheers
Emmanuel

2010/8/23 Carlos Jesús Bernardos Cano <[email-masked]>

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 24 Aug 2010 06:11:16 -0400

Hi,

I think the charter is OK. 
Is there any interest in taking a closer look at the security side of the addressing 
mechanisms and service discovery?

Regards,

Wassim H.
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Emmanuel Baccelli [[email-masked]]
Sent: Monday, August 23, 2010 01:51
To: [email-masked]
Subject: Re: [Autoconf] Fwd: WGLC for the AUTOCONF charter

Hi Carlos,

I was about to send the exact same email to the list ;) I also think the charter is OK, but would scrap service discovery.

cheers
Emmanuel

2010/8/23 Carlos Jesús Bernardos Cano <[email-masked]<mailto:[email-masked]>>
Hi all,

Thanks,

Carlos

On Sat, 2010-08-21 at 07:50 +0200, Thomas Heide Clausen wrote:
> > From: Ryuji Wakikawa <[email-masked]<mailto:[email-masked]>>
> >
> > Ryuji Wakikawa <[email-masked]<mailto:[email-masked]>>
> > Thomas Clausen <[email-masked]<mailto:[email-masked]>>
> >
> > Internet Area Directors:
> > Ralph Droms <[email-masked]<mailto:[email-masked]>>
> > Jari Arkko <[email-masked]<mailto:[email-masked]>>
> >
> > Internet Area Advisor:
> > Jari Arkko <[email-masked]<mailto:[email-masked]>>
> >
> > Mailing Lists:
> > General Discussion: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

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

---

From: Teco Boot <[email-masked]>
Date: Tue, 24 Aug 2010 22:16:25 +0200

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?

Teco