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

From: [email-masked]
Date: Wed, 18 Jul 2001 16:16:36 -0700

unsubscribe

                                                          

"Bernie Volz (EUD)" <[email-masked]> on 07/18/2001 04:10:07 PM

Please respond to [email-masked]

 To:      "DHCPv6 discussion list" <[email-masked]>     
                                                              
 cc:      (bcc: Relfe Tan/SB/GAPINC)                          

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

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

unsubscribe

                                                          

                                                              

                                                              

- 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]

                      _MelloN_

---

From: [email-masked]
Date: Wed, 18 Jul 2001 16:16:49 -0700

unsubscribe

                                                          

                                                              

                                                              

- 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]

                      _MelloN_

---

From: [email-masked]
Date: Wed, 18 Jul 2001 16:17:02 -0700

unsubscribe

                                                          

                                                              

                                                              

- 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]

                      _MelloN_

---

From: [email-masked]
Date: Wed, 18 Jul 2001 16:17:10 -0700

unsubscribe

                                                          

                                                              

                                                              

- 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]

                      _MelloN_

---

From: [email-masked]
Date: Wed, 18 Jul 2001 16:17:15 -0700

unsubscribe

                                                          

                                                              

                                                              

- 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]

                      _MelloN_

---

From: [email-masked]
Date: Wed, 18 Jul 2001 16:17:21 -0700

unsubscribe

                                                          

                                                              

                                                              

- 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]

                      _MelloN_

---

From: [email-masked]
Date: Thu, 19 Jul 2001 08:53:22 -0700

been trying to unsubscribe..

                                                          

"Jim Bound" <[email-masked]> on 07/18/2001 09:58:57 PM

                                                              

                                                              

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

/jim

On Wed, 18 Jul 2001, Ted Lemon wrote:

>
> > The Confirm is multicast by the client, picked up a relay and sent
> > to a server.
>
> Right, and that's why the language you wrote applies to the Confirm
> message!
>
>                     _MelloN_
>

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 19 Jul 2001 12:40:32 -0500

I meant the prefix of each address in the IA(s) in the client's
message. Not the IP source address of the client's message -
that is meaningless in terms of where the client is unless
it is a link local address (since then the server knows it is
on the received interface).

Depending on what checking routers will do, the IP source address
of a packet can easily be wrong (or let us say invalid for the
link the packet came from). I don't recall what the requirements
on routers are in IPv6 with regard to source address checking, so
perhaps this can't happen in IPv6. But most IPv4 routers don't
check source addresses (except when exit filters are added).

If we allow client unicast (per option 18.10) there are three
possibilities for how messages are delivered to the server:
1. On-link - the client is on the same link as the server, source
address will be link-local.
2. Relayed - the client's message will be in a Relay-forward and
the source address will be the relay's, not the client's.
3. Unicast - the client unicasts the message and therefore must
use a source address of suitable scope. (See above regarding how
reliable this information may be.)

- Bernie

-----Original Message-----
From: Jim Bound [mailto:[email-masked]]
Sent: Thursday, July 19, 2001 12:35 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] 

yep...

/jim

On Wed, 18 Jul 2001, Ted Lemon wrote:

> 
> > if the server checks the prefix of the renew it can know?
> 
> You mean the IP source address?   True enough.
> 
> 			       _MelloN_
>

---

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

I third this (agree with Ted and Ralph).

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, July 19, 2001 3:59 PM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] 

I agree with Ted - my intuition is that allowing the relay to do IA prefix 
checking is potentially dangerous.  To me, it introduces the requirement 
that we push detailed knowledge of network configuration out across lots of 
devices, where misconfiguration can cause significant problems for DHCP 
clients.  Even if we suppose that the relay can dive into other local 
information on the router, that information may not be complete enough to 
correctly make decisions about prefix validity.

- Ralph

At 11:46 AM 7/19/2001 -0700, Ted Lemon wrote:

> > No, the relay need not to be stateful. It can just compare the
> > prefix of Source IP address of the client packet and has to compare
> > with the prefix of its interface in which it is received. It don't need
> > to parse the packet. It has to just see the sender's address, that's all.
> > But, this prevent the more and more processing that going to be
> > happened on the servers. I think, including this functionality in the relay
> > won't be a big problem.
>
>This is true; the only concern is that the relay may not have complete
>knowledge of the network configuration, and in that case it could
>cause some serious breakage.   I like the idea of saving work by
>having the relay generate the Invalid Prefix result, but I think it
>should be approached with great caution.
>
>                                _MelloN_

---

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

Off the top of my head, the text Bernie cites in the "Server Unicast 
Option" is in error.  Confirm messages should always be multicast because 
the client has no way to determine if any of its source addresses are valid.

- Ralph

At 06:10 PM 7/18/2001 -0500, Bernie Volz (EUD) wrote:

>From: Ted Lemon [<mailto:[email-masked]>mailto:[email-masked]]

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 19 Jul 2001 16:11:37 -0500

See below - for clarity, my comments prefixed by BV>. I also cut
those items where I have no comments.

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, July 19, 2001 4:55 PM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes]

At 10:01 AM 7/18/2001 -0500, Bernie Volz (EUD) wrote:

>2) Add to 14.4.1, 14.4.2, 14.4.4:
>
>    If the server finds that the prefix on one or more IP addresses in
>    any IA in the {Request,Confirm,Rebind} message is not a valid
>    prefix for the link to which the client is connected, the server
>    MUST send an NoPrefixMatch status in the IA status field for that
>    IA in the DHCP Reply message.
>
>    [Should we include Renew in the message list and add to 14.4.3?]

Yes, I think we can include Renew.  I suggest the following change to the 
first sentence:  If the server can determine that the prefix on any of the 
IP addresses in an IA in the XXX message is not a valid prefix for the link 
to which the interface from which the message was received is connected, 
the server MUST send [...]

BV> Fine by me.

>3) Add to Section 14.3.5. (Receipt of Reply message in response
>    to a Request, Confirm, Renew or Rebind message):
>
>    When the client receives a NoPrefixMatch error status in the IA status
>    field of a Reply to a Confirm message, the client MUST make a
>    determination as to whether it has moved to a different link.  If the
>    client is unable to make such a determination it MUST assume that it
>    has moved to a new link.  In this case the client MAY discard the IA
>    that received the NoPrefixMatch status, or may retain it as long as
>    the addresses in the IA continue to be valid.

Why should the client make a determination about moving to a new link?  In 
fact, how can it make that determination at this point, which is, I think, 
after the point at which the client may have received an event from its 
interface about loss of carrier, change of access point, etc.?  I suggest 
the following text:

When the client receives a NoPrefixMatch error status in the IA status 
field of a Reply to a Confirm (what about Request and Rebind?) message, the 
client MUST not use any of the addresses in the IA.

BV> For Confirm, this sounds fine to me.
BV> Can this happen on a Request? No addresses in the IA. So, not
BV> possible?
BV> For Renew, this sounds fine as well (since the original server is
BV> responding).
BV> For Rebind, I think this would be OK as well but we may want to
BV> factor in the level of trust to prevent denial of service attacks.
BV>
BV> Note also that for Confirm and Rebind, many servers could respond.
BV> It may be advisable for a client to wait a short time after receiving
BV> the NoPrefixMatch to see what other servers have to say about the
BV> addresses. If a client gets multiple NoPrefixMatch, it may believe it.
BV> If a client gets multiple confusing responses, what should it do?
BV> (Perhaps that a reason not to wait!)
BV> Again, the level of trust may be factored in to the decision.

Regarding your last sentence - what does it mean to "discard" an IA?

BV> Discarding an IA means to completely and utterly remove it from the
BV> client's memory. It drops any reference to the addresses in the IA.
BV> Some clients may have limited resources and therefore feel that there
BV> is no reason to keep something that appears to be useless (for now
BV> at least). These addresses are discard although their valid and/or
BV> preferred lifetimes have not yet expired.

---

From: Droms Ralph <[email-masked]>
Date: Thu, 26 Jul 2001 11:54:52 -0400

At 09:18 AM 7/26/2001 -0500, Bernie Volz (EUD) wrote:

>The new text works for me.

OK...

>Regarding your other issue:
>"In the middle of writing my previous message, I had the following thought:
>suppose the link has been renumbered - the addresses in the IA will be
>invalid although the client has remained connected to the same link..."
>
>Isn't this a violation of the address lifetimes? If the lifetimes are
>maintained properly, this should never happen.

Right - but this behavior is mandated in DHCPv4 (well, I guess RFC2131 
isn't exactly clear about a DHCPNAK in response to DHCPRENEW), even though 
it constitutes a violation of the lease.  Perhaps the difference is that a 
"lease" constitutes an agreement about a period of time during which a 
server will not reassign an address, while a "lifetime" describes a period 
of time during which an address will be valid on a link.

>And, what's the impact? Won't the server send a NoPrefixMatch in this case
>because the client's prefixes aren't valid - though the client is still on
>the same link? In that case, the client will simply either believe the
>NoPrefixMatch and go through Solicit/Advertise or it will ignore the
>NoPrefixMatch in which case the lifetimes will expire the address anyway.

Yeah, but the client may well be unable to exchange IPv6 datagrams because 
it's insisting on using addresses that aren't valid until the lifetimes expire.

- Ralph

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 26 Jul 2001 11:20:14 -0500

>it's insisting on using addresses that aren't valid until the lifetimes expire.

Not much we can do about it though is there?

While a "fix" for this case could be to make a client not use the addresses if it
gets a NoPrefixMatch, that may be wrong in other situations.

I believe that we want to encourage a client to assume that it has changed links
or something pretty drastic has happened when it receives a NoPrefixMatch, but we
want to leave an out that says a client MAY take other actions if it has
information that the NoPrefixMatch might be in error (such as it is now on an
"overlapping" link, it has received other information, such as Router Advertisements,
that validate the addresses or some of the addresses, or perhaps it otherwise
believes the NoPrefixMatch message to be in error [such as sent by an unauthorized
server]).

>it's insisting on using addresses that aren't valid until the lifetimes expire.

Hopefully the client will figure out something's wrong because of ICMP errors it
receives or because of its inability to communicate? [Perhaps this is further input
to the client in making its determination that the link has changed.] But, if not,
then it will recover once the preferred lifetime expires since it won't be able to
"renew" the lifetimes. 

- Bernie

-----Original Message-----
From: Droms Ralph [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 11:55 AM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] 

OK...

- Ralph

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Fri, 27 Jul 2001 11:06:45 -0500

If so, what does this really mean?

... that the Confirm simply tells the client whether the addresses can
or can not be used and the reason may be (a) client has moved to a new
link or (b) some event happened while it was "gone" and its existing
addresses are no longer valid.

So, doesn't this reinforce what Ted was suggesting all along ... the
Reply to a Confirm that has a "NoPrefixMatch" status in the IA Option is just
input to the client that it *MAY* have moved to a new link but does not
necessarily mean it *HAS* moved to a new link.

Anyway, the action for the client is the same ... do not use the addresses
and go back to the Solicit "state" to find a server with which to communicate
and Request addresses.

- Bernie

-----Original Message-----
From: Jim Bound [mailto:[email-masked]]
Sent: Friday, July 27, 2001 11:48 AM
To: DHCPv6 discussion list
Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] 

In IPv6 the prefixes could be deprecated to 2 hours by a router. So it
could happen.  Or by the dhcpv6 serverr.

/jim

On Thu, 26 Jul 2001, Bernie Volz (EUD) wrote:

> Ralph, et al:
> Note: There will probably be instances because of clock differences where
> a client may still believe an address to be valid when it truely is not.
> But that condition should only last for short periods of time and it is
> adviseable that there be some "grace" involved in lifetimes.
> 
> - Bernie
> 
> Sent: Thursday, July 26, 2001 8:28 AM
> At 02:17 PM 7/19/2001 -0700, Ted Lemon wrote:
> 
> >This is the multiple overlapping link layers problem - a 3G cell phone
> >that is able to contact two different cell towers.  The client in this
> >case has information that the server does not have, and is probably
> >talking to more than one server, and therefore is in a position to
> >know that it can continue to use its addresses.
> 
> OK, now I get it.  I misunderstood the phrase "whether it has moved to a 
> different link."  In some sense, if the client is communicating with 
> overlapping links, it has, in fact, moved to a new link.  It is still on 
> the old link, as well...
> 
> Is it more that the client can determine, through some other means, that 
> the addresses in an IA are valid although some server - through 
> misconfiguration, overlapping links, ??? - has indicated that the addresses 
> are not valid?  I suggest the following text in section 14.3.5 (rev -19):
> 
>     field of a Reply to a Confirm, Rebind or Renew message, if the client
>     can determine through some other means that the addresses in the IA
>     are valid for the link to which the interface is attached, the client
>     MAY choose to ignore the NoPrefixMatch error.  Examples of ways a client
>     can determine the validity are: examining prefixes in router
>     advertisements, receipt of a Confirm message from a different server
>     that indicates validity of the addresses in the IA, link-layer
>     specific mechanisms through which the client can determine that it
>     is currently connected to the link for which the client previously
>     determined that the addresses in the IA were valid.
> 
>     After receiving a NoPrefixMatch error status in the IA status
>     field of a Reply to a Confirm, Rebind or Renew message, if the client
>     cannot independently determine that the addresses in the IA are still
>     valid, the client MUST NOT use any of the addresses in the IA.
> 
> - Ralph