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

[Ralph Droms <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg