dhcp  4.3.6-P1
About: ISC DHCP implements the "Dynamic Host Configuration Protocols" for connection to a local network. 4.3.x release series.
  Fossies Dox: dhcp-4.3.6-P1.tar.gz  ("inofficial" and yet experimental doxygen-generated source code documentation)  

IPv6 Structures Overview

A brief description of the IPv6 structures as reverse engineered.

There are four major data structures in the lease configuraion.

  • shared_network - The shared network is the outer enclosing scope for a network region that shares a broadcast domain. It is composed of one or more subnets all of which are valid in the given region. The share network may be explicitly defined or implicitly created if there is only a subnet statement. This structrure is shared with v4. Each shared network statment or naked subnet will map to one of these structures
  • subnet - The subnet structure mostly specifies the address range that could be valid in a given region. This structute doesn't include the addresses that the server can delegate those are in the ipv6_pool. This structure is also shared with v4. Each subnet statement will map to one of these structures.
  • ipv6_pond - The pond structure is a grouping of the address and prefix information via the pointers to the ipv6_pool and the allowability of this pool for given clinets via the permit lists and the valid TIMEs. This is equivilent to the v4 pool structure and would have been named ip6_pool except that the name was already in use. Generally each pool6 statement will map to one of these structures. In addition there may be one or for each group of naked range6 and prefix6 statements within a shared network that share the same group of statements.
  • ipv6_pool - this contains information about a pool of addresses or prefixes that the server is using. This includes a hash table that tracks the active items and a pair of heap tables one for active items and one for non-active items. The heap tables are used to determine the next items to be modified due to timing events (expire mostly).

The linkages then look like this:

*+--------------+   +-------------+
*|Shared Network|   | ipv6_pond   |
*|   group      |   |   group     |
*|              |   | permit info |
*|              |   |    next    ---->
*|    ponds    ---->|             |
*|              |<----  shared    |
*|   Subnets    |   |    pools    |
*+-----|--------+   +------|------+
*      |  ^                |    ^
*      |  |                v    |
*      |  |         +-----------|-+
*      |  |         | ipv6_pool | |
*      |  |         |    type   | |
*      |  |         |   ipv6_pond |
*      |  |         |             |
*      |  |         |    next    ---->    
*      |  |         |             |
*      |  |         |   subnet    |
*      |  |         +-----|-------+
*      |  |               |
*      |  |               v
*      |  |         +-------------+
*      |  |         |   subnet    |
*      |  +----------   shared    |
*      +----------->|             |
*                   |   group     |
*                   +-------------+
*
* The shared network contains a list of all the subnets that are on a broadcast
* doamin.  These can be used to determine if an address makes sense in a given
* domain, but the subnets do not contain the addresses the server can delegate.
* Those are stored in the ponds and pools.
*
* In the simple case to find an acceptable address the server would first find
* the shared network the client is on based on either the interface used to 
* receive the request or the relay agent's information.  From the shared 
* network the server will walk through it's list of ponds.  For each pond it 
* will evaluate the permit information against the (already done) classification.
* If it finds an acceptable pond it will then walk through the pools for that
* pond.  The server first checks the type of the pool (NA, TA and PD) agaisnt the
* request and if they match it attemps to find an address within that pool.  On
* success the address is used, on failure the server steps to the next pool and
* if necessary to the next pond.
*
* When the server is successful in finding an address it will execute any
* statements assocaited with the pond, then the subnet, then the shared
* network the group field is for in the above picture).
*
* In configurations that don't include either a shared network or a pool6
* statement (or both) the missing pieces are created.
* 
*
* There are three major data structuress involved in the lease database:
*
* - ipv6_pool - see above
* - ia_xx   - this contains information about a single IA from a request
*             normally it will contain one pointer to a lease for the client
*             but it may contain more in some circumstances.  There are 3
*             hash tables to aid in accessing these one each for NA, TA and PD.
* - iasubopt - the v6 lease structure.  These are created dynamically when
*              a client asks for something and will eventually be destroyed
*              if the client doesn't re-ask for that item.  A lease has space
*              for backpointers to the IA and to the pool to which it belongs.
*              The pool backpointer is always filled, the IA pointer may not be.
*
* In normal use we then have something like this:
*
* \verbatim
* ia hash tables
*  ia_na_active                           +----------------+
*  ia_ta_active          +------------+   | pool           |
*  ia_pd_active          | iasubopt   |<--|  active hash   |
* +-----------------+    | aka lease  |<--|  active heap   |
* | ia_xx           |    |  pool ptr  |-->|                |
* |  iasubopt array |<---|  iaptr     |<--|  inactive heap |
* |   lease ptr     |--->|            |   |                |
* +-----------------+    +------------+   +----------------+
* 

For the pool either the inactive heap will have a pointer or both the active heap and the active hash will have pointers.

I think there are several major items to notice. The first is that as a lease moves around it will be added to and removed from the address hash table in the pool and between the active and inactive hash tables. The hash table and the active heap are used when the lease is either active or abandoned. The inactive heap is used for all other states. In particular a lease that has expired or been released will be cleaned (DDNS removal etc) and then moved to the inactive heap. After some time period (currently 1 hour) it will be freed.

The second is that when a client requests specific addresses, either because it previously owned them or if the server supplied them as part of a solicit, the server will try to lookup the ia_xx associated with the client and find the addresses there. If it does find appropriate leases it moves them from the old IA to a new IA and eventually replaces the old IA with the new IA in the IA hash tables.