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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 12 Jul 2001 13:20:34 -0500

Ted:

My only concern is the one I raised as to why I think the 32-bit XID should be considered and that is exactly what you state in your response:

"as long as the client doesn't use a transaction ID number for any transaction that it remembers, there will never be a collision."

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! [Note that if there is NO stable storage, then perhaps the DHID will be different each time and hence this isn't an issue; however the DHID could be based on a serial number and hence could be the same each time regardless of the lack of stable storage.]

Perhaps a compromise is to add a 8-bit 'secs' field (perhaps calling it a 'retry' field and simply counting the number of retransmissions with the counter staying at 255 once it reaches that) and increase the XID from 16-bits to 24-bits? At least that reduces the chance by 256 times over the 16-bit value. While it doesn't align the header on a 32-bit boundry, it would align it on a 16-bit boundry.

One other minor point to consider for the XID cache ... depending on how the lifetimes are determined for addresses, the server MIGHT need to update these in the response to the client. For example, if a server has a configuration that says give out a lifetime of X with an expiration of the prefix at Y, then as the current time approaches Y, the lifetime has to be reduced. If the cache is allowed to exist for several minutes, the lifetimes won't be run down and the client might consider an address valid for longer than it should. So, cache times should be short.

We might even ask is the cache really worth it? If we REMOVED it, it would solve all the problems and we can use a 16-bit XID since all that would be used for is to match up active transactions, not past transactions. (Well, there is always the case that an old reply that was delayed by the network is received for a new request when the client reboots. But that's hopefully unlikely because of the time for reboots, etc.)

- Bernie

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

> 3. Is the 16-bit Transaction ID really sufficient? I would like to
> understand why reducing the number of bits from 32 (DHCPv4) to 16 is
> justified. A 1 out of 65536 chance is a lot higher than a 1 out of
> 2^32 chance of a collision.  Especially if clients don't have stable
> storage to save the last transaction ID (or don't want the 'cost' of
> using stable storage for this).

Hm, on second thought, here's the thing: the packet is being unicast
through the relay agent (or directly) to the client's link-local
address.   This is a completely different situation from DHCPv4, where
all responses to unconfigured clients were broadcast, and therefore
an XID collision was a real possibility.

So we don't have to consider statistical odds of a collision - as long
as the client doesn't use a transaction ID number for any transaction
that it remembers, there will never be a collision.

So there's no need for a 32-bit xid after all - 16 bits should be
plenty.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jul 2001 11:33:02 -0700

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