Subject: Re: DISCUSSION: Use of Address Extensions with DHCPv6

From: Jim Bound <[email-masked]>
Date: Wed, 1 Dec 1999 01:50:22 -0500 (EST)

Charlie,

I don't agree with 90% of what you object to.  But for now I am just
going to listen to where the working group goes with this discussion.
especially the implementors.  Then you, Mike, and I can look at it and
state what we think we heard everyone say and present the issues.
So I am not going to defend my statements you don't agree with at this
point I would rather see the wg respond.

thanks
/jim

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 2 Dec 1999 05:38:44 -0500 (EST)

> Semantics of messages:
> 
> 1.  Client sends DHCPv6 Request with no address extension. 
> 
> 1a. Server responds with all addresses available to the client 
>     if the sys admin has defined the server can do this.
> 
> 1b. If the server gets a second message from the client with no
>     address extension it resends the client addresses it gave 
>     them previously cumultatively (see below).
> 
> This would be the default behavior for DHCPv6 and how clients request
> addresses.  The reason there is a sys admin decision is that the network
> admin folks may have decided to use stateless addrconf and dhcpv6 is
> only being used to provide non-address parameters to the clients or to
> update DNS, etc.. 

Jim,

These examples are great trying to nail down the details!

One comment. If a adminstrator wants to use stateless on some links and
dhcp on other links the above seems to be error prone.
Both the stateless boxes asking dhcp for non-address information
and the stateful boxes (asking dhcp for addresses) will send
the same request: one without any address extension.
Thus should the admin get things wrong there will be some confusion.
And the fact that the stateless/managed knob is configured in the routers
sending router advertisements and the "which nodes/links should get addresses"
is configured in the dhcp server, means that misconfiguration will happen.

This *if* the WG concludes that they want different ways to ask for addresses
(as out specify with #1, #2, #3) I think it would be useful to have a
specially marked address extension (for the default set) in #1.
That way a stateless client which asks for non-address info will never
be surprised by receiving address extensions from the server.

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Thu, 9 Dec 1999 06:33:12 -0500 (EST)

In your previous mail you wrote:

   Semantics of messages:

=> I have a real concern with this because a client should be
allowed to use DHCPv6 for other things than statefull autoconf,
ie. the semantics of no address extension in a request should be
"I don't want an address".
Another point: #1 is no address extension or no extension at all
(ie. there is a conflict with #3)

=> this breaks the one for one releasable resource rule.
Is it a real issue?

=> this supposes the client can be identified in all cases
(this is the only issue I can see).

=> Argh! In fact I believe you'd like to have this #1 behavior ONLY
when the server knows the client is on a "managed" link. In this
context then I'd like to change my concern against the whole #1
to a request for a clarification!

   2b. The client MUST NOT send this through a RELAY-AGENT and the 
       client is assumed to have an address with enough scope to 
       reach the server directly.

=> a stupid (?) question: how you can identify the client in this case?

   3.  Client sends Request with address extension or extensions
       which are not empty.
   
=> I don't really understand the "extensions which are not empty"...
I believe we should have a way in this context to get an extra address
in a prefix, I believe your answer is "form an address in this prefix
and check with the server if this address can be used", this is good
for me.
   
Thanks

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Thu, 9 Dec 1999 07:06:39 -0500 (EST)

Hi Mike,
   
   >Seems to me (after no small amount of consideration) that a server needs to
   >provide more information in its advertisements then we have been
   >proposing (note that providing this information doesn't change the
   >protocol as defined at all). Consider my summary of
   >question #1 - I've used it in responding to this message.
   
=> I'd like to get a clarification about what kind of infos may/should
be in advertisements too.
   
   >#1 goes against the constraint I listed in the Summary: DC meeting
   >question #1 message: Clients must explicitly request releaseable
   >resources.

=> I had the same reaction but now I believe Jim wanted to put #1 in
a special context where the server knows DHCPv6 is used for address
management then #1 simplifies the whole thing.

   >If the server had explicit (through policy) or implicit
   >(dynamic addresses) to offer to the client, it would do so by adding
   >IP address extensions carrying these addresses to the
   >advertisement. The client would request one or all of these IP
   >addreses in its request. If the site is using stateless autoconf, then
   >the server would not have any IP address extensions in its
   >advertisement, and thus the client could not request an IP address.
   
   that would work yes.  same affect.  I can live with this if others can?
   
=> we need to have an exchange with extensions in order to negociate
DNS stuff for instance. If they are in advertisements this will work
(ie. I can live with this, this is in fact one of the solutions for
the multiple address management issue).

   >I'm assuming that this request is in addition to the IP
   >address(es) offered in the advertisement. The client will have
   >knowledge of what networks are available from the advertisement, and
   >thus would need to tell the server which network it would like an IP
   >address on. Thus, an empty IP address extension isn't enough - the
   >client would need to communicate which network.

=> I believe you should do it with the #3, the only difference is
with #3 the client has to build an address in the prefix.

   >At DC, I proposed a change to the IP address extension which would
   >permit the client to identify which network it wants an additional IP
   >address on. Whether or not it would receive an address is up to
   >administrator policy.

=> perhaps this introduces an unneeded complexity? I can live with
the rule that servers give primary addresses (ie. one address in each
prefix for each client on a "managed" link) and clients build and check
(with servers) secondary/extra addresses (ie. an address not in the previous
case).

   >Note that a server could use this modification for advertising
   >network prefixes, without advertising a specific IP address on that
   >network.
   
=> I think new prefixes should be dealt with reconfigure then I can't
see where this change is really needed.

   Again this is an optimization I can live with.
   
=> Jim, I am afraid it is an extra complexity and not an optimization.

   But for this case a client would have to provide an extension for each
   address it wanted.
  
=> this is a good thing because the client wanted extra things then
it needed fine control: my idea is we have to split the address management
is two parts, one for primary addresses and one for secondary addresses.

   Do you agree with this semantic for the protocol?
   
=> we need to write it down again before (and to get more opinions)

   And with the behavior?  This is one of Thomas's issues as a note and I
   would like to resolve that meta issue very clearly this time?
   
=> this issue is important because without a good address management
DHCPv6 is nearly useless (and implementors will restrict it to the
"other parameters" part as some have already done :-).

   >Jim, I don't think this is a good scenario. A Client should never
   >be involved in telling a server about IP addresses (or other
   >releasable resources) it may have that the server has no knowledge
   >of. Sure, a client MAY request that a certain address be assigned to
   >it, and if the request is valid from a network topology point of view
   >and a administrator policy view, then fine. I just don't think we
   >should be configuring DHCP servers with DHCP clients, IMHO.
   
=> this is a matter of taste. For primary addresses I agree that the
server should have the control and the client should be kept as stupid/
simple as possible. For secondary addresses the context is very different
because the client is supposed to know what it wants and to use the
server only as a check/register device is fine for me.

   Same difference.  If the address is not topologically correct then the
   server would not permit it?
   
=> I think your idea is to restrict the server to a passive role too
in this case.

Thanks

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Thu, 9 Dec 1999 07:06:58 -0500 (EST)

I am getting a feeling that things are seeming much more complex
   than they really are.  I'll try to bring as much simplicity back
   into this conversation as I can possibly do.
   
=> do you think we should disagree? (:-)

   Allowing extensions to the advertisement message is a suitable way
   to allow for administrators to cater to sophisticated clients.  But
   on the other hand I don't think it means that all servers need to
   advertise everything they might be willing to offer to the clients,
   especially because so many clients won't care very much.
   
=> Charles' idea is just to offer addresses in advertisement as
the first part of the negociation for primary addresses.
We need something like this because the knowledge (of the prefix list)
is in the server and requests are done by clients.
This is only a (re)use of an existing mechanism in order to solve
the primary address management problem.

   > > 1.  Client sends DHCPv6 Request with no address extension.

=> this has been overruled by Charles' idea (if we agree about it).

   We decided in Minneapolis that all releaseable resources needed
   to be explicitly requested, even if right now everybody knew that IP
   address extensions could be designed otherwise.
   
=> I believe this is a good principle and if we can add a one for one
rule (ie. don't get 3 instances of a resource when only one was requested)
it will be better too.

   I think a client should be able to request an IP address even if the
   site is using stateless address autoconfiguration.  This does not lead
   to any ambiguities to my best current understanding.
   
=> if we adopt something like my primary/secondary classification then
in this case it will be a secondary IP address (because primaries were
dealt with by stateless autoconf).

   Furthermore, I don't think that the client has to request an address
   that is listed in an advertisement, and I don't think that the
   advertisement has to have an IP address extension before the client
   is allowed to get an IP address.
   
=> how do you solve the multiple prefix issue?
   
   > permit the client to identify which network it wants
   > ...
   
   I don't see the need for this.

=> I agree
   
   If a client sends a nonempty IP address extension to a server, it
   is asking that server to renew or extend the lifetime for that address.

=> there is a third case: the secondary/extra address. And of course
the discussion is about that...
   
Thanks

[email-masked]