Re: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header

Josh Littlefield <joshl@cisco.com> Wed, 29 August 2001 20:52 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09310; Wed, 29 Aug 2001 16:52:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16361; Wed, 29 Aug 2001 16:50:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15245 for <dhcwg@ns.ietf.org>; Wed, 29 Aug 2001 16:32:59 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08572 for <dhcwg@ietf.org>; Wed, 29 Aug 2001 16:31:36 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-149-95.cisco.com [161.44.149.95]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA06583; Wed, 29 Aug 2001 16:31:09 -0400 (EDT)
Message-ID: <3B8D50D9.D86E9BF7@cisco.com>
Date: Wed, 29 Aug 2001 16:30:17 -0400
From: Josh Littlefield <joshl@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
CC: "'Ralph Droms'" <rdroms@cisco.com>, dhcwg@ietf.org
Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header
References: <66F66129A77AD411B76200508B65AC697B34C2@eambunt705.ena-east.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
Content-Transfer-Encoding: 7bit

Bernie, I agree with your conclusion, but differ with your reasoning. 
Comments inline:

> "Bernie Volz (EUD)" wrote:
> 
> See my comments below (prefixed by BV>).
> 
> Let me also suggest that the previous suggestion by Ted (which I also was
> suggested) to move the "relay-address" into an option is probably not so
> good.
> Consider ... how does the relay know on which interface to send the client
> the
> Reply? The only way it could get this without the option is by getting the
> 
> destination address from the IPv6 header of the Relay-Reply.

I believe if the relay is using the simple API and it must specify the right
source address, then the relay will need to send through a socket which is
bound to the desired local address.  I believe it will also receive its
response through that bound socket, so learning the responses packet's
destination address is accomplished by noticing the socket through which it
arrived.  So, its doable with the simple API, though I think its a bit more
complexity than you'd want relays to have to implement.

As you note below, if using the advanced API, then specifying the source
address on sending and learning the destination address on receiving is
easier, and is almost as easy as writing a the relay's local address into a
fixed place in the packet, but not quite.

I think the explicit specification of a relay-address is needed in cases
where either the relay has no global address on the proper interface (and
thus needs to indicate a prefix-only address, which should work just fine),
or where specifying the source address may complicate the packet's route out
of the relay (this is speculation).  If a relay must detect one of these
conditions, then it complicates the relay, or encourages relay authors to
opt for the safer solution and always use the option (in which case it isn't
optional in a practical sense).

I think those are the technical considerations.  I think I'd have the
relay-address always present (not move it to an option) for relay agent
implementation simplicity.

> While this is
> likely
> much more possible with the IPv6 socket API, it really isn't that easy if
> one
> considers the more restrictive IPv4 socket API (recvfrom only returns
> source
> info, not destination info). I ran into this issue when I received the end
> of
> Ralph's text (section 16.2). I have no problem if we want to gamble on
> this feature
> being available on all IPv6 stacks (to obtain the IPv6 destination
> address).
> I added this comment after making many of the comments about the changes
> needed to
> make this an option below. So, depending on what we decide, the comments
> below
> regarding making this an option may need to be ignored.
> 
> - Bernie
> 
> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]
> Sent: Tuesday, August 28, 2001 4:06 PM
> To: dhcwg@ietf.org
> Subject: [dhcwg] Changes to remove "client-link-local-address" from the
> DHCPv6 header
> 
> I've completed the changes to remove the client-link-local-address
> field from the DHCP message header.  Relay agents and servers will now
> use the source address from the IP header to reply to client messages.
> 
> The changes include:
> 
> * Message format and descriptions in section 8 to remove the
>   client-link-local-address field
> * Relay agent message format and descriptions in section 9 to
>   accommodate the client-return-address field
> * Address selection described in section 12 to allow for unicast
>   client messages
> * The description of client behavior in sections 13 and 14
>   to remove the use of the client-link-local-address field and to
>   specify that the client must send the message through the interface
>   to be configure, to correctly set the source address in the IP
>   header
> * The description of server behavior in sections 13 and 14 to remove
>   the use of the client-link-local-address and change the format of
>   the relay agent messages
> * The description of relay behavior in section 15 based on the new
>   relay agent message format
> 
> Note that the relay agent message has to include information about:
> 
> 1. The return address to which the server should send the Relay-reply
>    message
> 2. A link identifier/subnet selector that the server uses to select
>    configuration information for the client
> 3. An interface identifier and return address for the client that the
>    relay agent uses to forward the message from the server back to the
>    client
> 
> In DHCPv4, all of these functions are supplied by 'giaddr'.  However,
> the source address from the IP header isn't sufficient (which we had
> discussed using for DHCPv6), because it may be awkward or impossible
> (and, usually suboptimal) to force the message from the relay agent to
> be sent to the server through the interface on which the message from
> the client was received.  So, I've retained the relay-address field
> and added a client-return-address field in the Relay-forward for
> 2. and 3., and specified that the server use the source address from
> the IP header for 1.
> 
> The text affected by these changes is included below.  Please review
> and follow up with comments.
> 
> - Ralph
> 
> =====
> 
> 8. Message Formats
> 
>    Each DHCP message has an identical fixed format header; some messages
>    also allow a variable format area for options.  Not all fields in
>    the header are used in every message.  In this section, every field
>    is described for every message and fields that are not used in a
>    message are marked as "unused".  All unused fields in a message MUST
>    be transmitted as zeroes and ignored by the receiver of the message.
> 
>    The DHCP message header:
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |    msg-type   |               transaction-ID                  |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                                                               |
>      |                         server-address                        |
>      |                          (16 octets)                          |
>      |                                                               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                                                               |
>      .                            options                            .
>      .                          (variable)                           .
>      |                                                               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 8.1. DHCP Solicit Message Format
> 
>       msg-type         SOLICIT
> 
>       transaction-ID   An unsigned integer generated by the client used
>                        to identify this Solicit message.
> 
>       server-address   (unused) MUST be 0
> 
>       options          See section 18.
> 
> 8.2. DHCP Advertise Message Format
> 
>       msg-type         ADVERTISE
> 
>       transaction-ID   An unsigned integer used to identify this
>                        Advertise message.  Copied from the client's
>                        Solicit message.
> 
>       server-address   The IP address of the server that generated
>                        this message.  If the DHCP domain crosses
>                        site boundaries, then this address MUST be
>                        globally-scoped.
> 
>       options          See section 18.
> 
> 8.3. DHCP Request Message Format
> 
>       msg-type         REQUEST
> 
>       transaction-ID   An unsigned integer generated by the client used
>                        to identify this Request message.
> 
>       server-address   The IP address of the server to which the this
>                        message is directed, copied from an Advertise
>                        message.
> 
>       options          See section 18.
> 
> 8.4. DHCP Confirm Message Format
> 
>       msg-type         CONFIRM
> 
>       transaction-ID   An unsigned integer generated by the client used
>                        to identify this Confirm message.
> 
>       server-address   MUST be zero.
> 
>       options          See section 18.
> 
> 8.5. DHCP Renew Message Format
> 
>       msg-type         RENEW
> 
>       transaction-ID   An unsigned integer generated by the client used
>                        to identify this Renew message.
> 
>       server-address   The IP address of the server to which this Renew
>                        message is directed, which MUST be the address
>                        of the server from which the IAs in this message
>                        were originally assigned.
> 
>       options          See section 18.
> 
> 8.6. DHCP Rebind Message Format
> 
>       msg-type         REBIND
> 
>       transaction-ID   An unsigned integer generated by the client used
>                        to identify this Rebind message.
> 
>       server-address   MUST be zero.
> 
>       options          See section 18.
> 
> 8.7. DHCP Reply Message Format
> 
>       msg-type         REPLY
> 
>       transaction-ID   An unsigned integer used to identify this Reply
>                        message.  Copied from the client's Request,
>                        Confirm, Renew or Rebind message.
> 
>       server-address   The IP address of the server.  If the DHCP domain
>                        crosses site boundaries, then this address MUST
>                        be globally-scoped.
> 
>       options          See section 18.
> 
> 8.8. DHCP Release Message Format
> 
>       msg-type         RELEASE
> 
>       transaction-ID   An unsigned integer generated by the client used
>                        to identify this Release message.
> 
>       server-address   The IP address of the server that assigned the
>                        IA.
> 
>       options          See section 18.
> 
> 8.9. DHCP Decline Message Format
> 
>       msg-type         DECLINE
> 
>       transaction-ID   An unsigned integer generated by the client used
>                        to identify this Decline message.
> 
>       server-address   The IP address of the server that assigned the
>                        addresses.
> 
>       options          See section 18.
> 
> 8.10. DHCP Reconfigure-init Message Format
> 
>       msg-type         RECONFIG-INIT
> 
>       transaction-ID   (unused) MUST be 0
> 
>       server-address   The IP address of the DHCP server issuing the
>                        Reconfigure-init message.  MUST be of sufficient
>                        scope to be reachable by all clients.
> 
>       options          See section 18.
> 
> 9. Relay messages
> 
>    Relay agents exchange messages with servers to forward messages
>    between clients and servers that are not connected to the same link.
> 
> 9.1. Relay-forward message
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |    msg-type   |                                               |
>      +-+-+-+-+-+-+-+-+                                               |
>      |                                                               |
>      |                         relay-address                         |
>      |                                                               |
>      |               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
>      +-+-+-+-+-+-+-+-+                                               |
>      |                                                               |
>      |                     client-return-address                     |
>      |                                                               |
>      |               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
>      +-+-+-+-+-+-+-+-+                                               |
>      .                                                               .
>      .            options (variable number and length)   ....        .
>      |                                                               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>       msg-type                    RELAY-FORW
> 
>       prefix-length               The length of the prefix in the
>                                   address in the "relay-address" field.
> BV> Drop prefix-length as not used.
> 
>       relay-address               An address assigned to the interface
>                                   on which the message from the client
>                                   was received.
> BV> See previous email from Ted and myself regarding the relay-address;
> BV> we should make it an option since it won't always be needed (as the
> BV> source IPv6 header address can be used in most cases). ALSO, see
> BV> my intro to this message before making this change.)
> 
>       client-return-address       The source address from the IP
>                                   datagram in which the message from the
>                                   client was received by the relay agent
> 
>       options                     MUST include a "Client message
>                                   option"; see section 18.7.
> 
> 9.2. Relay-reply message
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |    msg-type   |                                               |
>      +-+-+-+-+-+-+-+-+                                               |
>      |                                                               |
>      |                         relay-address                         |
>      |                                                               |
>      |               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
>      +-+-+-+-+-+-+-+-+                                               |
>      |                                                               |
>      |                     client-return-address                     |
>      |                                                               |
>      |               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
>      +-+-+-+-+-+-+-+-+                                               |
>      .                                                               .
>      .            options (variable number and length)   ....        .
>      |                                                               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>       msg-type        RELAY-REPL
> 
>       prefix-length   The length of the prefix in the address in the
>                       "relay-address" field.
> BV> Drop prefix-length as not used.
> 
>       relay-address   An address identifying the interface on the
>                       relay agent through which the message from the
>                       server should be forwarded; copied from the
>                       "relay-forward" message.
> BV> See above (make an option). Note that the server MUST send this
> BV> option back in the relay sent it in Relay-Forw.
> 
>       client-return-address       The source address from the IP
>                                   datagram in which the message from the
>                                   client was received by the relay agent
> 
>       options         MUST include a "Server message option"; see
>                       section 18.8.
> 
> 12. Selecting addresses for assignment to an IA
> 
>    A server selects addresses to be assigned to an IA according to the
>    address assignment policies determined by the server administrator
>    and the specific information the server determines about the client
>    from the following sources:
> 
>     -  The link to which the client is attached:
> 
>         *  If the server receives the message directly from the client
>            and the source address in the IP datagram in which the
>            message was received is a link-local address, then the client
>            is on the same link to which the interface over which the
>            message was received is attached
> 
>         *  If the server receives the message directly from the client
>            and the source address in the IP datagram in which the
>            message was received is not link-local address, then the
>            client is on the link identified by the source address in the
>            IP datagram
> 
>         *  If the server receives the message from a forwarding relay
>            agent, then the client is on the same link as the one to
>            which the interface identified by the relay-address field in
>            the message from the relay is attached
> BV> This will need to be updated to reflect relay-address option (if no
> BV> option, use source address else use relay-address option value).
> 
>     -  The DUID supplied by the client
> 
>     -  Other information in options supplied by the client
> 
>     -  Other information in options supplied by the relay agent
> 
> 13. DHCP Server Solicitation
> 
>    This section describes how a client locates servers.  The behavior
>    of client and server implementations is discussed, along with the
>    messages they use.
> 
> 13.1. Solicit Message Validation
> 
>    Clients MUST silently discard any received Solicit messages.
> 
> 13.2. Advertise Message Validation
> 
>    Servers MUST discard any received Advertise messages.
> 
>    Clients MUST discard any received Advertise messages in which the
>    "Transaction-ID" field value does not match the value the client used
>    in its Solicit message.
> 
> 13.3. Client Behavior
> 
>    A client uses the Solicit message to discover DHCP servers configured
>    to serve addresses on the link to which the client is attached.
> 
> 13.3.1. Creation and sending of the Solicit message
> 
>    The client sets the "msg-type" field to SOLICIT. The client generates
>    a transaction ID and inserts this value in the "transaction-ID"
>    field.
> 
>    The client includes a DUID option to identify itself to the server.
>    The client MUST include options for any IAs to which it wants the
>    server to assign addresses.  The client may include addresses in the
>    IAs as a hint to the server about addresses for which the client
>    may have a preference.  The client MAY include an Option Request
>    Option in the Solicit message.  The client MUST NOT include any other
>    options except those specifically allowed as defined by specific
>    options.
> 
>    The client sends the Solicit message to the All DHCP Agents
>    multicast address, destination port 547.  The source port selection
>    can be arbitrary, although it SHOULD be possible using a client
>    configuration facility to set a specific source port value.
> 
> 13.4. Server Behavior
> 
>    A server sends an Advertise message in response to Solicit messages
>    it receives to announce the availability of the server to the client.
> 
> 13.4.1. Receipt of Solicit messages
> 
>    The server determines the information about the client and its
>    location as described in section 12.  If administrative policy
>    permits the server to respond to the client, the server will generate
>    and send an Advertise message to the client.
> 
> 13.4.2. Creation and sending of Advertise messages
> 
>    The server sets the "msg-type" field to ADVERTISE and copies the
>    values of the transaction-ID field from the client's Solicit to the
> BV> Drop "the values of"
>    Advertise message.
> 
>    The server places one of its IP addresses (determined through
>    administrator setting) in the "server-address" field of the Advertise
>    message.  The server MAY add a Preference option to carry the
>    preference value for the Advertise message.
> 
>    The server implementation SHOULD allow the setting of a server
>    preference value by the administrator.  The server preference value
>    MUST default to zero unless otherwise configured by the server
>    administrator.
> 
>    The server MUST include options to the Advertise message containing
>    any addresses that would be assigned to IAs contained in the Solicit
>    message from the client.  If the server will not assign any addresses
>    to IAs in a subsequent Request from the client, the server MAY choose
>    to send an Advertise message to the client that includes no IA
>    options.  The server MAY include other options the server will return
>    to the client in a subsequent Reply message.  The information in
>    these options will be used by the client in the selection of a server
>    if the client receives more than one Advertise message.  The server
>    SHOULD include options specifying values for options requested by the
>    client in an Option Request Option included in the Solicit message.
> 
>    If the Solicit message was received directly by the server, the
>    server unicasts the Advertise message directly to the client using
>    the address in the source address field from the IP datagram in
>    which the Solicit message was received.  The Advertise message MUST
>    be unicast through the interface on which the Solicit message was
>    received.
> 
>    If the Solicit message was received in a Relay-forward message,
>    the server constructs a Relay-reply message with the Advertise
>    message in the payload of a "server-message" option.  The server
>    unicasts the Relay-reply message directly to the relay agent using
>    the address in the source address field from the IP datagram in which
>    the Relay-forward message was received.
> 
> 14. DHCP Client-Initiated Configuration Exchange
> 
>    A client initiates a message exchange with a server or servers to
>    acquire or update configuration information of interest.  The client
>    may initiate the configuration exchange as part of the operating
>    system configuration process or when requested to do so by the
>    application layer.
> 
>    The client uses the following messages to initiate a configuration
>    event:
> 
>       Request   Obtain initial configuration information (from a server
>                 identified in a previously received Advertise message)
>                 when the client has no assigned addresses
> BV> Request may also be used at any time, not just "initial" configuration
> 
> BV> information ... when the client has no assigned addresses.
> 
>       Confirm   Confirm the validity of assigned addresses and other
>                 configuration changes through the server from which the
> BV> "configuration changes"? how about "configuration information".
>                 configuration information was obtained when the client's
>                 assigned addresses may not be valid; for example, when
>                 the client reboots or loses its connection to a link
> BV> also, this isn't just from the server from the info was obtained?
> 
>       Renew     Extend the lease on an IA through the server that
>                 originally assigned the IA
> 
>       Rebind    Extend the lease on an IA through any server willing to
>                 extend the lease
> 
>       Release   Release the lease on an IA and release all of the
>                 addresses contained in the IA,
> BV> I think we still have open whether all or some address can be
> released.
> 
>       Decline   Decline the assignment of one or more addresses in an
>                 IA.
> 
>    A client uses the Release/Reply message exchange to indicate to the
>    DHCP server that the client will no longer be using the addresses in
>    the released IA.
> BV> Why have this? Isn't this already covered by the above entry for
> Release?
> 
>    A client uses the Decline/Reply message exchange to indicate to the
>    DHCP server that the client has detected that one or more addresses
>    assigned by the server is already in use on the client's link.
> BV> Why have this? Same as release.
> 
> 14.1. Client Message Validation
> 
>    Clients MUST silently discard any received client messages (Request,
>    Confirm, Renew, Rebind, Release or Decline messages).
> 
>    Servers MUST discard any received client messages in which the
>    "options" field contains an authentication option, and the server
>    cannot successfully authenticate the client.
> 
>    Servers MUST discard any received Request, Renew, Release or Decline
>    message in which the "server-address" field value does not match any
>    of the server's addresses.
> 
> 14.2. Server Message Validation
> 
>    Servers MUST silently discard any received server messages
>    (Advertise, Reply or Reconfigure-init messages).
> 
>    Clients MUST discard any server messages that meet any of the
>    following criteria:
> 
>      o The "transaction-ID" field value in the server message does
>        not match the value the client used in its Request or Release
>        message.
> BV> This should apply to all client messages, not just Request/Release.
> 
>      o The server message contains an authentication option, and the
>        client's attempt to authenticate the message fails.
> 
>    Relays MUST discard any Relay-reply message in which the
>    "client-link-local-address" field in the Relay-reply message does not
>    contain a valid link-local address.
> BV> This is now the "client-return-address" and does it really need to
> BV> only be a link-local address? I don't think so (though it likely will
> BV> mostly be link-local).
> 
> 14.3. Client Behavior
> 
>    A client will use Request, Confirm, Renew and Rebind messages to
>    acquire and confirm the validity of configuration information.  A
>    client may initiate such an exchange automatically in order to
>    acquire the necessary network parameters to communicate with nodes
>    off-link.  The client uses the server address information from
>    previous Advertise message(s) for use in constructing Request and
>    Renew message(s).  Note that a client may request configuration
>    information from one or more servers at any time.
> 
>    A client uses the Release message in the management of IAs when
>    the client has been instructed to release the IA prior to the IA
>    expiration time since it is no longer needed.
> 
>    A client uses the Decline message when the client has determined
>    through DAD or some other method that one or more of the addresses
>    assigned by the server in the IA is already in use by a different
>    client.
> 
> 14.3.1. Creation and sending of Request messages
> 
>    If a client has no valid IPv6 addresses of sufficient scope to
>    communicate with a DHCP server, it may send a Request message to
> BV> Why "communicate with a DHCP server"? And the client could well
> BV> have many addresses of sufficient scope - that's not the point
> BV> of the request. We really should just say that "If the client
> BV> is using stateful address configuration and either needs an
> BV> initial set of address or additional addresses, it MUST send a
> BV> Request message to obtain new addresses." (or something like that)
>    obtain new addresses.  The client includes one or more IAs in the
>    Request message, to which the server assigns new addresses.  The
>    server then returns IA(s) to the client in a Reply message.
> 
>    The client generates a transaction ID and inserts this value in the
>    "transaction-ID" field.
> 
>    The client places the address of the destination server in the
>    "server-address" field.
> BV> How about "The client copies the "server-address" field as received in
> 
> BV> the selected Advertise message to the "server-address" field of the
> BV> Request."
> 
>    The client adds a DUID option to identify itself to the server.  The
>    client adds any other appropriate options, including one or more IA
>    options (if the client is requesting that the server assign it some
>    network addresses).  The list of addresses in each included IA MUST
>    be empty.  If the client is not requesting that the server assign it
> BV> IA MUST be empty? This wasn't what we had been discussing?? Wasn't
> BV> it that people wanted the addresses received in the Advertise to be
> BV> used here?
>    any addresses, the client omits the IA option.
> 
>    The client sends the Request message to the All DHCP Agents multicast
>    address through the interface for which the client is interested in
>    obtaining configuration information, with the destination port set
>    to 547.  The source port selection can be arbitrary, although it
>    SHOULD be possible using a client configuration facility to set a
>    specific source port value.
> 
>    The server will respond to the Request message with a Reply
>    message.  If no Reply message is received within REP_MSG_TIMEOUT
>    milliseconds, the client retransmits the Request with the same
>    transaction-ID, and doubles the REP_MSG_TIMEOUT value, and waits
>    again.  The client continues this process until a Reply is received
>    or REQUEST_MSG_ATTEMPTS unsuccessful attempts have been made, at
>    which time the client MUST abort the configuration attempt.  The
>    client SHOULD report the abort status to the application layer.
> 
>    Default and initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS
>    are documented in section 7.5.
> 
> 14.3.2. Creation and sending of Confirm messages
> 
>    Whenever a client may have moved to a new link, its IPv6 addresses
>    may no longer be valid.  Examples of times when a client may have
>    moved to a new link include:
> 
>      o The client reboots
> 
>      o The client is physically disconnected from a wired connection
> 
>      o The client returns from sleep mode
> 
>      o The client using a wireless technology changes cells
> 
>    In any situation when a client may have moved to a new link, the
>    client MUST initiate a Confirm/Reply message exchange.  The client
>    includes any IAs, along with the addresses associated with those IAs,
>    in its Confirm message.  Any responding servers will indicate the
>    acceptability of the addresses with the status in the IA it returns
>    to the client.
> 
>    The client sets the "msg-type" field to CONFIRM. The client generates
>    a transaction ID and inserts this value in the "transaction-ID"
>    field.
> 
>    The client sets the "server-address" field to 0.
> 
>    The client adds a DUID option to identify itself to the server.  The
>    client adds any appropriate options, including one or more IA options
>    (if the client is requesting that the server confirm the validity of
>    some network addresses).  If the client does include any IA options,
>    it MUST include the list of addresses the client currently has
>    associated with that IA.
> 
>    The client sends the Confirm message to the All DHCP Agents multicast
>    address through the interface for which the client is interested in
>    obtaining configuration information, with the destination port set
>    to 547.  The source port selection can be arbitrary, although it
>    SHOULD be possible using a client configuration facility to set a
>    specific source port value.
> 
>    Servers will respond to the Confirm message with a Reply message.  If
>    no Confirm message is received within REP_MSG_TIMEOUT milliseconds,
>    the client retransmits the Confirm with the same transaction-ID,
>    and doubles the REP_MSG_TIMEOUT value, and waits again.  The client
>    continues this process until a Reply is received or QRY_MSG_ATTEMPTS
>    unsuccessful attempts have been made, at which time the client MUST
>    abort the configuration attempt.  The client SHOULD report the abort
>    status to the application layer.
> 
>    Default and initial values for REP_MSG_TIMEOUT and QRY_MSG_ATTEMPTS
>    are documented in section 7.5.
> 
>    If the client receives no response to its Confirm message, it MAY
>    restart the configuration process by locating a DHCP server with an
>    Advertise message and sending a Request to that server, as described
>    in section 14.3.1.
> 
> 14.3.3. Creation and sending of Renew messages
> 
>    IPv6 addresses assigned to a client through an IA use the same
>    preferred and valid lifetimes as IPv6 addresses obtained through
>    stateless autoconfiguration.  The server assigns preferred and valid
>    lifetimes to the IPv6 addresses it assigns to an IA. To extend those
>    lifetimes, the client sends a Request to the server containing an
>    "IA option" for the IA and its associated addresses.  The server
>    determines new lifetimes for the addresses in the IA according to
>    the server's administrative configuration.  The server may also add
>    new addresses to the IA. The server remove addresses from the IA by
> BV> The server [may] remove addresses from the IA by ...
>    setting the preferred and valid lifetimes of those addresses to zero.
> 
>    The server controls the time at which the client contacts the server
>    to extend the lifetimes on assigned addresses through the T1 and
>    T2 parameters assigned to an IA. If the server does not assign an
>    explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the
>    shortest preferred lifetime of any address assigned to the IA and
>    T2 defaults to 0.875 times the shortest preferred lifetime of any
>    address assigned to the IA.
> BV> The above will be reworked in new material Mark, Ted, and I should be
> BV> providing.
> 
>    At time T1 for an IA, the client initiates a Request/Reply message
>    exchange to extend the lifetimes on any addresses in the IA. The
>    client includes an IA option with all addresses currently assigned to
>    the IA in its Request message.
> 
>    The client sets the "msg-type" field to RENEW. The client generates a
>    transaction ID and inserts this value in the "transaction-ID" field.
> 
>    The client places the address of the destination server in the
>    "server-address" field.
> 
>    The client adds a DUID option to identify itself to the server.  The
>    client adds any appropriate options, including one or more IA options
>    (if the client is requesting that the server extend the lease on some
>    IAs; note that the client may check the status of other configuration
>    parameters without asking for lease extensions).  If the client does
>    include any IA options, it MUST include the list of addresses the
>    client currently has associated with that IA.
> 
>    The client sends the Renew message to the All DHCP Agents multicast
>    address through the interface for which the client is interested in
>    obtaining configuration information, with the destination port set
>    to 547.  The source port selection can be arbitrary, although it
>    SHOULD be possible using a client configuration facility to set a
>    specific source port value.
> 
>    The server will respond to the Renew message with a Reply message.
>    If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
>    the client retransmits the Renew with the same transaction-ID, and
>    doubles the REP_MSG_TIMEOUT value, and waits again.  The client
>    continues this process until a Reply is received or until time T2 is
>    reached (see section 14.3.4).
> 
>    Default and initial values for REP_MSG_TIMEOUT are documented in
>    section 7.5.
> 
> 14.3.4. Creation and sending of Rebind messages
> 
>    At time T2 for an IA (which will only be reached if the server to
>    which the Renew message was sent at time T1 has not responded),
>    the client initiates a Rebind/Reply message exchange.  The client
>    includes an IA option with all addresses currently assigned to the IA
>    in its Rebind message.  The client sends this message to the All DHCP
>    Agents multicast address.
> 
>    The client sets the "msg-type" field to REBIND. The client generates
>    a transaction ID inserts this value in the "transaction-ID" field.
> 
>    The client sets the "server-address" field to 0.
> 
>    The client adds a DUID option to identify itself to the server.
>    The client adds any appropriate options, including one or more IA
>    options.  If the client does include any IA options (if the client is
>    requesting that the server extend the lease on some IAs; note that
>    the client may check the status of other configuration parameters
>    without asking for lease extensions), it MUST include the list of
>    addresses the client currently has associated with that IA.
> 
>    The client sends the Rebind message to the All DHCP Agents multicast
>    address through the interface for which the client is interested in
>    obtaining configuration information, with the destination port set
>    to 547.  The source port selection can be arbitrary, although it
>    SHOULD be possible using a client configuration facility to set a
>    specific source port value.
> 
>    The server will respond to the Rebind message with a Reply message.
>    If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
>    the client retransmits the Rebind with the same transaction-ID, and
>    doubles the REP_MSG_TIMEOUT value, and waits again.  The client
>    continues this process until a Reply is received.
> 
>    Default and initial values for REP_MSG_TIMEOUT are documented in
>    section 7.5.
> 
>    The client has several alternatives to choose from if it receives no
>    response to its Rebind message.
> 
>     -  When the lease on the IA expires, the client may choose to use a
>        Solicit message to locate a new DHCP server and send a Request
>        for the expired IA to the new server
> 
>     -  Some addresses in the IA may have lifetimes that extend beyond
>        the lease of the IA, so the client may choose to continue to use
>        those addresses; once all of the addresses have expired, the
>        client may choose to locate a new DHCP server
> 
>     -  The client may have other addresses in other IAs, so the client
>        may choose to discard the expired IA and use the addresses in the
>        other IAs
> 
> 14.3.5 (omitted)
> 
> 14.3.6. Creation and sending of Release messages
> 
>    The client sets the "msg-type" field to RELEASE. The client generates
>    a transaction ID and places this value in the "transaction-ID" field.
> 
>    The client places the IP address of the server that allocated the
>    address(es) in the "server-address" field.
> 
>    The client adds a DUID option to identify itself to the server.  The
>    client includes options containing the IAs it is releasing in the
>    "options" field.  The addresses to be released MUST be included in
>    the IAs.  The appropriate "status" field in the options MUST be set
>    to indicate the reason for the release.
> 
>    If the client is configured to use authentication, the client
>    generates the appropriate authentication option, and adds this option
>    to the "options" field.  Note that the authentication option MUST be
>    the last option in the "options" field.  See section  18.11 for more
>    details about the authentication option.
> 
>    The client sends the Release message to the All DHCP Agents multicast
>    address through the interface for which the client is interested in
>    obtaining configuration information, with the destination port set
>    to 547.  The source port selection can be arbitrary, although it
>    SHOULD be possible using a client configuration facility to set a
>    specific source port value.
> 
> 14.3.7. (Omitted)
> 
> 14.3.8. (Omitted)
> 
> 14.3.9. Creation and sending of Decline messages
> 
>    The client sets the "msg-type" field to DECLINE. The client generates
>    a transaction ID and places this value in the "transaction-ID" field.
> 
>    The client places the IP address of the server that allocated the
>    address(es) in the "server-address" field.
> 
>    The client adds a DUID option to identify itself to the server.  The
>    client includes options containing the IAs it is declining in the
>    "options" field.  The addresses to be released MUST be included in
>    the IAs.  The appropriate "status" field in the options MUST be set
>    to indicate the reason for declining the address.
> 
>    If the client is configured to use authentication, the client
>    generates the appropriate authentication option, and adds this option
>    to the "options" field.  Note that the authentication option MUST be
>    the last option in the "options" field.  See section  18.11 for more
>    details about the authentication option.
> 
>    The client sends the Decline message to the All DHCP Agents multicast
>    address through the interface for which the client is interested in
>    obtaining configuration information, with the destination port set
>    to 547.  The source port selection can be arbitrary, although it
>    SHOULD be possible using a client configuration facility to set a
>    specific source port value.
> 
> 14.3.10. (Omitted)
> 
>    If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
>    the client retransmits the Decline, doubles the REP_MSG_TIMEOUT
>    value, and waits again.  The client continues this process until a
>    Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have
>    been made, at which time the client SHOULD abort the attempt to
>    decline the address.  The client SHOULD return the abort status to
>    the application, if an application initiated the release.
> 
>    Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS
>    are documented in section 7.5.
> 
> 14.3.11. Receipt of Reply message in response to a Release message
> 
>    Upon receipt of a valid Reply message, the client can consider the
>    Release event successful, and SHOULD return the successful status to
>    the application layer, if an application initiated the release.
> BV> This section should replace Release with Decline (Section 14.3.8
> BV> covers the Release case). No need for application layer to be told
> BV> about Declines?
> 
> 14.4. Server Behavior
> 
>    For this discussion, the Server is assumed to have been configured in
>    an implementation specific manner with configuration of interest to
>    clients.
> 
> 14.4.1. Receipt of Request messages
> 
>    Upon the receipt of a valid Request message from a client the server
>    can respond to, (implementation-specific administrative policy
>    satisfied) the server scans the options field.
> 
>    The server then constructs a Reply message and sends it to the
>    client.
> 
>    The server SHOULD process each option for the client in an
>    implementation-specific manner.  The server MUST construct a Reply
>    message containing the following values:
> 
>       msg-type         REPLY
> 
>       transaction-ID   The transaction-ID from the Request message.
> 
>       server address   One of the IP addresses assigned to the interface
>                        through which the server received the message
>                        from the client.
> 
>    When the server receives a Request and IA option is included the
>    client is requesting the configuration of a new IA by the server.
> BV> We need to clarify this behavoir and what "new" means (may be cases
> BV> where client thinks it is new, but server already knows about it).
>    The server MUST take the clients IA and associate a binding for that
>    client in an implementation-specific manner within the server's
>    configuration parameter database for DHCP clients.
> 
>    If the server cannot provide addresses to the client it SHOULD send
>    back an empty IA to the client with the status field set to Unavail.
> 
>    If the server can provide addresses to the client it MUST send back
>    the IA to the client with all fields entered and a status of Success,
>    and add the IA as a new client binding.
> 
>    The server adds options to the Reply message for any other
>    configuration information to be assigned to the client.
> 
> 14.4.2. Receipt of Confirm messages
> 
>    Upon the receipt of a valid Confirm message from a client the server
>    can respond to, (implementation-specific administrative policy
>    satisfied) the server scans the options field.
> 
>    The server then constructs a Reply message and sends it to the
>    client.
> 
>    The server SHOULD process each option for the client in an
>    implementation-specific manner.  The server MUST construct a Reply
>    message containing the following values:
> 
>       msg-type         REPLY
> 
>       transaction-ID   The transaction-ID from the Confirm message.
> 
>       server address   One of the IP addresses assigned to the interface
>                        through which the server received the message
>                        from the client.
> 
>    When the server receives a Confirm and an IA option is included the
>    client is requesting confirmation that the addresses in the IA are
>    valid.  The server SHOULD locate the clients binding and verify the
>    information in the IA from the client matches the information stored
>    for that client.
> 
>    If the server cannot find a client entry for this IA the server
>    SHOULD return an empty IA with status set to NoBinding.
> 
>    If the server finds that the information for the client does not
>    match what is in the server's records for that client the server
>    should send back an empty IA with status set to Conf_NoMatch.
> 
>    If the server finds a match to the Confirm then the server should
>    send back the IA to the client with status set to success.
> 
> 14.4.3. Receipt of Renew messages
> 
>    Upon the receipt of a valid Renew message from a client the server
>    can respond to, (implementation-specific administrative policy
>    satisfied) the server scans the options field.
> 
>    The server then constructs a Reply message and sends it to the
>    client.
> 
>    The server SHOULD process each option for the client in an
>    implementation-specific manner.  The server MUST construct a Reply
>    message containing the following values:
> 
>       msg-type         REPLY
> 
>       transaction-ID   The transaction-ID from the Confirm message.
> 
>       server address   One of the IP addresses assigned to the interface
>                        through which the server received the message
>                        from the client.
> 
>    When the server receives a Renew and IA option from a client it
>    SHOULD locate the clients binding and verify the information in the
>    IA from the client matches the information stored for that client.
> 
>    If the server cannot find a client entry for this IA the server
>    SHOULD return an empty IA with status set to NoBinding.
> 
>    If the server finds that the addresses in the IA for the client do
>    not match the clients binding the server should return an empty IA
>    with status set to Renw_NoMatch.
> 
>    If the server cannot Renew addresses for the client it SHOULD send
>    back an empty IA to the client with the status field set to Unavail.
> 
>    If the server finds the addresses in the IA for the client then the
>    server SHOULD send back the IA to the client with new lease times
>    and T1/T2 times if the default is not being used, and set status to
>    Success.
> 
> 14.4.4. Receipt of Rebind messages
> 
>    Upon the receipt of a valid Rebind message from a client the server
>    can respond to, (implementation-specific administrative policy
>    satisfied) the server scans the options field.
> 
>    The server then constructs a Reply message and sends it to the
>    client.
> 
>    The server SHOULD process each option for the client in an
>    implementation-specific manner.  The server MUST construct a Reply
>    message containing the following values:
> 
>       msg-type         REPLY
> 
>       transaction-ID   The transaction-ID from the Confirm message.
> 
>       server address   One of the IP addresses assigned to the interface
>                        through which the server received the message
>                        from the client.
> 
>    When the server receives a Rebind and IA option from a client it
>    SHOULD locate the clients binding and verify the information in the
>    IA from the client matches the information stored for that client.
> 
>    If the server cannot find a client entry for this IA the server
>    SHOULD return an empty IA with status set to NoBinding.
> 
>    If the server finds that the addresses in the IA for the client do
>    not match the clients binding the server should return an empty IA
>    with status set to Rebd_NoMatch.
> 
>    If the server cannot Rebind addresses for the client it SHOULD send
>    back an empty IA to the client with the status field set to Unavail.
> 
>    If the server finds the addresses in the IA for the client then the
>    server SHOULD send back the IA to the client with new lease times
>    and T1/T2 times if the default is not being used, and set status to
>    Success.
> 
>    There is a significant difference between Renew and Rebind messages:
>    Because the Rebind message is processed by a single server, the
>    responding server can actually change the addresses in the IA.
>    However, because multiple servers may respond to a Rebind, all they
>    can safely do is update T1, T2 (for the IA) and lifetimes (for
>    individual addresses).
> 
> 14.4.5. Receipt of Release messages
> 
>    Upon the receipt of a valid Release message, the server examines the
>    IAs and the addresses in the IAs for validity.  If the IAs in the
>    message are in a binding for the client and the addresses in the IAs
>    have been assigned by the server to those IA, the server deletes
>    the addresses from the IAs and makes the addresses available for
>    assignment to other clients.
> 
>    The server then generates a Reply message.  If all of the IAs were
>    valid and the addresses successfully released,, the server sets the
>    "status" field to "Success".  If any of the IAs were invalid or if
>    any of the addresses were not successfully released, the server
>    releases none of the addresses in the message and sets the "status"
>    field to "NoBinding"(section 7.4).
> 
>    If the client successfully releases some but not all of the addresses
>    in an IA, the IA continues to exist and holds the remaining,
>    unreleased addresses.
> 
>    A client can send an option containing an IA with no listed addresses
>    to release implicitly all of the addresses in the IA.
> 
>    A server is not required to (but may choose to as an implementation
>    strategy) retain any record of an IA from which all of the addresses
>    have been released.
> 
> 14.4.6. Sending of Reply messages
> 
>    If the Request, Confirm, Renew, Rebind or Release message from
> BV> What about Decline messages (add to list).
>    the client was originally received was originally received in a
> BV> typo - duplicated "was originally received".
>    Relay-forward message from a relay, the server places the Reply
>    message in the options field of a Relay-response message and copies
>    the relay-address and client-link-local-address fields from the
> BV> client-return-address
>    Relay-forward message into the Relay-response message.
> 
>    The server then unicasts the Reply or Relay-reply to the source
>    address from the IP datagram in which the original message was
>    received.
> 
> 16. Relay Behavior
> 
>    For this discussion, the Relay may be configured to use a list of
>    server destination addresses, which may include unicast addresses,
>    the All DHCP Servers multicast address, or other multicast addresses
>    selected by the network administrator.  If the Relay has not been
>    explicitly configured, it MUST use the All DHCP Servers multicast
>    address as the default.
> 
> 16.1. Relaying of client messages
> 
>    When a Relay receives a valid client message, it constructs
>    a Relay-forward message.  The relay places an address from
>    the interface on which the client message was received in the
>    "relay-address" field.  This address will be used by the server to
>    identify the link to which the client is connected and will be used
>    by the relay to forward the Advertise message from the server back to
>    the client.
> 
>    The relay copies the source address from the IP datagram
>    in which the message was received from the client into the
>    client-link-local-address field in the Relay-forward message.
> BV> client-return-address
> 
>    The relay constructs a "client-message" option 18.7 that contains
>    the entire message from the client in the data field of the
>    option.  The relay places the "relay-message" option along with any
>    "relay-specific" options in the options field of the Relay-forward
>    message.  The Relay then sends the Relay-forward message to the list
>    of server destination addresses that it has been configured with.
> 
> 16.2. Relaying of server messages
> 
>    When the relay receives a Relay-reply message, it extracts the server
>    message from the "server-message" option and forwards the message to
>    the address in the client-link-local-address field in the Relay-reply
> BV> client-returnn-address
>    message.  The relay forwards the server message through the interface
>    identified in the "relay-address" field in the Relay-reply message.
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> http://www1.ietf.org/mailman/listinfo/dhcwg

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
joshl@cisco.com                                      250 Apollo Drive
tel: 978-244-8378  fax: same               Chelmsford, MA  01824-3627


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg