Re: [dhcwg] DHCPv6 - server-address and unicast

Ralph Droms <rdroms@cisco.com> Fri, 25 January 2002 11:48 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 GAA29144 for <dhcwg-archive@odin.ietf.org>; Fri, 25 Jan 2002 06:48:39 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA09897 for dhcwg-archive@odin.ietf.org; Fri, 25 Jan 2002 06:48:40 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09536; Fri, 25 Jan 2002 06:43:33 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09513 for <dhcwg@optimus.ietf.org>; Fri, 25 Jan 2002 06:43:32 -0500 (EST)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29014 for <dhcwg@ietf.org>; Fri, 25 Jan 2002 06:43:29 -0500 (EST)
Received: from rdroms-w2k.cisco.com ([10.86.240.17]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA25980 for <dhcwg@ietf.org>; Fri, 25 Jan 2002 06:42:59 -0500 (EST)
Message-Id: <4.3.2.7.2.20020125063329.00b88350@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 25 Jan 2002 06:43:18 -0500
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: [dhcwg] DHCPv6 - server-address and unicast
In-Reply-To: <66F66129A77AD411B76200508B65AC69BC77F0@EAMBUNT705>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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

I fully support Bernie's proposal.  These changes clarify the 
identification of servers (in fact, the corresponding function in DHCPv4 is 
accomplished with the 'server-identifier' option), and eliminates 
overloading the server-identifier function with the server-address 
function.  Bernie's proposal does not require any changes to the basic 
protocol function - all that's changed is the source of the number used to 
identify the server and the way in which the client finds out how to 
contact the server.

- Ralph

At 08:43 PM 1/24/2002 -0600, Bernie Volz (EUD) wrote:

>Folks:
>
>Here's a VERY LATE proposal to consider for a change to the DHCPv6 
>specification. We currently have an issue with the server-address field in 
>the header of the messages being overloaded for two purposes:
>
>1. To identify the server (for messages that are directed at a single server)
>2. To identify the address for the client to use if allowed to unicast to 
>the server.
>
>While issue 2 could be fairly easily resolved by changing the definition 
>of 22.14 Server unicast option to include an IPv6 server address, issue 1 
>is more complex.
>
>To identify the server, we're using an address and what address should a 
>server use? How do we guarentee that this address is unique within a DHCP 
>domain? If a global address is used, that would work well (provided that 
>the address is fairly stable). But, if onlt site addresses are available, 
>what if the DHCP domain crosses site boundries?
>
>And, there really is no reason to use an IPv6 address at all for this 
>server "identifier". So, what about changing the specification to use a 
>DUID for the server identifier? Instead of a server-address field in the 
>message header, we define a server identifier option (and require it be 
>"first" to assure that servers that aren't being addressed can drop the 
>message quickly). This server identifier option uses the exact same format 
>as the DUID option. This allows the server to generate a DUID, use it as 
>the server identifier for all time. Now, even if the server changes its 
>addresses (or location within a domain), it can still service the same 
>clients (and unless they are allowed to unicast, even Renew and other 
>directed message will reach the server after it has moved!).
>
>Now, one issue is how to handle the case where any (all) servers are to 
>reply. Either we allow the Server ID option to have a zero option-length 
>to mean any (all) servers OR we say there is no Server ID option in the 
>message. I kind of prefer the 0 length option since that allows a server 
>to find the option (even it is not first but second or third) and know 
>when to stop searching (otherwise, all servers would be forced to look 
>through all options).
>
>Perhaps another possibility is not to have a the Server ID option in some 
>messages and the server need not even bother looking for it since it knows 
>it is not needed, such as for the Solicit, Rebind, and Confirm. The only 
>message this doesn't work for is the Inform since it may be directed at 
>all or one server.
>
>I realize this is a fairly significant change this late in the game. But, 
>I think it nicely solves the problem of what to use as the server-address 
>and reuses the concept of the DUID. And, it also removes ANY reference to 
>the address of the server in clients (except for those that unicast). 
>Relays will still need reconfiguration if explicit addresses are used for 
>forwarding to servers.
>
>It also avoids the temptation that Relay agents may have to use the 
>server-address field in the message header to expedite delivery to the 
>server - they can't use the DUID for the server to do this anymore!
>
>And, if we develop a failover type protocol, the failover servers can 
>great a unique DUID for the group of failover servers.
>
>So, the changes would include:
>
>- Changing the message formats and descriptions to remove the "server 
>address"
>field.
>
>- Add 22.x Server identifier option
>
>    The Server Identifier option is used to carry the DUID of the server.
>    The format for the DUID is keyed to mark the type of identifier and is of
>    variable length.  The format of the option is:
>
>       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
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |        OPTION_SERVERID        |          option-len           |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |           DUID type           |             DUID              |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
>      |                                                               |
>      .                         DUID (cont.)                          .
>      .                                                               .
>      .                                                               .
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>      Unlike the DUID option (section 22.2), the option-len is allowed to be
>      0 for the Server ID option if the message is not directed to a specific
>      server but instead all servers. A 0 length option-len MAY only be used
>      with Solicit, Rebind, Confirm, Inform messages. All other
>      messages require the DUID for the server to be provided.
>
>- Revise 22.14. Server unicast option
>
>    The server MAY send this option to a client to indicate to the client
>    that is allowed to unicast messages to the server.  When a client
>    receives this option, where permissible, the client MAY send messages
>    to the server using the IPv6 address that the server specifies in the
>    server address field in this option.
>
>    Details about when the client may send messages to the server using
>    unicast are in section 18.
>
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          OPTION_UNICAST       |        option-len             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                         server-address                        |
>    |                            (16 octets)                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       option-code     OPTION_UNICAST (TBD)
>
>       option-len      See section 22.
>
>       server-address  The IPv6 address that the client MUST use when 
> unicasting
>                       to the server.
>
>-  And, there are other places that will need changes (such as the text 
>for filling
>in the server-address field).
>
>
>Bernie Volz


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