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

[Ralph Droms <[e-mail]>]

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.