Subject: [dhcwg] draft-ietf-dhc-dhcpv6-stateless-03.txt published

From: Ralph Droms <[email-masked]>
Date: Sun, 21 Dec 2003 13:45:51 -0500

I've submitted draft-ietf-dhc-dhcpv6-stateless-03.txt for publication.  This
revision includes changes in response to comments from the IESG.  The most
important changes are to section 5:

* text that describes use of Information-request/Reply message exchange when
   a host moves to a new link has been deleted
* text added referring to draft-ietf-dhc-dna-ipv4-04 (which addresses the
   problem of link attachment in IPv4) and to work on defining mechanism to
   control host use of Information-request/Reply message exchange (e.g.,
   draft-chown-dhc-stateless-dhcpv6-renumbering; note that no specific drafts
   are cited in draft-ietf-dhc-dhcpv6-stateless-03.txt)

I've included the revised section and an HTML diff of the -02 and -03 revs
of draft-ietf-dhc-dhcpv6-stateless.

Please respond with comments...

- Ralph

=====

    5. Implementation of Stateless DHCP

       The client indicates that it is requesting configuration
       information by sending an Information-request message that
       includes an Option Request option specifying the options that it
       wishes to receive from the DHCP server.  For example, if the
       client is attempting to obtain a list of DNS recursive name
       servers, it identifies the DNS Recursive Name Server option in the
       Information-request message. The server determines the appropriate
       configuration parameters for the client based on its configuration
       policies and responds with a Reply message containing the
       requested parameters.  In this example, the server would respond
       with DNS configuration parameters.

       As described in section 18.1.5 of RFC 3315, a node may include a
       Client Identifier option in the Information-request message to
       identify itself to a server, because the server administrator may
       want to customize the server's response to each node, based on the
       node's identity.

       RFC 3315 does not define any mechanisms through which the time at
       which a host uses an Information-request message to obtain updated
       configuration parameters can be controlled.  The dhc WG has
       undertaken the development of such a mechanism or mechanisms which
       will be published as Standards-track RFC(s).

       RFC 3315 also does not provide any guidance about when a host
       might use an Information-request message to obtain updated
       configuration parameters when the host has moved to a new link.
       The dhc WG is reviewing a related document, "Detection of Network
       Attachment (DNA) in IPv4" [8], which describes how a host using
       IPv4 can determine when to use DHCPv4.  Either the dhc WG or a WG
       formed from the dna BOF will undertake development of a similar
       document for IPv6.

       [8]  Aboba, B., "Detection of Network Attachment (DNA) in IPv4",
            draft-ietf-dhc-dna-ipv4-04 (work in progress), October 2003.

=====
   5. Implementation of Stateless DHCP

       The client indicates that it is requesting configuration
       information by sending an Information-request message that
       includes an Option Request option specifying the options that it
       wishes to receive from the DHCP server.  For example, if the
       client is attempting to obtain a list of DNS recursive name
       servers, it identifier identifies the DNS Recursive Name Server 
option in the
       Information-request message. The server determines the appropriate
       configuration parameters for the client based on its configuration
       policies and responds with a Reply message containing the
       requested parameters.  In this example, the server would respond
       with DNS configuration parameters.

    A As described in section 18.1.5 of RFC 3315, a node uses the may include a
       Client Identifier option in the Information-request message to
       identify itself to a server, because the server administrator may
       want to customize the server's response to each node, based on the
       node's identity.

    Whenever

       RFC 3315 does not define any mechanisms through which the time at
       which a client may have moved host uses an Information-request 
message to a new link, the obtain updated
       configuration parameters obtained for the interfaces on that link 
may no longer can be
    appropriate for the link to which controlled.  The dhc WG has
       undertaken the client is attached.  Examples development of times 
such a mechanism or mechanisms which
       will be published as Standards-track RFC(s).

       RFC 3315 also does not provide any guidance about when a client may 
have host
       might use an Information-request message to obtain updated
       configuration parameters when the host has moved to a new link include:

    o  The client reboots.

    o link.
       The client dhc WG is physically connected to reviewing a wired 
connection.

    o  The client returns from sleep mode.

    o  The client using related document, "Detection of Network
       Attachment (DNA) in IPv4" [8], which describes how a wireless 
technology changes access points.

    In any situation host using
       IPv4 can determine when a client may have moved to use 
DHCPv4.  Either the dhc WG or a new link, WG
       formed from the
    client initiates an Information-request/Reply message exchange. dna BOF 
will undertake development of a similar
       document for IPv6.

---

From: "Bernie Volz" <[email-masked]>
Date: Mon, 22 Dec 2003 14:56:09 -0500

Ralph:

OK by me.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ralph
Droms
Sent: Sunday, December 21, 2003 1:46 PM
To: [email-masked]
Subject: [dhcwg] draft-ietf-dhc-dhcpv6-stateless-03.txt published

- Ralph

=====

=====

      The client indicates that it is requesting
configuration
      information by sending an
Information-request message that
      includes an Option Request option
specifying the options that it
      wishes to receive from the DHCP
server.  For example, if the
      client is attempting to obtain a list of
DNS recursive name
      servers, it
identifier
identifies the DNS Recursive Name Server option in the
      Information-request message. The server determines the appropriate
      configuration parameters for the client based on its configuration
      policies and responds with a Reply message containing the
      requested parameters.  In this example, the server would respond
      with DNS configuration parameters.
 
   A As described in section 18.1.5 of RFC 3315, a node uses the may include
a
      Client Identifier option in the Information-request message to
      identify itself to a server, because the server administrator may
      want to customize the server's response to each node, based on the
      node's identity.
 
   Whenever
 
      RFC 3315 does not define any mechanisms through which the time at
      which a client may have moved host uses an Information-request message
to a new link, the obtain updated
      configuration parameters obtained for the interfaces on that link may
no longer can be
   appropriate for the link to which controlled.  The dhc WG has
      undertaken the client is attached.  Examples development of times such
a mechanism or mechanisms which
      will be published as Standards-track RFC(s).
 
      RFC 3315 also does not provide any guidance about when a client may
have host
      might use an Information-request message to obtain updated
      configuration parameters when the host has moved to a new link
include:
 
   o  The client reboots.
 
   o link.

 
   In any situation host using
      IPv4 can determine when a client may have moved to use DHCPv4.  Either
the dhc WG or a new link, WG
      formed from the
   client initiates an Information-request/Reply message exchange. dna BOF
will undertake development of a similar
      document for IPv6.