Subject: [dhcwg] Re: Last Call: 'A Guide to Implementing Stateless DHCPv6 Service' to Proposed Standard

From: Pekka Savola <[email-masked]>
Date: Mon, 3 Nov 2003 14:27:26 +0200 (EET)

On Thu, 30 Oct 2003, The IESG wrote:
> The IESG has received a request from the Dynamic Host Configuration WG to 
> consider the following document:
> 
> - 'A Guide to Implementing Stateless DHCPv6 Service'
>    <draft-ietf-dhc-dhcpv6-stateless-01.txt> as a Proposed Standard

Comments below.  The document needs a revision, but does not have, AFAICS,
major issues to deal with, except for better considerations on how DHCP
relays work (or don't :-) in the stateless/full DHCP model.. that is, do 
you have "stateless relays" and "full relays", and potential problems to 
stateful services stemming from that or not.

Note: IMHO, DHCP spec should have been the other way around, stateless
first, adding stateful parts on top of that as an extension.  Can't be
changed now, but might be something to consider when going to Draft
Standard or the like.

substantial
-----------

1) the spec is not sufficiently clear how the relays behave in a mixed world
of stateless/stateful DHCP service.  That is, would deploying a
stateless-only relay (if such a thing is possible?) harm the stateful DHCP
clients?  Is the implementation of a relay any different for full/stateless
DHCP service, etc. ?:

   The operation of relay agents is the same for stateless and stateful
   DHCPv6 service.  The operation of relay agents is described in the
   DHCPv6 specification.

2) there are a few remnants on the spec which talk about "DNS configuration
parameters".  One should be more generic than that; these are listed in the
editorials section.

3) I'm not familiar with DHCPv6 spec, but I'd like a confirmation that the
last sentence is actually true, and to reword it for clarity if so:

   A DHCP server that is only able to provide stateless configuration
   information through an Information-request/Reply message exchange
   discards any other DHCP messages it receives. Specifically, the
   server discards any messages other than Information-Request or
   Relay-forward it receives, and the server does not participate in any
   stateful address configuration messages exchanges.  If there are
   other DHCP servers that are configured to provide stateful address
   assignment, one of those servers will provide the address assignment.

==> that is, do relays really *flood* these messages to all the DHCPv6
servers they know, so that if one doesn't process the request but silently
ignores it, the others can step up and handle the job?  See also the point
1) above.

editorial
---------

   the node's message with a Reply message that carries the DNS
   configuration parameters.  The Reply message from the server can

==> s/DNS//

   1-4:   give an introduction to DHCPv6 and an overview of DHCP message
      flows

==> some of those flows are redundant to Stateless DHCPv6 operation,
though.. :-)

5. Implementation of stateless DHCP
                                                                                                   
==> s/stateless/Stateless/

   DNS configuration information, it includes either or both of the DNS
   configuration options in the Information-request message.
 
==> one should list here the two kinds of DNS config options, or reword the
sentence.

5.1 Messages required for stateless DHCP
                                                                                                   
==> s/r/R/, s/s/S/

   Clients and servers implement the following messages for stateless
   DHCP service; the section numbers in this list refer to the DHCPv6
   specification:

==> many sections are missing the "the section ..." blurb.  It might make
sense to add something at the end of section 5, like, "In the following
subsections, the section numbers used refer to the DHCPv6 specification".

   Information-request: sent by a DHCP client to a server to request DNS
      configuration parameters (sections 18.1.5 and 18.2.5)
                                                                                                   
   Reply:               sent by a DHCP server to a client containing the
      DNS configuration parameters (sections 18.2.6 and 18.2.8)

==> s/DNS// (2 cases)

5.2 Options required for stateless DHCP service
                                                                                                   
==> s/r/R/, s/s/S/, s/service// (remove service for consistency with other
5.x)

5.3 Options used for configuration information
                                                                                                   
==> s/u/U/, s/c/C/, s/i/I/

5.4 Other options used in stateless DHCP
                                                                                                   
==> s/o/O/, s/u/U/, s/s/S/

   DHCP service; the section numbers in this list refer to the DHCPv6
   specification, RFC 3315>:

==> see above, but if keeping it here, make consistent with the rest

      22.2).  Clients are not required to send this option; servers send
      the option back if included in a message fro ma client
                                                                                              
==> s/fro ma/from a/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Thu, 13 Nov 2003 07:57:34 -0500

Pekka - thanks for your review.  My responses to your comments are inline.

- Ralph

>changed now, but might be something to consider when going to Draft

The functions referenced in draft-ietf-dhc-dhcpv6-stateless-01.txt are
all completely defined in RFC 3315.  From the point of view of the
DHCPv6 relay agent, there is no difference between the subset of
RFC 3315 referred to as "stateless DHCPv6" and the full set of
functions in  RFC 3315.

More concisely, there are just "DHCPv6 relay agents" that work with both
full RFC 3315 clients and stateless-only clients...

>parameters".  One should be more generic than that; these are listed in the

OK...

>ignores it, the others can step up and handle the job?  See also the point

Yes, a relay agent forwards a copy of each message it receives from a client
to each of the servers in its configured list of servers.

>    configuration parameters.  The Reply message from the server can

OK.

>==> some of those flows are redundant to Stateless DHCPv6 operation,

OK, would a more precise list (e.g., individual subsections rather than
simply "1-4") be helpful?

>==> s/stateless/Stateless/

OK.

>==> one should list here the two kinds of DNS config options, or reword the

OK.

>5.1 Messages required for stateless DHCP

OK.

>       DNS configuration parameters (sections 18.2.6 and 18.2.8)

OK.

>==> s/r/R/, s/s/S/, s/service// (remove service for consistency with other

OK

>==> s/u/U/, s/c/C/, s/i/I/

OK

>==> s/o/O/, s/u/U/, s/s/S/

OK (more precisely, I'll make sure the capitalization is consistent
in section headers throughout)

>==> see above, but if keeping it here, make consistent with the rest

OK

>       the option back if included in a message fro ma client

OK

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Nov 2003 16:13:41 +0200 (EET)

> Pekka - thanks for your review.  My responses to your comments are inline.

Thanks.. just a few responses inline.

(Btw -- does the case I mentioned off-line about first-hop router being a 
stateless DHCP server, but acting as DHCP relay for stateful DHCP need to 
be explicitly mentioned -- I guess so?)

> full RFC 3315 clients and stateless-only clients...

Right.  I think this should be spelled out in the stateless document a bit 
better, that the stateless DHCP has to implement "full" relay service, 
which is of course rather lightweight in itself (it has no state, I 
believe).

> to each of the servers in its configured list of servers.

Are all the responses equally flooded back to the relay as well?  Does the 
relay pick and respond to the hosts with first or all the information?

(Just trying to clarify, this probably doesn't need changes in the spec.)

> simply "1-4") be helpful?

That might not hurt.  However, what I was referring to was that e.g. 
"message flows" or sections like do not really reflect the stateless DHCP 
operation...

---

From: Ralph Droms <[email-masked]>
Date: Fri, 14 Nov 2003 08:05:44 -0500

>be explicitly mentioned -- I guess so?)

Recognizing that a network element can be both a server and a relay
agent has evolved in DHCPv4 without any explicit text - there's nothing
in the DHPCv4 specifications that disallows such behavior.

If there is consensus that text allowing a network element to act
as both a DHCPv6 server and relay agent would be useful, we can add
it to this doc...

>which is of course rather lightweight in itself (it has no state, I

I would rather add text like:

   This document does not apply to the behavior of DHCPv6 relay agents.

>Are all the responses equally flooded back to the relay as well?

Yes - in this regard a DHCPv6 relay agent works the same as a
DHCPv4 relay agent.

>   Does the

No.

OK.

- Ralph

---

From: Tim Chown <[email-masked]>
Date: Fri, 14 Nov 2003 16:06:45 +0000

>    <draft-ietf-dhc-dhcpv6-stateless-01.txt> as a Proposed Standard

Wrt recent exchanges on the dhcwg list, are we concerned that there is
no mechanism in stateless DHCPv6 for the DHCPv6 server to inform DHCPv6
clients of renumbering events to DNS or NTP servers (for example) where
the clients are using stateless autocinfiguration (RFC2462) for address
assignment and DHCPv6 (stateless) for options (DNS, NTP, ...).

If the clients use DHCPv6 for address assignment, the DHCPv6 server could
use its IP lease information to unicast the Reconfigure message, but in
a stateless-only DHCPv6 server this client information would presumably
not be available.

The current solution seems to be that clients must poll for changes, which
is not ideal, but which may suffice in some cases.

Tim

---

From: "Bernie Volz" <[email-masked]>
Date: Sat, 15 Nov 2003 12:48:23 -0500

DHCPv6 is no different from what we have with DHCPv4. DHCPINFORM in DHCPv4
has no "lease time" or "lifetime" for the parameters obtained. The implied
behavior for DHCPv4, as it should be for DHCPv6, is that when the address is
reassigned (through some other means), the client should naturally assume
that its current configuration parameters are suspect and hence send a new
DHCPINFORM (or DHCPv6 Information-Request).

There is no prohibition against a client issuing (DHCPv6)
Information-Request messages (or DHCPv4 DHCPINFORM) whenever it believes the
previously obtained configuration information may be out of date. Note also
that DHCPv6 servers may send Reconfigure messages as well (though
draft-ietf-dhc-dhcpv6-stateless-01.txt is silent as to whether stateless
clients support this).

When a client detects that it may be on a different network, whether that is
because it has detected a link state change (such as because the network
cable was reconnected), been powered on (such as from a standby state), or
has its address(es) reconfigured through some non-DHCP mechanism (perhaps
via router advertisements), it should take steps to validate its
configuration information.

We probably should have added to RFC 3315 a similar section for
Information-Request as exists for the stateful case (see section 18.1.2,
Creation and Transmission of Confirm Messages).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim
Chown
Sent: Friday, November 14, 2003 11:07 AM
To: [email-masked]; [email-masked]
Subject: [dhcwg] Re: Last Call: 'A Guide to Implementing Stateless DHCPv6
Service' to Proposed Standard

Tim

---

From: Tim Chown <[email-masked]>
Date: Sat, 15 Nov 2003 19:34:25 +0000

> DHCPINFORM (or DHCPv6 Information-Request).

Hi Bernie, thanks for the comments.

I think that in IPv6 we should be trying to incorporate aids to easy(er)
renumbering, for a number of good reasons.  Also in IPv6 networks it is now 
quite probable that many networks will statelessly autoconfigure addresses 
but use stateless DHCPv6 for options (DNS and NTP in particular).  So it's
a bit different to IPv4.

> draft-ietf-dhc-dhcpv6-stateless-01.txt is silent as to whether stateless

But this is the point - the DHCPv6 server can't send a Reconfigure message
to the client, because the client is not using DHCPv6 for stateful address
assignment, only for the DNS/NTP/other options (and so I believe the stateless 
DHCPv6 server won't have a client list to unicast the messages to?).

There could at the very least be a timer for the valid lifetime of the
stateless DHCPv6 options, so that planned ("make before break") renumbering 
as per draft-baker-ipv6-renumber-procedure-01 can be more readily achieved.  
That would not necessarily help with other renumbering events, but it would 
seem useful to have.
 
> configuration information.

I agree you could use a new RA (with O bit set) as a cue to get new DHCPv6 
option information; this has also been suggested on the dhcwg list.  But it
wouldn't include the case where the DNS or NTP server is renumbered within 
the existing network.
 
> Creation and Transmission of Confirm Messages).

I think anything we can add now to make IPv6 renumbering more easy to do
(both compared to IPv4, and because of existing IPv6 limitations like having
no PI address space) should be considered, including a method to deliver a 
stateless DHCPv6 Reconfigure message to clients.

Tim

---

From: Ralph Droms <[email-masked]>
Date: Thu, 20 Nov 2003 09:26:18 -0500

In response to comments from Pekka about the description of the function of
relay agents in providing stateless DHCPv6 service, is there any objection
to adding the following paragraph as the last paragraph in section 3,
"Overview", of draft-ietf-dhc-dhcpv6-stateless-02.txt:

   This document does not apply to the function of DHCPv6 relay agents as
   described in RFc 3315.  A network element can provide both DHCPv6 
service to
   some clients, while relaying messages for other clients to another DHCPv6
   server.  For example, a network element can provide stateless DHCPv6 
service
   to hosts requesting stateless DHCP service, while relaying messages from
   hosts requesting address assignment through DHCPv6 to another DHCPv6 server.

- Ralph