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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 24 Jan 2002 20:43:49 -0600

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

---

From: Ralph Droms <[email-masked]>
Date: Fri, 25 Jan 2002 06:43:18 -0500

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:
>
>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.
>

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg