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

[Alexandru Petrescu <[e-mail]>]

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.
>
> Please give us your feedback before July 9th.
>
> thanks, ryuji
>
> 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. 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
> [e-mail] https://www.ietf.org/mailman/listinfo/autoconf
>