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
- [dhcwg] Generic DHCPv6 Message Paul Tan
- [dhcwg] DHCPv6 - server-address and unicast Bernie Volz (EUD)
- Re: [dhcwg] DHCPv6 - server-address and unicast Ralph Droms