Subject: Re: A few additional items re: -19 draft

From: Ralph Droms <[email-masked]>
Date: Thu, 26 Jul 2001 15:17:30 -0400

Bernie - I don't understand your question.  Can you explain what you mean 
by "client" and "allocate"?

- Ralph

At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote:

>- Should we consider a client prefix-selection option as
>a base option to allow a "client" to allocate an address
>for a prefix other than the one it might be on? Should
>this be part of the base specification?
>
>Note: Perhaps these devices should just be Relays and use
>the Relay-Forward. In this case, they can simply specify
>that information via the relay-address field. And, if we
>have the server use the IPv6 source address for sending
>replies to the relay's, then this field (relay-address)
>can even contain something that might not truly be an
>address assigned to the relay.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 26 Jul 2001 15:31:22 -0400

At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote:

>- For the Confirm message, Section 14. states:
>
>Confirm Confirm the validity of assigned addresses and other
>        configuration changes through the server from which the
>        configuration information was obtained when the client's
>        assigned addresses may not be valid; for example, when
>        the client reboots or loses its connection to a link

Turns out you've pointed out redundant and conflicting text in -19.  DHCPv6 
messages are defined in section 7 and each definition includes a short 
description.  There's no need to include a definition in section 14 as well.

Here's the text from section 7:

       CONFIRM (4)          The DHCP Confirm (or Confirm) message is used
                            by clients to confirm that the addresses
                            assigned to an IA and the lifetimes for
                            those addresses, as well as the current
                            configuration parameters assigned by the
                            server to the client are still valid.

Perhaps the easiest thing to do would be to constrain the Reply to a 
Confirm to be a binary response: ACK implies everything OK (no changes from 
the server; everything from the client used as currently known to the 
client); NAK implies client does a Request.  Otherwise, we might get 
conflicting responses from multiple, non-coordinating servers, as you point 
out:

>We probably need to clarify the behavior somewhat. For example,
>if a server that did not give out the addresses responds, can
>it:
>- Allocate additional addresses (to the IA)?
>- Extend the lifetimes of existing addresses?
>- Change/respond with configuration parameters?

Perhaps we might allow extension of address lifetimes, as this has been 
shown to work among multiple servers with DHCPv4 failover...

>If the client does request (and supply) other options, what
>happens if the server's reply does not include those options
>(perhaps because the server doesn't feel it can supply them).
>
>I guess what I'm suggesting is that we indicate that allocation
>of addresses and supplying configuration parameters with a
>Confirm are problematic. And, that a client MUST NOT assume
>that the lack of a configuration parameter (option) means
>that the previous value for that option should be removed.
>
>Similar behavior might be required for Rebind - as multiple
>servers may respond? Though I think there are fewer issues
>here.
>
>Perhaps we should stress that Confirm SHOULD (MUST) only be
>used to confirm whether addresses are valid and SHOULD NOT
>(MUST NOT) be used in place of a Renew/Rebind?? Perhaps we
>should even specifically state that clients MUST NOT apply
>changes to the lifetimes or addition of new addresses received
>in a Reply to a Confirm?

---

From: Ralph Droms <[email-masked]>
Date: Thu, 26 Jul 2001 15:35:56 -0400

Why would the server send any options at all in a Reply to a Decline or 
Release message?  Of course, if the server shouldn't send any options in 
those Reply messages, the spec should explicitly say so.

- Ralph

At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote:
>- For Reply messages to Decline and Release messages,
>what should the server do about options (other than the
>IA)? This may be less of a server issue but more of a
>client issue. It probably makes little sense for the
>server to include a "Domain Name Server option"? And
>servers may want to provide a minimal message to save
>bandwidth and processing overhead? I guess since we have
>no idea what future options may be defined, the best
>recommendations is that servers MUST send those options
>explicitly requested by a client's ORO option; a server
>MAY send other options (though clients are free to
>ignore these extra options - as they normally are!).
>Perhaps this is already implied by the options
>processing (based on DHCPv4) but wouldn't it be best to
>make it explicit? This same processing probably applies
>to ALL option handling in any Reply to a client message.
>Is it already in the draft and I missed it?

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 26 Jul 2001 14:48:56 -0500

Let me try to clarify ...

By client I meant something like a Network Access Server (Remote Access
Server) that is acting as a DHCPv6 client on behalf of "real" clients (but
those clients don't run DHCP but instead us some other means of obtaining
addresses from the NAS/RAS).

Perhaps this model doesn't apply to IPv6? (As I recall, the PPP over IPv6
document only allows negotation of a interface identifier. And, this probably
contracts a lot of the IPv6 address configuration specifications.)

Basically, I'm trying to forsee the situation where a device is using DHCPv6
on behalf of a "client" (not a DHCPv6 client) to obtain addresses for it.
However, the link on which that device (which is the DHCPv6 client) is
communicating with the DHCPv6 server (either directly or indirectly) is NOT
the link on which it needs to obtain addresses for.

Now, perhaps the argument in DHCPv6 would be that that device should act
as a relay, but perhaps that adds one more level of complexity into the
implementation that isn't needed or desired.

A server always can have policy controls as to whether it will or will not
accept that "Prefix Selection Option" or not.

Does that help? Perhaps this is a useless request at this time if noone
else feels there is any need (it can always be added later I guess like the
subnet selection option was).

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 3:18 PM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: Re: A few additional items re: -19 draft

- Ralph

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 26 Jul 2001 15:01:50 -0500

>There's no need to include a definition in section 14 as well.

Great. Guess I didn't do a throughout enough saerch. Removing redundancy
(especially when conflicting) is good.

>shown to work among multiple servers with DHCPv4 failover...

Hum ... 

Failover servers are kind of special since they generally share information.

But consider if you have multiple servers that don't communicate with each
other (and have the protections of the failover protocol), then you can't
allow one to extend the lifetimes since the original server never learns of
the extension and would potentially "reclaim" the addresses.

So, I would say that only the server that gave out the addresses in the
first place can extend them on a Confirm. Future extensions to DHCPv6 or
special server-to-server communication protocols could alter this behavior
in the future.

Also, if you did allow *ANY* server to extend the lifetimes on a Confirm,
does that mean the client should communicate with that new server when it
is time to Renew? Or should it go back to "old" server (that gave it the
addresses on a Request or previously Renewed)?

- Bernie

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 26 Jul 2001 15:07:35 -0500

Ralph ... that may be perfectly acceptable - especially with the options we
have defined today. Of course, you probably do need the server to send back
the IA option with the "success" code in it. Also, we should state that the
client MUST NOT include the ORO option?

We should allow future options to define different behavior (since they may
be similar to the IA option).

Here's a new issue ... I think the server should ALWAYS send back an IA option
with *ALL* of the addresses that it believes the client still has after a
DECLINE or RELEASE. Only if the server believes the client has no more addresses
should it send back the IA option with num-addrs = 0.

Now, if the Release/Decline FAILS, then the server should send back the IA option
that the client sent with the error information.

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 3:36 PM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: Re: A few additional items re: -19 draft

- Ralph