Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 18 Jul 2001 18:10:07 -0500

OK. I understand your point.

BTW, I was originally thinking that only the Reply to a Confirm message
would do this prefix checking and hence return a NoPrefixMatch status.

But, even that would not have been safe. Note that text for the "Server
Unicast Option":

	"This option is used by a server to send to a client to inform the
	client it can send a Request, Renew, Confirm, Release, and Decline
	by unicasting directly to the server instead of the All DHCPv6 Agents
	multicast adress as an optimization."

I think we need to change this OR we need to add a statement to the prefix
checking that prohibits it if the server can't tell where the client is.

Now, this raises the nasty issue of if the client unicasts a message, how
does the server reply to it (I already raised this issue). One solution is
to use the IPv6 Source Address - but that has problems since then why not
always use it? Another is for the server to save information on how to reach
the client (which it might need to do anyway to send it Reconfigure-Inits?)
via a Relay (or directly if on-link). But this is messy and what if the
client has moved (I guess you could argue then it might not need to be
Reconfigured)?

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, July 18, 2001 6:51 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] 

IIRC = If I Recall Correctly

> What difference does that make? A Release or Decline can be unicast as well
> (if the client has another address - in a different IA - than what it is
> releasing and the server has told the client it can unicast).

The server doesn't need to make a determination as to what link the
client is on in the case of Release.   Decline probably does need to
go through the relay.

> Why does *HOW* the packet was sent make any difference? Remember, we're
> dealing with MANY addresses so an individual message's IAs have nothing to
> do with other IAs (and hence addresses) that client has.

If the packet goes through a relay, the relay can say on which link
the packet was received.  If it is unicast through a router, that is
not the case.  In the case where it is unicast through a router,
therefore, it doesn't make sense to check the prefix - we can only
assume that it is correct.  In the case where it is not correct, the
packet probably wouldn't have gotten to us, and even if it did somehow
get to us, we couldn't reply, because our reply will go to the link
where the prefix *is* valid.

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Thu, 19 Jul 2001 00:45:39 -0400 (EDT)

In the case of unicast the server first of all knows immediately it was
not sent thru the relay by the options.  it then know it was unicast.
yes the server must keep the ipv6 src address of the client for the prefix
check.  if the client got to the server the server can get to the client.

/jim