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

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

One more comment ... in some cases (agreed not all) a server *CAN* determine
that a prefix is invalid in its domain regardless of where the client actually
is.

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.

If relays are configured incorrectly and forwarding packets to where they
shouldn't be going, that's not the servers fault.

Again, the entire point of the NoPrefixMatch is to tell the client quickly
that it may have moved. So, one bad prefix in a list of addresses (regardless
of whether that server even has any knowledge of that client or that IA) is
sufficient to communicate that to the client quickly and effectively.

Just returning NoBinding or another error doesn't help the client at all.

- 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: Ted Lemon <[email-masked]>
Date: Wed, 18 Jul 2001 16:23:57 -0700

> 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: Jim Bound <[email-masked]>
Date: Thu, 19 Jul 2001 00:50:03 -0400 (EDT)

but since the discussion brought up by ted. I would now check the prefix
for all clients on any msg-type.  I think we have defined something that
will need to be inherent in dhcpv6 implementations now.  whether forwarded
by relay or direct unicast from the client.  I also think its a good idea
esp for mobile nodes.

/jim

---

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

that is why we say that a client must have sufficient scope often in the
spec and also in some cases state the client should use a global address.

A client that tries sending site to global scope will get bounced by the
router in ipv6 too it won't be allowed to get to the server fyi.  This is
the ipv6 scoping rules for routing.

/jim