SQL

Configuration data

The following schemes apply to SQLite and MySQL.

The supplied file config.sql for client configuration contains this scheme:

CREATE TABLE hosts (
  hostname varchar(255) NOT NULL,
  mac varchar(1024) DEFAULT NULL,
  class varchar(255) DEFAULT NULL,
  address varchar(255) DEFAULT NULL,
  id varchar(255) DEFAULT NULL,
  duid varchar(255) DEFAULT NULL,
  PRIMARY KEY (hostname)
);

If client configuration should be read from a database it should be created with above scheme. A client can have these attributes:

  • hostname (required)
  • mac – more than one have to be separated by spaces
  • class
  • address – more than one have to be separated by spaces
  • id (0-FFFF) – will be used for one octet of IPv6 address
  • duid – more than one have to be separated by spaces

Depending on planned identification and address generation some fields have to be filled respectively.

If you already store your clients in a database create a view for translation or glue your database and the one used for dhcpy6d with some scripting.

Volatile data

The supplied file volatile.sql for leases and the MAC-LLIP-mapping contains this scheme:

CREATE TABLE leases (
  address varchar(32) NOT NULL,
  active tinyint(4) NOT NULL,
  preferred_lifetime int(11) NOT NULL,
  valid_lifetime int(11) NOT NULL,
  hostname varchar(255) NOT NULL,
  type varchar(255) NOT NULL,
  category varchar(255) NOT NULL,
  ia_type varchar(255) NOT NULL,
  class varchar(255) NOT NULL,
  mac varchar(17) NOT NULL,
  duid varchar(255) NOT NULL,
  last_update datetime NOT NULL,
  preferred_until datetime NOT NULL,
  valid_until datetime NOT NULL,
  iaid varchar(8) DEFAULT NULL,
  last_message int(11) NOT NULL DEFAULT 0,
  PRIMARY KEY (address)
);

CREATE TABLE macs_llips (
  mac varchar(17) NOT NULL,
  link_local_ip varchar(39) NOT NULL,
  last_update datetime NOT NULL,
  PRIMARY KEY (mac)
);

A database created with above schemes is used to store leases and the MAC-LLIP-mapping. This data is completely generated by dhcpy6d.
This database could be used for clustering (not yet implemented) and as replacement for DHCPv6 relaying. Due to being MAC-aware only on local network segments relaying is not possible. Using several dhcpy6d servers which share information in one central database might be a workaround therefore.