Subject: Allowing unicasts from client to server

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 22 Mar 2001 00:30:53 -0600

Ralph:

Regarding the issue of allowing clients to unicast to the server, when one
really looks into it, I think there are few instances where this will be of
value. We need to document these assuming we want to go forward with it. The
cases I could see are:
- Renew
- Release
- Decline
- Request (in response to a reconfigure? or if more addresses are desired)

In each of the above cases the client MUST have an address of sufficient
scope to communicate with the server (assuming the client is allowed to
unicast to an off-link server). For other cases:

- Rebind *MUST* be multicast.
- Confirm I think also *MUST* be multicast. But we probably have a difference
of opinion exactly how this will operate and whether other servers (without
binding information) may be respond. Regardless, it is really much like Rebind
and thus I think it needs to be multicast.

Some cases are also tricky since the client might not have an address of
sufficient scope. OR, are we only allowing this if the server is on-link
(hence, link-local can be used).

Assuming the option is desired and we're allowing unicast to off-link
servers, how about we also allow the server to specify the IPv6 address
to which the client should send the response. This would be an OPTIONAL
parameter depending on whether the server-address in the reply is the
correct one or not. (If optional parameters in options are desired, I
guess we could have another option to specify the unicast server address).

So, the option might have the following "parameters":
	2-byte option code
	2-byte option length (which is either 1 or 17)
	1-byte flag (this is 0 if the client must multicast, 1
	  otherwise; remaining bits reserved?)
	16-byte OPTIONAL server's ip-address

Finally, if the server says that a client is allowed to unicast, we should
say this option is advisor and the client *MAY* (or perhaps *SHOULD*) to
it but we should not say that it *MUST* do this.

- Bernie Volz
  Ericsson

---

From: [email-masked]
Date: Thu, 22 Mar 2001 07:58:13 -0600

bernie,
 
the other reason is performance.  it could cost more to hop thru the relay
than directly to a router that forwards that prefix in its fast path off the
lan in IPv6.
 
/jim

-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Thursday,March 22,2001 1:31 AM
To: DHCPv6 discussion list
Cc: [email-masked]
Subject: Allowing unicasts from client to server

Ralph: 

cases I could see are: 
- Renew 
- Release 
- Decline 

- Rebind *MUST* be multicast. 
- Confirm I think also *MUST* be multicast. But we probably have a
difference 
of opinion exactly how this will operate and whether other servers (without 
binding information) may be respond. Regardless, it is really much like
Rebind 
and thus I think it needs to be multicast. 

- Bernie Volz 
  Ericsson