Subject: RE: -16 rev of DHCPv6 spec

From: Bernie Volz <[email-masked]>
Date: Tue, 28 Nov 2000 10:36:09 -0500

Ralph and others ... here's some comments on the -16 spec.

In general, this looks GREAT! Excellent job!

Sorry that these comments are in no particular order.

- In most of the message headers, there is the 16-byte client-link-local
address. What about dropping the first 64-bits of this (the prefix)? It
would save 8-bytes/packet. This is just a thought - there might be good
reasons NOT to do this. But on the other hand, it would remove the need for
servers/relays to validate that the prefix is the link local - instead, they
pre-append the prefix when they need to use it as a link-local address. So,
if we were to do this, we'd call this 64-bit field "interface ID" or
something similar (at least based on RFC 2373 terminology).

>From RFC 2373, it appears that link local doesn't really consume the full
64-bits before the interface-id, instead only the first 10 bits are really
specified (with the next 54-bits being zero, though it is not clear that is
REQUIRED).

   |   10     |
   |  bits    |        54 bits          |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+

- Section 9.10 calls the message "Server-forward" message. Yet most of the
text uses "Relay-reply". Please fix. Relay-reply is used almost exclusively
in the rest of the text.

- Section 22.2's diagram has a "pref. len". Yet this field is not defined
anywhere in the list of fields. Was this an error in the diagram? Or was
this to be the "prefix length"? If pref. len is prefix length, you might
want to consider what to use as an abbreviation since then pref. could be
"prefix" or "preferred" (as in preferred lifetime).

Also, if this is "prefix length", then the format of address/prefix length
is REVERSED from that used in the Relay-Forward/Server-Forward (see sections
9.9 and 9.10). Might be nice to have it consistent in always having prefix
length/address (or address/prefix length). In RFC 2461, for prefix
advertisements, the prefix appears before the address.

- In section 23.7, the claim is made that "add messages share a comment
fixed message header followed by options." This is not true (unless one
assumes that the fixed message header is the 1-byte msg-type field). See
Section 9.9 and 9.10 as they don't share the common message header.

Might is be wise to consider changing the Relay-forward/Server-forward
messages to use the common header? Though likely most of the fields would be
0's so it may be a waste.

- In section 9.2 and 9.4, it might be best to move the "See sections 14.4
and 15.3 for information ..." under the "preference" definition text. Also,
perhaps some indication that higher values indicate "more" preference to the
server are worth nothing in these descriptions?

- In section 9.5, there is a "P     (unused) MUST be 0" in the definitions
that doesn't belong.

- In section 9.9, shouldn't there be some more details around the
"relay-address"? This address must be carefully chosen by the relay to
reflect the network on which the client is located. As most interfaces are
bound to have many addresses, picking the proper address may be a bit
involved. This will likely be a major issue for relays and the configuration
of DHCP in IPv6 networks. For example, use of the relay's link-local address
for the interface is no good. But, are locally scoped address potentially
legal? Or must this be a fully routable (Internet-routable) address?

- It is not clear why section 9.11 is where it is. Section 9 does say it is
"Message Formats and Identity Associations" but I would think it best to put
the Identity Association in a separate section.

- In section 10.3.1, setting a transaction id is not specified. Implied
action is to set it to 0 (The client sets all other fields to zero).

- In section 10.3.3, there are several mentions of "advertising availability
of IP address" ... how is this done (perhaps there will or is an option that
will provide this information?). Also, if this capability DOES exist, isn't
Ted's Discussion point in section 10.5.2 null and void?

- Finally, there are a bunch of minor typos and like errors. But I've
ignored those for now as I think most of those will get addressed in the -17
draft. If you want me to send my list sometime, let me know.

And I still need to more carefully review section 11 to 17 and thus may have
further comments.

But, again, nice job and I think we're making excellent progress.

- Bernie Volz
  Ericsson DNS & DHCP Development Unit