DHCPv6 address allocation, was: Re: problem with dhcp setup

[Shane Kerr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Suprasad Mutalik Desai wrote:
> I understand about using prefix /128 in the dhcp-4.0.0a1 version , but
> wat u said is
> same as using fixed-address6 . with the prefix /64 i get a random IPv6
> address assigned to my host . Is there any addressing mechanism behind
> it ?

The mechanism is actually deterministic, but designed to spread addresses across
the space.


How It Works
- ------------

First the server attempts to use whatever address the client requested. If it is
free, then it is given to the client.

If no address is requested, or the requested address is not available, then the
mechanism is:

- - make an MD5 hash of the client DUID
- - combine the upper bits from the network with lower bits from the hash (we
  throw away any part of the hash that we don't need)
- - if the address is not free, rehash including the address we just got and
  try again (up to 100 attempts)


Collision Handling
- ------------------

For most IPv6 networks, we expect MD5 collisions to be rare. A /96 network with
1 million clients on it has less than a 0.03% chance of collision on any given
client. But for very small, almost full networks, we will churn a bit on the
server side. If this is a problem, we may add alternate methods for picking
addresses in the future, perhaps based on the size of the subnet.


Converting Ranges to CIDR-style Subnets
- ---------------------------------------

This algorithm assumes CIDR-style subnets. But we allow any arbitrary start and
end addresses in the range6 statement, so we must convert those to a set of
subnets.  So if you have a range:

   ffff:ffff:ffff::8000  ffff:ffff:ffff::8011

It will become these two CIDR-style networks:

   ffff:ffff:ffff::8000/4
   ffff:ffff:ffff::8010/2

We are lazy, and simply allocate addresses from the first available network
until we have a collision, and then we switch to the other network. The reason
that we switch is that otherwise certain types of operator error would slow the
server down. A typical case might be:

   1:2:3:4:: 1:2:3:5::

The user probably wanted 1:2:3:4:ffff:ffff:ffff:ffff for the second address. But
it actually becomes:

   1:2:3:4::/64
   1:2:3:5::/128

We will try the /128 only very rarely, which is probably what the user wants.

This may be confusing to administrators who pick a range that is, for example, a
range that includes a /64 and a /96, because they will see all the allocations
from one of these two subnets for a long time, until one day the server switches
to the other subnets. If this is a problem, we may come up with some sort of
"load balancing" between available subnets in the future.


Security
- --------

We use MD5 hashing based on the client DUID to pick addresses. This is
completely deterministic. It might be better to stir in a secret on the server
side, to make them unpredictable, at least optionally. I'm not sure what the
security risks are, and whether these outweigh the operational problems with no
longer being able to predict what address a given client will get.

- --
Shane
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGcR9XMsfZxBO4kbQRAq3AAJsFGCwF+t7gYPcY2teMQvdD5J9eyACgs2FJ
FCWp2JbGS5rBuuidYJq2ozk=
=e4yr
-----END PGP SIGNATURE-----