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

John Jason Brzozowski john_brzozowski at cable.comcast.com
Thu Jun 14 11:07:54 UTC 2007


The *option* to randomize would be a good feature.

John


On 6/14/07 6:58 AM, "Shane Kerr" <Shane_Kerr at isc.org> wrote:

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

=========================================
John Jason Brzozowski (CISSP, RHCT)
Comcast Corporation
e) mailto:john_brzozowski at cable.comcast.com
m) 609-377-6594
p) 856-324-2671
=========================================



More information about the dhcp-users mailing list