Subject: [dhcwg] Client Preferred Prefix option for DHCPv6

From: "Vijayabhaskar A K" <[email-masked]>
Date: Fri, 14 Mar 2003 17:27:26 +0530

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

---

From: Ralph Droms <[email-masked]>
Date: Mon, 17 Mar 2003 08:58:30 -0500

Vijay - I have a couple of questions and comments about your requirements 
(in line)...

- Ralph

>    different site, as the server allocates only site-local addresses in

If the DHPCv6 server policy is to assign addresses from site-local
prefixes, what information would the client send to the server
in the preferred prefix option?  Even if the client expresses a
preference for a global prefix, the server policy will override
that preference and the client will receive only addresses
from site-local prefixes.

>    the unwanted addresses, which requires extra transactions.

Here, to, it seems the server policy would override any preferences
from the client.

>    has to renumber to 3fff::/64 unnecessarily, though both the prefixes

I think this scenario, too, represents a problem for cooordination
of configuration between the prefixes advertised in RAs and the
DHCPv6 server.  It's up to the network admin to make sure that
addresses assigned by the DHCPv6 server are coordinated with the
advertised prefixes - there's no additional information for the
client to supply to the server.

>    the Military, Law Enforcement, Fire Departments, and Doctors.

For this scheme to work, I would think the client would have to know
the network topology so it could decide what prefix or prefixes would
be routable from the link to which the client is attached.  Rather than
giving that topology information to each client, it would be
more efficient to program the topolgy information into the server
and let the server decide which prefix or prefixes are appropriate.
The client can still use an authenticated identification mechanism
to convey its identity to the server for prefix selection.

>~ Vijay

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Mon, 17 Mar 2003 23:27:50 +0530

Ralph,

Thanks for your comments and see my reply inline.

~Vijay

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Ralph Droms
> Sent: Monday, March 17, 2003 7:29 PM
> To: [email-masked]
> Cc: 'DHCPWG'
> Subject: Re: [dhcwg] Client Preferred Prefix option for DHCPv6
> 
> 
> in the preferred prefix option? 

The client will send its preference by sending the prefix it wants
in the client preferred prefix option, in this case, the site-local
prefix.

> Even if the client expresses a

In this case, it is true. The client is asking for a prefix
which cannot be provided by the server. But, not true for all the cases.
Look at the next case.

> Here, to, it seems the server policy would override any preferences

Here, the client is not asking something which the server doesn't
manage. It has a preference over one of those prefixes. That's it.
Basically, when the server is not able to offer the address on
the client requested prefix (or) server is not supporting this
option, the server is going to do either one of the following :
ignore the message as the whole (or) it can ignore this option 
and reply as if this option is not present in the client message.

> client to supply to the server.

The problem is not with the coordination of the configuration
info, but with the allocation policy. Say, the policy is to 
allocate the addresses from one of the prefix, then the client
may not get its prefered one. Here, it will be useful to
have this option.

> to convey its identity to the server for prefix selection.

Yes, of course, this option is for those clients which has an
idea about the network topology and the prefixes in the links,
which it has obtained through by some out of band mechanism.
I think sending the authentication id along with the preferred
prefix will be more easier and simpler than the server authenticating
and deciding the prefixes for the the client with just the key 
information. Moreover, the client anyhow configured with the keys 
in some way out of band for these kind of highly secured environment,
it can learn about the prefixes along with that.