Subject: Re: 18.10, Server Unicast Option

From: Ralph Droms <[email-masked]>
Date: Thu, 19 Jul 2001 16:41:43 -0400

Bernie - can you be more specific about suggestion #2?  Are you referring 
to the problem of replying to unicast messages when the client has used an 
invalid source address?

- Ralph

At 03:28 PM 7/19/2001 -0500, Bernie Volz (EUD) wrote:

>After a few private exchanges with Ted, while there are still many
>open issues with the client unicasting to the server (such as how
>the server replies), how about we:
>
>- At a minimum, remove Confirm from the list of messages in Section
>18.10. It does not belong because it is NOT directed to a single
>server but instead to ANY server. (See section 14.3.2, "The client
>sets the "server-address" field to 0.) The other messages (Request,
>Renew, Release, and Decline) are all directed to a single server.
>
>- At a maximum, remove this section (option) altogether for now - it
>can always be added as a feature in a later revision (new option).
>This means we don't have to figure out how a server returns a reply
>to a unicast message. (Though it may tie in closely to what I've
>suggested as a clarificaton to Section 15.2.1 on unicasting
>Reconfigure-inits.)
>
>Bernie Volz
>Chief Technical Officer - DNS & DHCP Development Unit
>Ericsson, Inc.
>Tel: +1-508-875-3162
>Fax: +1-508-875-3018
>Mobile: +1-617-513-9060
><mailto:[email-masked]>mailto:[email-masked]

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 19 Jul 2001 15:53:35 -0500

Ralph:

No where in the -19 text does it say to ever use the IPv6 Source Address
to send messages. I thought the idea was NOT to require this kind
of data - we wanted the messages themselves to pretty much contain all
the server needed?

The text on sending the reply says unicast to relay (if Relay-Forward
received) else unicast it to the "client-link-local-address". 

Perhaps we should change this to unicast to relay (if Relay-Forward
received) else unicast it to the IPv6 source address of the client's
message. In which case, what's the client-link-local-address needed
for (except when relayed, in which case that can be part of the
Relay-Forward/Relay-Reply).

If the IPv6 Source Address is used, yes there may be an issue if the
client doesn't provide an address of sufficent scope. But, I wasn't
really worried about that since that isn't really the server's fault.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, July 19, 2001 4:42 PM
To: DHCPv6 discussion list
Subject: Re: 18.10, Server Unicast Option

- Ralph

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 19 Jul 2001 17:52:35 -0500

I would be happy if the text did say to use the IPv6 Source
Address (unless Relay-Forward message was received - though I
again see no reason why that can't be used to send the
Relay-Reply to the Relay as well).

If we do this, why not drop the client-link-local-address from 
the message formats. It won't be needed anymore. Though of course
we will need to change the Relay-Forward and Relay-Reply message
formats to put the client-link-local-address (or client-reply-address)
such that the relay has the information it needs to get the packet
to the client. Note that we do need the relay-address in the Relay-
Forward header, but that's to tell the server which link the
client is on only and doesn't need to be used by the server to
send the Relay-Reply.

We also need to make it clear that when a server receives a client
packet (when not via the Relay) it can tell where the client is as
follows:
- If the IPv6 Source Address is a link-local address, it is on
the interface the packet was received from.
- Otherwise, the IPv6 Source Address should tell the server where
the client is. This has lots of benefits though it may require
the server to know more about the network than it would need to
just to assign addresses. So, we need to add "If the IPv6 Source
Address' prefix is not known by the server, the server MUST NOT
make any assumptions about the link the client is on." This then
has implications as to how it would process each client request
type if it doesn't know the link (we had this anyway in the -19
draft when packets were unicast to the server, so this is nothing
new).

I believe in the past there was some concern that you couldn't
always get the IP source address for UDP packets. Recvfrom does
provide this but apparently only some implementations it was
broken? or could be used to get other information that was more
important for the DHCP server (such as the receiving interface?).
These are hopefully IPv4 legacy issues and don't apply to
IPv6 with its much improved socket API. And DHCPv6 servers will be
using that - not the IPv4 interface.

DOES *ANYONE* ON THE MAILING LIST HAVE ANY ISSUE WITH DOING THIS
CHANGE?

- Bernie

PS: In terms of unicasting the Reconfigure-Init, I think the
server will still need to save some information (such as the
Relay address and client's link local address to give to the
relay) or the client's link-local address (if on link). But, it
still should have all it needs.

-----Original Message-----
From: Bernie Volz (EUD) 
Sent: Thursday, July 19, 2001 4:54 PM
To: [email-masked]'
Subject: RE: 18.10, Server Unicast Option

Ralph:

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, July 19, 2001 4:42 PM
To: DHCPv6 discussion list
Subject: Re: 18.10, Server Unicast Option

- Ralph