Subject: [dhcwg] questions about dhcpv6-28

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 14 Jan 2003 16:31:41 +0900

I have several questions on draft-ietf-dhc-dhcpv6-28.txt from my
implementation experiences.  (It is probably too late to reflect the
points to the spec before it becomes an RFC, though.)

I'd apologize in advance if some (or all) of them were addressed in
the draft, but I could not find the answers.

1. Section 18.1.8 says:

   When the client receives a NoBinding status in an IA from the server
   in response to a Renew message or a Rebind message, the client sends
   a Request to reestablish an IA with the server.

does this imply that the client must remove the IA before sending the
request?  (I guess the answer is YES, but I'm asking this to be sure.)

2. What should a client do if it receives an IA_NA in a reply message
   where T1 > T2 > 0?
   a) the client must ignore the option (or the entire reply message)
   b) the client must treat as if T1 = T2
   c) the client must choose appropriate alternatives for T1 and T2.
    (this cannot be an option, though, because Section 22.4 says the
     client MUST use T1 and T2 if they are non-0)
   d) others

   FYI: Our implementation currently takes the option a).

3. What should a server do when it receives a request message and
   already has a binding required in the request?  (this can happen if
   the first reply was lost and the client resend the request
   message.)

  FYI: Our implementation currently updates parameters
  (e.g. lifetimes) of the binding and sends a reply with the
  parameters, just like the server receives a renew message for the
  binding.

4. Section 18.1.8 says

   When the client receives a NoAddrsAvail status from the server in
   response to a Request, the client can either try another server
   (perhaps restarting the DHCP server discovery process) or use the
   Information-Request to obtain configuration parameters only.

This sentence is not very clear to me.  I interpreted this sentence
corresponds to the following part of Section 18.2.1:

   If the server cannot assign any addresses to an IA in the message
   from the client, the server MUST include the IA in the Reply message
   with no addresses in the IA and a Status Code option in the IA
   containing status code NoAddrsAvail.

If so, there may be other IAs that do not contain NoAddrsAvail status
code.  In this case, what should the client do for the other IAs?

Or, does Section 18.1.8 mean a NoAddrsAvail code in the DHCPv6 options
field (i.e. not in an IA)?

5. Section 18.1.3 says:

   ...The
   client includes an IA option with all addresses currently assigned to
   the IA in its Renew message.

and Section 18.2.3 has corresponding sentences:

   If the server finds that any of the addresses are not appropriate
   to the link to which the client is attached, the server returns the
   address to the client with lifetimes of 0.

   If the server finds the addresses in the IA for the client then the
   server sends back the IA to the client with new lifetimes and T1/T2
   times.  The server may choose to change the list of addresses and the
   lifetimes of addresses in IAs that are returned to the client.

That is, (in my understanding)

- the client sends all addresses for an IA to be renewed.
- (if the binding is still valid) the server returns all the addresses
  for the IA with 0 or larger lifetimes.

Now, what if the client finds a lack of addresses in the reply message
for the IA?

  a) the client should ignore the entire IA (or the entire reply)
  b) the client should let the dropped address expire (unless there's
     no more update)
  c) others

FYI: Our implementation currently takes the option b), though we do
this for prefixes in an IA_PD option, not for addresses.

6. there seems to be a corner case about handling the Rapid Commit
   option.  Section 17.1.3 says:

   ... If it does
   not receive such a Reply message and does receive a valid Advertise
   message, the client processes the Advertise message as described in
   section 17.1.3.

But what should the client do if it receives a reply message for a
solicit message with a Rapid Commit option after receiving an
advertise message?  Should the client ignore or accept it?  In the
latter case, what if the client has already sent a request message
(then it will receive a different reply)?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 28 Jan 2003 12:42:33 -0600

>Ralph pointed out to me the possibility of some "magic" between a
>primary server and a backup server, which allows those servers to be
>synchronized in real time.  I'm not sure how this is realistic,
>either, but I'd personally prefer to keep the possibility.

For DHCPv6 there seems to me a better way to handle things like failover?

The two standard mechanisms would be:
1. Failover like protocol between the two servers
2. Redundant backend database

But, with the large IPv6 addresses, there is another way which I think is even
better and requires no communication between "redundant" servers (well, there is
the configuration issues but there is no need or minimal need for ongoing
communication). The idea is as follows:

- Use load balancing on the client identifier to determine which "new" clients a
server will handle. The one issue here is if a server goes down, a portion of the
client population will take a while to get addresses (to allow the Service Delay
to pass). This can be resolved by specifying a rather simple means for servers
to probe each other to determine whether they are alive. Another option is to
abandon load balancing and instead allow all servers to respond to Solicits. Or,
to alter how a server handles load balancing - it could simply adjust its server
preference based on whether the client is in or out of its hash bucket (in means
use 255 as the server preference, whereas out means use a lower value).
- Use load balancing when generating new IPv6 addresses to restrict the addresses
a server will allocate to a client. This prevents the partner server(s) from
generating the same addresses and doesn't require the servers to communicate (this
was always an idea Steve Gonczi was pushing when we were designing the DHCPv4
failover algorithm, but the address space wasn't large enough to really allow it
to be used). In IPv6, if one "looses" the ability to generate addresses for a large
fraction of the address space (such as 1/256th the space), the impact is really
not noticeable (2^62 / 256 is 2^54 which still allows plenty of addresses).
Note: The input to the load balancing algorithm in this case is the generated
IPv6 address. If it is in the server's hash bucket, it can be used. If not, the
server generates another until one is found that is in the hash bucket. 
- Trust clients. For a Renew, this goes to the server that originally assigned
the address. For a Rebind, any server that receives it may respond and renew
the address. It keeps a record of the binding in this case but it will never
reassign the address to another client. This does mean that the server that
failed to Renew might expire the address and reassign it to another client
while the first is still using it ... to reduce the chance of this, servers
should not reuse addresses for "a long while" unless a client has explicitly
released the address. Hopefully, in the worst case, DAD will resolve the problem
should it happen.
- Another option for handling Rebinds is for the other servers to give out
new addresses instead of renewing the existing ones. This allows the client
to continue using its existing addresses until the lifetime expires and
transition to the new addresses. Perhaps this should be configurable action -
either servers are allowed to Rebind existing addresses (with the small risk
of duplicate addresses) or must give new addresses (from the range they can
allocate from). It is not clear to me whether respond to a Rebind with new
addresses or first sending a NoBinding and requiring the client to Request
is better (I like just assigning new addresses on the Rebind since that is
always possible anyway and it is less traffic and work for the client, but
if many servers respond, it could result in several addresses going unused
since the client only accepts one of the server's responses).

I wonder whether the DHC WG might take this on - to specify how redundant DHCPv6
services could or should be built? I think it will be easier than the DHCPv4
failover work and may not require any protocol - just a way of working? But, then
perhaps this is simply left to the server implementers to decide how best to work
and interoperability between several vendors is not required?

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, January 26, 2003 1:31 AM
To: Bernie Volz (EUD)
Cc: [email-masked]
Subject: Re: [dhcwg] questions about dhcpv6-28

>>>>> On Fri, 24 Jan 2003 09:01:24 -0600, 
>>>>> "Bernie Volz (EUD)" <[email-masked]> said:

> The specification is ambiguous about the use of the Server
> Identitifier option.  Section 18.1.3, "Creation and Transmission of
> Renew Messages" of draft-ietf-dhc-dhcpv6-28.txt requires that the
> client include "the identifier of the destination server in a Server
> Identifier option."  However, section 18.2.3, "Receipt of Renew
> Messages", does *not* require that a server discard any Renew messages
> in which the contents of the Server Identifier option does not match
> the DUID of the receiving server.  I think the specification needs to
> be corrected.

BV2> Yes, agreed we should fix 18.2.3. (Perhaps we should even consider
BV2> whether additional rules should be added in section 15.10 on Replies
BV2> to specific messages? Such as Server Identifier must match that sent
BV2> in any "request".)

Hmm, I personally don't see the need for additional text in 15.10, but
it might be helpful if a client implementation identifies an
outstanding request by the pair of "server ID + transaction ID".

> The specification may also require clarification in the case of Rebind,
> when the server should respond with NoBinding only if it has
> authoritative information that there is no binding for the client.
> There may be another alternative, which would  be to allow the client
> to ignore Reply messages (ins response to a Rebind message )with
> NoBinding status, if the client receives another Reply message
> from a server that does find the binding.

BV2> What about just requiring all servers to respond but having the
BV2> client only take the NoBinding from the Server Identifier it last
BV2> used with that binding as being authoritative. I'm not sure how a
BV2> server could know whether it has (or had) authoritative information.

Ralph pointed out to me the possibility of some "magic" between a
primary server and a backup server, which allows those servers to be
synchronized in real time.  I'm not sure how this is realistic,
either, but I'd personally prefer to keep the possibility.

					JINMEI, Tatuya