Subject: RE: -16 rev of DHCPv6 spec (Part 2)

From: Bernie Volz <[email-masked]>
Date: Tue, 28 Nov 2000 12:14:34 -0500

Ralph and others:

Had some more time to finish the document review. Here's some additional
comments:

- In section 8.3, "Relays receive the Solicit and Request messages ...",
they also receive Release messages (and perhaps others in the future).

- In section 11.4.2, if the client fails to get a response from Request
messages, should it fall back to the Solicit state or perhaps use any
'cached' information from previous Solicits to contact a lower preference
server?

I would think that the clients should not "stop" requesting addresses just
because they can't contact a server. If an application requests an address,
it should have a means to specify some timeout or other means to abort the
request. If the client has just booted and is trying to get addresses, it
should continue to try forever (perhaps backing off in how frequently it
does Solicit / Request sequences).

- In section 11.4.3, where is this 'status' field? Isn't this to be carried
in an option? Also, if the request is successful, does a status need to be
sent (if in an option)? Also, what's the impact if there are multiple IAs
specified in the request and some are successful and others aren't (for
whatever reason?)?

- In section 11.4.4, what's the "(The client always forwards Release
messages to the server through a relay; see section 11.5)" all about? 11.5
provides no useful information in this regard. Also, what if there is no
relay? Also, should a client always use a link local address when sending a
release? If so that should be stated (in that case a relay is required if
the server is not on the link).

- In section 11.4.5 and 11.4.6, it should state clearly that a client MUST
stop using the addresses when sending a Release (whether or not a Reply is
received).

- In section 11.4.8, add 'send' ... "it may [send] a Request message". And,
drop 'to' in "The server returns [to] IA(s)...".

- In section 11.4.9, what if the 'old' server is not reachable (such as it
was reached via a link-local address and you're now on a different link)? Or
perhaps the server was a scoped address? Shouldn't there be some more
thoughts about this? I think this needs some more consideration about what
the best mechanism to determine what to do is. For example, if there are
Router Advertisements, perhaps the client can determine whether its
'current' addresses are still valid and base a decision on that? If there
are no Router Advertisements, perhaps the client should start at Solicit. If
the same server responds, it can continue using it (regardless of the
preference values)?

Microsoft's Windows 2000 client uses the router address - it 'pings' the
router address (with a hop limit of 1 I suspect) and if it gets a response,
it assumes it is still on the same subnet. This is a nice approach and
generally works very well.

- In section 11.4.10, add 'may' ... "The server [may] remove addresses from
the IA ...".

Also, "If the server does not assign an explicit value to T1 or T2 ...". How
is that done? The option has fixed fields for T1 and T2. Perhaps you're
allowing these to have some magic value (such as 0 or all bits 1?)? If so,
that isn't mentioned in the option text (section 22.2).

- In section 11.5.1, some thought might be needed regarding the address
issue (see previous set of comments). For example, depending on the server
the request is forwarded to, the relay-address / prefix length might need to
be different. So, the text is probably a bit too simplistic. Again, we
should discuss this issue.

- In section 11.6.3, again the 'status' field is discussed. Where is it in
the message? An option?

Also, the forward (relay) message names here don't match other sections.

- In section 12, I think you should be staying if new prefixes are added to
a link. As you indicating, adding new links is meaningless (if a client gets
a new link, it would need to start IPv6 on that link and hence would do DHCP
if so specified). The issue for servers and Reconfigures is if new prefixes
are added (or old ones removed or depreciated).

- In section 12.4.4, some text should be added about having the server
'pace' unicast Reconfigure-Init messages. If there are 100's of clients on a
link, the server should send the 100's of reconfigure-init messages 'slowly'
(perhaps 10/second or some such number).

Also, using the transaction-id from the Reconfigure-Init message in Request
messages can cause problems (collisions) with client generated values. While
you might argue that it doesn't matter, it may in some instances and
therefore we should be careful about this. One solution might be to have a
'Reconfigure-Init Transaction ID' option to carry that transaction ID and
thus the number space between client and server don't collide. Also, this
aids the server in understanding that this Request was generated by a
'Reconfigure-Init'.

- In section 12.4.5, what about Multicast implications? If the
Reconfigure-Init is multicast, should a server retransmit it? If so, clients
might need to remember recent Reconfigure-Init transaction ids so they know
if they've received a duplicate? Or is the server restricted to ONE
multicast message and then needs to switch to unicast?

This also applies to section 12.5.1 - check for duplicates?

- In section 12.5.2, does the client need to pause under all cases before
sending the Request? Or just if multicast received.

- In section 12.5.4, isn't this just the usual Reply processing?

- In section 14.2, more details on what is and is not cachable should be
added.

- In section 14.3, I see there being 3 sources of values:
	- Defaults (per RFC)
	- Server (per option)
	- Client configuration
How do these interact? Which as priority over the other. I think it is clear
that the Defaults are lowest on the food chain. But, should a client's
configuration prevent using server supplied values? Perhaps this is a client
policy issue?

- In section 14, would an additional section on how to generate IAs be
useful? We had long discussions about this on the mailing list and there
really isn't much said about this in the specification.

- In section 15, would an additional section on how to assign addresses be
appropriate? I'm not saying we should force servers to adhere to a
convention, but what about providing some guidelines? Are servers supposed
to use the EUI-64 identifier or not when generating addresses? ...

- In sectin 17.4, what about considering an option to carry this
information? That way, servers MAY use it to change their behavoir but they
need not rely on it. Clients MAY supply it if they want servers to consider
this? I'm happy if the discussion decides that this is a REQUIRED piece of
information (but then I'd still put it in an option).

Thats it for now.

- Bernie Volz
  Ericsson DNS & DHCP Development Unit