[dhcwg] DHCPv6 - server-address and unicast

"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> Fri, 25 January 2002 03:14 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 WAA13864 for <dhcwg-archive@odin.ietf.org>; Thu, 24 Jan 2002 22:14:49 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA10924 for dhcwg-archive@odin.ietf.org; Thu, 24 Jan 2002 22:14:52 -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 VAA09319; Thu, 24 Jan 2002 21:43:57 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09242 for <dhcwg@ns.ietf.org>; Thu, 24 Jan 2002 21:43:54 -0500 (EST)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13419 for <dhcwg@ietf.org>; Thu, 24 Jan 2002 21:43:50 -0500 (EST)
Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0P2hqh03138 for <dhcwg@ietf.org>; Thu, 24 Jan 2002 20:43:53 -0600 (CST)
Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0P2hqa16627 for <dhcwg@ietf.org>; Thu, 24 Jan 2002 20:43:52 -0600 (CST)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu Jan 24 20:43:52 2002 -0600
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <ZP0Q8K1W>; Thu, 24 Jan 2002 20:43:52 -0600
Message-ID: <66F66129A77AD411B76200508B65AC69BC77F0@EAMBUNT705>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: dhcwg@ietf.org
Date: Thu, 24 Jan 2002 20:43:49 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A54A.1E3B99F0"
Subject: [dhcwg] DHCPv6 - server-address and unicast
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

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