Subject: DISCUSSION: Use of Address Extensions with DHCPv6

From: Jim Bound <[email-masked]>
Date: Fri, 26 Nov 1999 12:51:57 -0500 (EST)

folks,

I think we need to discuss some details here.  what do folks think about
the attached:

ONLY DISCUSSING ADDRESS EXTENSIONS other parameters and what clients or
servers should do is being discussed globally on another mail thread.

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.. 

2.  Client sends Request with 1 or more "empty" address extensions 
    
2a. Server responds, if the client is permitted a new address, with a new 
    IPv6 address in addition to the ones given to the client previously.
    If the client is not permitted a new address then an error is 
    returned to the client.
    The previous addresses are not resent to the client in the
    Server Reply.

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.  This permits the use of DHCPv6
    authentication or IPsec to be used to access the server.
    [In fact it probably should be a MUST have security for 
     this type of transaction.]

This would be a configured behavior permitted by sys admins.
To support this behavior we must require that the transaction-id be part
of the clients binding for the server/client database kept by the
server, when the client uses this feature.  The binding would be as follows:

    client-link-local-address
    dhcpv6-agent-address-prefix
    ipv6-address given to client
    valid and preferred lifetimes
    transaction-id from the request by the client

* we can add in the appendix that a server can structure the database
  so that the main key is link-local + agent-prefix and sub keys are
  the remaining parts.  We should also point out that when dhcpv6 
  operates in this mode there is more cost for memory and for 
  performance as the sever must now locate previous transactions 
  with this behavior or use a binding-cache (see discussion below).

3.  Client sends Request with address extension or extensions
    which are not empty.

3a. Server adds these addresses to the sever database for this 
    client.  Server sends Reply back to the client if it is 
    permitted to do this with the addresses the client sent
    back to the client in the Reply.

3b. 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.  This permits the use of DHCPv6
    authentication or IPsec to be used to access the server.
    [In fact it probably should be a MUST have security for 
     this type of transaction.]

We really need to discuss this scenario.  Do we want to permit this type
of behavior in DHCPv6.  This breaks the model of DHCPv4 yet again and is
really new stuff???????????  But we could make it work.

What is the affect of #3 above to any future server to server protocol,
could clients "updating" dhcpv6 server databases throw a synched server
to server protocol database out of synch?

BINDING-CACHE:  We would move the binding cache discussion to the
appendix as the above I think fixes idempotent problems in the protocol
standard.  The binding-cache would also lesson the cost/performance hit
I speak of above in implementations.  The server would only need to
store the Reply that has to be resent and an not the entire client
database.

Comments and Shoot Holes in the above please...if there are any...

Or just say you only want the default and why?

Whatever but if we can wrap this one up we will have made great progress
for the next rev of the spec.

thanks
/jim

---

From: "Michael W. Carney" <[email-masked]>
Date: Mon, 29 Nov 1999 19:47:17 -0500 (EST)

Hi Jim,

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.

> only being used to provide non-address parameters to the clients or to

#1 goes against the constraint I listed in the Summary: DC meeting question #1
message: Clients must explicitly request releaseable resources. 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.

>      this type of transaction.]

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. 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. Note that a server could use this modification for
advertising
network prefixes, without advertising a specific IP address on that network.

> server, when the client uses this feature.  The binding would be as follows:

I don't see that the transaction id needs to be part of the binding. The XID is
cached
to enable a server to distinguish retransmissions from new requests. The
link-local
address, agent prefix, and IP address should be enough. Prehaps I'm missing
something.

>   with this behavior or use a binding-cache (see discussion below).

Do we really want/need to specify this?

> to server protocol database out of synch?

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.

> store the Reply that has to be resent and an not the entire client

Binding cache is very useful for preventing unnecessary database lookups. Ah,
now I see where you're coming from wrt saving the transaction ID - you're
attempting to record the assignment transaction to avoid confusion between
retransmissions and new requests.

Is it really necessary to be this heavy-weight? Sure, as specified, there is
a window where the server's XID timeout cache may timeout cache entries
while a client is retransmitting (server reboots, loses cache information), but

that window is very small. In most cases, the XID cache timeout will be large
enough and the server stable enough to prevent the accidental assignment of
additional IP address(es) (or other releasable resources). Alternately, a
server could write its XID cache to stable storage from time to time, and
reload it upon restart, thus satisfying the idempotent problem w/o having the
cost of the extra space in the database and extra initial database lookup.

--

Mike Carney

---

From: Jim Bound <[email-masked]>
Date: Tue, 30 Nov 1999 02:12:47 -0500 (EST)

Hi Mike,

>question #1 - I've used it in responding to this message.

OK.  I think I agree with you on that count.

>IP address extensions in its advertisement, and thus the client could not

that would work yes.  same affect.  I can live with this if others can?

>network prefixes, without advertising a specific IP address on that network.

Again this is an optimization I can live with.

But for this case a client would have to provide an extension for each
address it wanted.

Do you agree with this semantic for the protocol?

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?

>address, agent prefix, and IP address should be enough. Prehaps I'm missing

will respond further down.

>Do we really want/need to specify this?

We should not have to I was being nice.  

>should be configuring DHCP servers with DHCP clients, IMHO.

Same difference.  If the address is not topologically correct then the
server would not permit it?

>retransmissions and new requests.

No if the XID-TIMEOUT happens and the retransmission gets pass the
binding cache is the problem.  

>cost of the extra space in the database and extra initial database lookup.

but it could happen Mike.  if it can happen don't we have to cover it?

Whats the worst thing that could happen.  What I come up with is:

We don't give the client another address because we think we already
gave them their last one because this retransmission is treated as a new
request (got past the binding cache) and when we look at the database we
the server believe we have given them all the addresses they can get.
The client would get an error returned.

Seems that putting the transaction id in the sever database is a small
price to pay to respond to clients when the XID_TIMEOUT was not big
enough?

/jim

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 30 Nov 1999 20:35:07 -0500 (EST)

Hello folks,

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.

> 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 think that when there are multiple servers, you are right that
a client might wish to get more information in the advertisements.
When there is just one, no additional advertisements would help.
When the client doesn't care, no additional advertisements are
needed.

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.

> >     them previously cumultatively (see below).

If the client sends a request with the same transaction ID, it
should get the same reply.  If the client sends the request with
no extensions and a different transaction ID, then the server should
send one or more new configuration items if it is willing to do so
for that client.

If the client wanted to renew a specific address, it would include that
address in an IP address extension.  If it does not include that address
for a valid IP address it is using, it is not asking the server's
opinion about that IP address.

This algorithm seems pretty unambiguous to me.

If the working group decides that IP addresses must be explicitly
requested, then of course the client wouldn't get any IP addresses
if it doesn't include the address extension or the as-yet-undefined
Parameter Request extension.

My first paragraph above is worded in such a way that it should still
hold true even if the working group decides to allow a client to get
addresses without explicitly asking for them.  I would prefer that this
decision be made to allow such freedom, but I don't want to get dragged
again over the coals of consistency with future extensions for
releaseable
resources.  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.

> have any IP address extensions in its advertisement, and thus the client could
> not request an IP address.

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.

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.

> >      this type of transaction.]

The client should be able to send any DHCP Request through a
relay agent.  Why not?  Authentication is fine, and I don't think
that one should be required to authenticate the request just to get
an address.  There are lots of them.  On the other hand, a server
should be allowed to require authentication if that is site policy.

> client would need to communicate which network.

The server is supposed to know which network it is by looking at the
relay agent address, or else by looking at the client address.

>    At DC, I proposed a change to the

I don't see the need for this.

> address, agent prefix, and IP address should be enough.

The transaction id has to be stored somewhere for the client, and
the binding is an O.K. place.  Other places are also O.K.  We discussed
this recently on this list, I think.

> Do we really want/need to specify this?

I don't think so, myself.

> > really new stuff???????????  But we could make it work.

I do not understand what is wrong here.  Clients should be able
to ask for IP addresses when they need one.  I disagree with Jim's
proposed restriction about avoiding Relay Agents.

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.
This is very natural.  I don't see what is wrong.

> Jim, I don't think this is a good scenario. A Client should never be involved in

While I agree with your point, Mike, I don't think it is an issue
given my interpretation of what it means for a client to include an
address in its DHCP Request.

> retransmissions and new requests.

The latter sentence is precisely what the transaction ID is supposed to
be used for.  I don't think of any other function for it, just off the
top of my head right now.

> cost of the extra space in the database and extra initial database lookup.

I am failing to see the problem here.  The transaction ID allows a
server
to recognize retransmitted Request messages.  It has a similar role for
Reconfigure messages.  I'm getting perplexed by what might be causing
this
to be confusing.

Regards,
Charlie P.