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

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

Why?

The Confirm is multicast by the client, picked up a relay and sent to a server.

The server can return the Reply the same way.

Or, what about the case where the client and server are on the same link?

In both these cases all the client needs is a valid link local address. Nothing
else to communicate between client/server.

- Bernie

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

> For example, if a server receives a Confirm for a global prefix it has no 
> knowledge of, why does it care where it came from? If it can send a Reply
> back to the client, it can tell it - hey, you're using invalid prefixes.

Sure.  But it can't get such a unicast message unless the client
already has an address with a valid prefix (by valid, I mean that the
server can successfully send a packet to the client, not just that a
site-local prefix looks valid by coincidence).  So this case isn't one
that we need to deal with, as far as I can see.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Jul 2001 16:35:55 -0700

> The Confirm is multicast by the client, picked up a relay and sent

Right, and that's why the language you wrote applies to the Confirm
message!

			       _MelloN_

---

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

in the case of a relay this will work yes.  but not for unicast.
in that case the server will get the packet and be e2e with the relay not
the client.  all should work that way and our new prefix error code if it
applies.

/jim

---

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

yep I agree?  are we all in violent agreement !!!!!

/jim