[dhcwg] Client Preferred Prefix option for DHCPv6

["Vijayabhaskar A K" <[e-mail]>]

In the last IETF meeting, there were a discussion
about the client preferred prefix option for DHCPv6
and i was asked to send the requirements for this 
option.

The requirements for this option are:

<extract from my draft>

   Scenario 1: The client's link has multiple prefixes of different
   scopes and the administrator policy on the server insists that the 
   addresses need to be allocated on site-local prefixes only. The 
   client will not be able to communicate with a node that belongs to a 
   different site, as the server allocates only site-local addresses in 
   IAs.

   Scenario 2: The client's link has two prefixes: site-local and global.
   The administrator policy insists that addresses need to be allocated 
   on both the prefixes. All the nodes on a link will not communicate 
   with external sites and thus all of them do not require global 
   addresses. However, the server allocates addresses on both the 
   prefixes. So, the client needs to send the release message to release
   the unwanted addresses, which requires extra transactions.

   Scenario 3: The node has used the stateless autoconf and learned 
   about prefixes. Say, the link has two prefixes 3ffe::/64 and
   3fff::/64 and the link has been subnetted to two sets with these
   prefixes. Now, suddenly the RAs say to use stateful autoconf. It
   depends up on the dhcpv6 configuration whether the node will get both
   the prefixes or not. It will be worser if the node using 3ffe::/64
   has to renumber to 3fff::/64 unnecessarily, though both the prefixes
   are valid in the link.

   Scenario 4: In a highly secured environment where there is only a
   known IPv6 prefix by specific entities provided the knowledge of that
   prefix out of band not over a network. The entity will request this 
   prefix as a DHCPv6 client and will provide secret security parameter 
   to the DHCPv6 server. The server then provides a complete address for 
   that prefix.  The entity client now can use that address for 
   communications with nodes that accept no other prefix on the network. 
   The applications for this are special operations for entities like 
   the Military, Law Enforcement, Fire Departments, and Doctors.

   To overcome the problems described in the above Scenarios, the client 
   can specify its preferred prefixes to the server using Client 
   Preferred Prefix option.

</extract from draft ends>

Apart from the dumb devices like mobile phones, PDAs etc, there can be 
intelligent nodes which know their requirements and the necessary 
configuration. My draft concentrates on these kind of nodes.

Anyhow, its just an option, the server can very well ignore
it, if it not supporting it, thus doesn't bring any harm
to the architecture.

As i have not sumbitted the draft before March 3rd, it is not yet
published, hence i am attaching the updated draft along with this
mail. I will resubmit after March 17th.

Please go through it and let me know your comments.


~ Vijay