Subject: DHCPv6 comments

From: Richard Draves <[email-masked]>
Date: Fri, 21 Jan 2000 03:02:10 -0800

So I finally had time to read draft-ietf-dhc-dhcpv6-14.txt. I don't have
access to the list archives at 30,000 feet, so forgive me if these are old
issues. I'm going to send separate messages on the extensions draft and
responding to Thomas's 12/23 "DHCPv6 address allocation model" email.

This protocol is really different from DHCPv4 (from what I've seen of DHCPv4
in packet traces), too bad it doesn't have a different name.

Making the relay explicit in the protocol introduces lots of complexity.
Here's an idea:

The relay should only participate in Solicit/Advertise messages. Once the
client discovers server/relay addresses, the client and the server
communicate directly with each other. If the client's link-local address is
the IP source or destination and the server is off-link (relay address !=
server address), then a routing header is used to route the packet via the
relay.

This would simplify the protocol a lot. Among other things, the client and
server could potentially use end-to-end IPsec instead of using one-off
DHCPv6 security hacks.

Some (fatal???) complications with this idea:
- Routing header processing when the IP source is link-local.
draft-ietf-ipngwg-icmp-v3-00.txt is unclear - should routing header
processing generate the "beyond scope of source address" error?
- IPsec operation in the server, with off-link link-local client addresses

Another issue - servers don't have access to client link-layer addresses. Is
the assumption that administrators will be happy to use link-local addresses
instead as a good key to identify clients? Will administrators feel that
they are losing something here?

Misc specific comments (quotations from the draft are indented):

      02 DHCP Advertise

         The DHCP Advertise is an IP unicast message sent by a DHCP
         Agent in response to a client's DHCP Solicit message.

Why not allow for multicast Advertise messages, so when a lot of clients are
booting one Advertise can suffice for them all, or least everyone on a link.
(See ND Router Advertisements.)

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     saved agent-address                       |
     |                   (if present, 16 octets)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I finished reading the dhcpv6 draft and was in the middle of the extensions
draft before I realized what "if present" meant. I thought at first that
when a field was "not present" it was supposed to be sent as zeroes. I think
I got confused because none of the other v6 protocols have optional fields
like this in their headers. This could use more explanation.

      C          If set, the client requests that all servers receiving
                 the message deallocate the resources associated with
                 the client.  If set, the client SHOULD provide a saved
                 agent-address to locate the clients binding by a
                 server.

Shouldn't this be MUST, since the C bit is controlling the presence of the
agent-address field? This was also a source of my confusion about "if
present".

   relay MUST NOT be a link-local address.  In situations where there
   are no routers sending Router Advertisements, then a DHCP server MUST
   be configured on the same link as prospective clients.  The DHCPv6
   protocol design does not apply to situations where the client is
   unable to route messages to a server not on the same link.

The last sentence does not convey the intended meaning. It is possible to
use DHCPv6 when the client is unable to route messages to a server not on
the same link, just put the DHCPv6 server on the same link as the client.

   If a client reboots and does not have a valid IP address, it SHOULD
   set the `C' bit in the DHCP Solicit message it sends when restarting.
   By setting the `C' bit in the solicitation, a client requests that
   all the DHCP servers that receive the solicitation should clean up
   their client records that match its link-local address.

The client link-local address does not uniquely specify the client.

   If a client sends a DHCP Solicit message after it reboots, the
   solicitation SHOULD be delayed after reception of the first Router
   Advertisement [14] message (see section 5.8), by at least some random
   amount of time between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY (see
   section 8).  This delay is intended to help stagger requests to
   DHCP servers (and avoid link-layer collisions) after a power outage
   causes many nodes to reboot all at once.  Each subsequent DHCP
   Solicit message that is issued before receiving an advertisement
   MUST be delayed by twice the amount by which the previous DHCP
   Solicit message was delayed, plus a small random delay between
   MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY seconds.

Is there a limit to the number of retransmissions? A limit to the backoff?

   retransmit according to the rules in Section 8.  If (after following
   those rules) the client has not received a Reply message, it SHOULD
   start over again by multicasting a new DHCP Solicit message to find a
   different server.

What if the client already knows about other servers from its original
solicit?

   6.2. Sending DHCP Advertise Messages
   Upon receiving and verifying the correctness of a DHCP Solicit
   message, a server constructs a DHCP Advertise message and transmits
   it on the same link as the solicitation was received from.  When the
   solicitation is received at the All-DHCP-Servers multicast address,
   the server SHOULD delay the transmission of its advertisement
   for a random amount of time between SERVER_MIN_ADV_DELAY and
   SERVER_MAX_ADV_DELAY (see section 8).

So this delay is not done when the solicitation is received at the
All-DHCP-Agents multicast address???

   7.2. DHCP Request Message Processing
   When a relay receives a DHCP Request message, it SHOULD check that
   the IP source address in the IP header is a link-local address,
   that the link-local address matches the link-local address field in

Should the same checks be performed when a relay receives a DHCP Solicit?

   All of the fields of DHCP Request message transmitted by the relay
   are copied over unchanged from the DHCP Request received from the
   client.  Only the fields in the IP header will differ from the
   packet received from the client.  All relays MUST send DHCP Request

And the UDP checksum will differ.

   8. Retransmission and Configuration Variables
   When a client does not receive a DHCP Reply in response to a pending
   DHCP Request, the client MUST retransmit the identical DHCP Request,
   with the same transaction-ID, to the same server again until it can
   be reasonably sure that the server is unavailable and an alternative
   can be chosen.  The DHCP server assumes that the client has received

Unless N bit was set in a Reconfigure that caused the Request.

The default settings for the parameters will cause perceptible delay in
DHCPv6 address allocation relative to address auto-configuration. Can't they
be tuned to make DHCP work faster in the common case?

      CLIENT_ADV_WAIT

Why 2s? An analogous ND value (MAX_RTR_SOLICITATION_DELAY) is 1s.

      SERVER_MIN_ADV_DELAY / SERVER_MAX_ADV_DELAY

Why 100ms / 1s? The analogous range for Router Advertisements is 0 / 500ms.
Conflicting descriptions of which multicast addresses are relevant.

      REPLY_MSG_TIMEOUT / REQUEST_MSG_MIN_RETRANS

So it will be ~ 1/2 hour before a client gives up and tries another server
when it doesn't get a Reply to a Request???

      RECONF_MMSG_MIN_RESP

Why is this not zero?

      RECONF_MULTICAST_REQUEST_WAIT

         The time a client should wait before retransmitting a Request
         message in reponse to a retransmitted multicast Reconfigure
         message.

This is a very confusing / incorrect description of this variable.

   MIN_SOLICIT_DELAY / MAX_SOLICIT_DELAY

Why are these values so large compared to the analogous ND values? In
general, why is the solicitation algorithm so much more cautious than the ND
algorithm?

   B. Related Protocol Specifications

Doesn't mention reference [15]!

Thanks,
Rich

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 21 Jan 2000 15:02:32 -0800

Hello again Richard,

> in packet traces), too bad it doesn't have a different name.

That has to be considered a matter of opinion.  Most of the differences
arise from things that are different between IPv6 and IPv4 (e.g.,
link-local
addresses, multihomed hosts).

> Making the relay explicit in the protocol introduces lots of complexity.

Hmmm.... I always thought it made things more definite and (in
combination
with the use of link-local addresses) a lot easier.  As I remember,
dealing
with 0.0.0.0 as a destination IP address wasn't exactly the world's most
elegant design.

> server could potentially use end-to-end IPsec instead of using one-off

Y'know, I just hate it when somebody calls my elegant security
breakthrough a "hack".  Maybe I'm too sensitive about these things.

> - IPsec operation in the server, with off-link link-local client addresses

These complications amount to an objection that is more significant
than your issues with the current design.

> they are losing something here?

I do not understand what's wrong here.  How would it help if every
server had a network interface to every link, so that it could detect
link-local addresses in client packets?  I haven't heard any complaints
from any administrators!

> (See ND Router Advertisements.)

I don't have a terrible problem with this, but I also don't want
to open that can of worms just now.  My mantra is "get it finished,
don't look at any additional features".

Ask us again in a few weeks when we've finally gone through last call.
We've had enough hints from important people to stop making new
features.

I'm sure this can be done.  Thanks for pointing out a possible
source of confusion.

> The client link-local address does not uniquely specify the client.

This is true.  We have discussed this many times.  But, it is also
true that in many common situations, the link-local address DOES
uniquely identify the client, and we wanted to allow for the possibility
of using it that way whenever the local administration wished to do so.

> What if the client already knows about other servers from its original

You are right that a client should be able to use the other servers.
I think this language should be changed to make that clear.
On the other hand, if the information is very, very old, the
client may suffer some additional unwanted latency by using
stale information.  Should there be a timeout?  How long?

> All-DHCP-Agents multicast address???

It only has to be done at one or the other.

> Should the same checks be performed when a relay receives a DHCP Solicit?

I'm not certain, but I think the checks are not necessary
in this case.

> And the UDP checksum will differ.

That is a good point!  I think the language in the above
paragraph needs to be revised to reflect this point.

> Unless N bit was set in a Reconfigure that caused the Request.

All the stuff about the 'N' bit is going to be stale after the
new revision is issued by Mike.

> be tuned to make DHCP work faster in the common case?

I already lost that argument.  I agree with you, though.

Regarding the other parameter settings, I will leave the
discussion to a later date.  However, I should note that we
haven't had much discussion about them, and probably some of
the values should be changed to reflect your observations.

> Doesn't mention reference [15]!

Good point...

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 23 Jan 2000 16:40:42 +0100

In your previous mail you wrote:

=> -14 I-D has many problems which were solved in the mailing list...

=> I agree, the main (and unsolved) problem of DHCPv6 is its first four
letters (:-).

=> the relay function is needed because a box can start with only
a link-local address and no server on the link. A relay is a small
piece of code then one can find to have a server with a lot of relays
easier than a lot of relays + distributed server management tool.

   Here's an idea:

=> this doesn't work (ie. you can't use a link-local address in a
routing header to go outside the link).

=> the reason DHCP must have security hacks is simply because IPSec uses
destination addresses (the thing you get with DHCP).

=> yes or it should drop the packet...

=> this is not secure by default because link-local addresses are ambiguous
(ie. you can have two off-link clients with the same address on different
links).

Regards

[email-masked]

PS: I expect the new I-Ds will be available soon?

---

From: Ted Lemon <[email-masked]>
Date: Sun, 23 Jan 2000 10:56:37 -0500

> => -14 I-D has many problems which were solved in the mailing list...

Dare I say it?   A problem that has been solved on the mailing list
but whose solution is not reflected in the draft has not in fact been
solved - it has merely been discussed.

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Sun, 23 Jan 2000 11:10:13 -0500

>solved - it has merely been discussed.

Ted - thanks for making that clarifying (and correct) distinction.  I've 
been in touch with the authors, who expect to post a summary of solutions 
developed in mailing list conversations.  They plan to express the 
solutions formally in a new draft within a couple of weeks.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Sun, 23 Jan 2000 11:28:54 -0500

> solutions formally in a new draft within a couple of weeks.

Cool!   :')

			       _MelloN_

---

From: Thomas Narten <[email-masked]>
Date: Wed, 26 Jan 2000 16:53:18 -0500

> server address), then a routing header is used to route the packet via the

For one thing, this would require changing existing (non-DHCP) specs
and router implementations. I.e., the current semantics of the routing
header don't say anything about what to do if the destination address
by itself is insufficient to deterimine which outgoing interface (or
more generally which scope) the destination address corresponds to. In
the case of DHCP, where the client address is link-local, it isn't
clear which outgoing interface to send the packet on.

In the case of DHCP relays, the obvious thing to do is send it out on
the interface corresponding to the address of the relay agent in the
routing header. But this is not something that existing specs say to
do or even if it is the right general semantic to have.

Also, my recollection of long-ago discussion was that forwarding
packets beyond the scope of their source addresses was not something
to be encouraged, as this proposal would.

The idea of using a general-purpose technique rather than something
DHCP-specific is certainly appealing though!

Thomas