Subject: RE: Discussion items for dhcpv6 -19 draft ...

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 12 Jul 2001 14:36:22 -0500

1. Client issues a DHCPv6 Renew to renew IA 565 with XID 10.

2. Client crashes before getting response from server.

3. Client boots (and doesn't have stable storage regarding XIDs) and issues a DHCPv6 Request for IA 123 with XID 10.

4. Client gets back the cached Reply for IA 565 and not IA 123 as a Reply to its request (XID 10).

Now, it depends on how the client processes this. Based on some new language in the -19 draft, the client might assume that IA 565 was already allocated to it and add it to its addresses (this is to allow for Reconfigure-Init processing). Or, perhaps the client 'ignores' the Reply?

In any case, the client still has no assignment for IA 123 so does it assume XID 10 is done or re-request it? If it re-requests it, it will still get the cached reply (and hence still have no valid response). Etc. Especially if the server restarts the timer on flushing that particular XID with reach request.

So, perhaps the client gets no address for the IA (or it takes a while until the cached entry expires) AND/OR it uses addresses that it really didn't request (in this boot).

Does this really break anything? Perhaps not. Is it proper behavoir, NO.

There are other ways to fix this issue:
- Add the client 'request' type to the XID cache.
- Add the IAIDs to the XID cache (this may be more to simply match up the IAIDs in the cached reply with those in the request).

Note that a 32-bit XID doesn't really solve the problem, it just reduces the chance it will happen.

Does this answer you request for a 'real-world scenario'? Or, is my scenario broken in some way?

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, July 12, 2001 2:33 PM
To: DHCPv6 discussion list
Subject: Re: Discussion items for dhcpv6 -19 draft ... 

> The issue is that if DHCPv6 is on a client that has limited
> resources (and hence no stable storage), how can it be sure that
> when it starts DHCPv6 and has to 'randomly' pick an XID that it
> isn't one that was recently used? A 1 out of 65536 chance is fairly
> decent odds that you'll get a collision. Using 32 bits would reduce
> this chance by 65536 times!

I don't understand what sort of problem you expect this to cause.
Can you describe a real-world scenario where this could result in
something bad happening?

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jul 2001 13:46:30 -0700

> Does this really break anything?   Perhaps not.   Is it proper
> behaviour?   NO.

A client with no non-volatile storage probably can't form a different
query after it crashes, so the cached response should be identical to
the previous response anyway.

The DHCP server has to check the outgoing packet to make sure it's to
the right client, based on the DUID, so I think that your proposed
solution of making it check the IAIDs as well is probably the right
one - this is a _lot_ less work than a database lookup, so it's still
a win.

			       _MelloN_