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

["Bernie Volz" <[e-mail]>]

Ralph:

 

OK by me.

 

- Bernie

 

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

 

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.