{ "Dhcp6":
{
- // Kea is told to listen on ethX network interface only.
- "interfaces-config": {
- "interfaces": [ "ethX" ],
+ // Kea is told to listen on ethX network interface only.
+ "interfaces-config": {
+ "interfaces": [ "ethX" ],
// This makes interfaces to be re-detected at each (re-)configuration.
// By default it is true.
"re-detect": true
- },
-
- // We need to specify the the database used to store leases. As of
- // September 2016, four database backends are supported: MySQL,
- // PostgreSQL, Cassandra, and the in-memory database, Memfile.
- // We will use memfile because it doesn't require any prior set up.
- "lease-database": {
- "type": "memfile",
- "lfc-interval": 3600
- },
-
-// Kea 0.9.1 introduced MAC/hardware addresses support in DHCPv6. There is
-// no single reliable method of getting MAC address information in DHCPv6.
-// Kea supports several methods. Depending on your network set up, some
-// methods may be more preferable than others, hence the configuration
-// parameter. 'mac-sources' is a list of methods. Allowed parameters are:
-// any, raw, duid, ipv6-link-local, client-link-addr-option, rfc6939 (which
-// is an alias for client-link-addr-option), remote-id, rfc4649 (which is an
-// alias for remote-id, subscriber-id, rfc4580 (which is an alias for
-// subscriber-id) and docsis.
-//
-// Note that the order matters. Methods are attempted one by one in the order
-// specified until hardware address is obtained. If you don't care which method
-// is used, using 'any' is marginally faster than enumerating them all.
-//
-// If mac-sources are not specified, a default value of 'any' is used.
- "mac-sources": [ "client-link-addr-option", "duid", "ipv6-link-local" ],
-
-// RFC6422 defines a mechanism called relay-supplied options option. The relay
-// agent may insert certain options that the server will echo back to the
-// client, if certain criteria are met. One condition is that the option must
-// be RSOO-enabled (i.e. allowed to be echoed back). IANA maintains a list
-// of those options here:
-// http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#options-relay-supplied
-// However, it is possible to allow the server to echo back additional options.
-// This entry marks options 110, 120 and 130 as RSOO-enabled.
- "relay-supplied-options": [ "110", "120", "130" ],
+ },
+
+ // We need to specify the the database used to store leases. As of
+ // September 2016, four database backends are supported: MySQL,
+ // PostgreSQL, Cassandra, and the in-memory database, Memfile.
+ // We will use memfile because it doesn't require any prior set up.
+ "lease-database": {
+ "type": "memfile",
+ "lfc-interval": 3600
+ },
+
+ // Kea 0.9.1 introduced MAC/hardware addresses support in DHCPv6. There is
+ // no single reliable method of getting MAC address information in DHCPv6.
+ // Kea supports several methods. Depending on your network set up, some
+ // methods may be more preferable than others, hence the configuration
+ // parameter. 'mac-sources' is a list of methods. Allowed parameters are:
+ // any, raw, duid, ipv6-link-local, client-link-addr-option, rfc6939 (which
+ // is an alias for client-link-addr-option), remote-id, rfc4649 (which is an
+ // alias for remote-id, subscriber-id, rfc4580 (which is an alias for
+ // subscriber-id) and docsis.
+ //
+ // Note that the order matters. Methods are attempted one by one in the
+ // order specified until hardware address is obtained. If you don't care
+ // which method is used, using 'any' is marginally faster than enumerating
+ // them all.
+ //
+ // If mac-sources are not specified, a default value of 'any' is used.
+ "mac-sources": [ "client-link-addr-option", "duid", "ipv6-link-local" ],
+
+ // RFC6422 defines a mechanism called relay-supplied options option. The
+ // relay agent may insert certain options that the server will echo back to
+ // the client, if certain criteria are met. One condition is that the option
+ // must be RSOO-enabled (i.e. allowed to be echoed back). IANA maintains a
+ // list of those options here:
+ // http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#options-relay-supplied
+ // However, it is possible to allow the server to echo back additional
+ // options. This entry marks options 110, 120 and 130 as RSOO-enabled.
+ "relay-supplied-options": [ "110", "120", "130" ],
// This defines a control socket. If defined, Kea will open a UNIX socket
// and will listen for incoming commands. See section 15 of the Kea User's
"socket-name": "/tmp/kea6-ctrl-socket"
},
-// Addresses will be assigned with preferred and valid lifetimes
-// being 3000 and 4000, respectively. Client is told to start
-// renewing after 1000 seconds. If the server does not respond
-// after 2000 seconds since the lease was granted, client is supposed
-// to start REBIND procedure (emergency renewal that allows switching
-// to a different server).
- "preferred-lifetime": 3000,
- "valid-lifetime": 4000,
- "renew-timer": 1000,
- "rebind-timer": 2000,
-
- // The following list defines subnets. Each subnet consists of at
- // least subnet and pool entries. Note the user-context being
- // used throughout the definitions. This is something that is not
- // being used by Kea, it's simply parsed and stored in appropriate
- // structures. You can put anything you want in the user-context
- // as long as it is a valid JSON.
- "subnet6": [
+ // Addresses will be assigned with preferred and valid lifetimes
+ // being 3000 and 4000, respectively. Client is told to start
+ // renewing after 1000 seconds. If the server does not respond
+ // after 2000 seconds since the lease was granted, client is supposed
+ // to start REBIND procedure (emergency renewal that allows switching
+ // to a different server).
+ "preferred-lifetime": 3000,
+ "valid-lifetime": 4000,
+ "renew-timer": 1000,
+ "rebind-timer": 2000,
+
+ // The following list defines subnets. Each subnet consists of at
+ // least subnet and pool entries. Note the user-context being
+ // used throughout the definitions. This is something that is not
+ // being used by Kea, it's simply parsed and stored in appropriate
+ // structures. You can put anything you want in the user-context
+ // as long as it is a valid JSON and it starts with a map (i.e.
+ // is enclosed by curly brackets).
+ "subnet6": [
{
"pools": [
{
// Here's the user-context for the whole subnet.
"user-context": { "comment": "Floor one, west wing" },
-// This defines PD (prefix delegation) pools. In this case
-// we have only one pool. That consists of /64 prefixes
-// being delegated out of large /48 pool. Each delegated
-// prefix will contain an excluded-prefix option.
- "pd-pools": [
- {
- "prefix": "2001:db8:abcd::",
- "prefix-len": 48,
- "delegated-len": 64,
- "excluded-prefix": "2001:db8:abcd:1234::",
- "excluded-prefix-len": 62,
-
- // Another user-context for this PD pool. Again, you can put anything
- // you want in there as long as it's valid JSON.
- "user-context": {
- "purpose": "For CPE devices"
- }
- }
- ],
- "subnet": "2001:db8:1::/64",
- "interface": "ethX",
-
- // Sometimes the relay may use an odd IPv6 address that's not matching
- // the subnet. This is discouraged, but there are valid cases when it
- // makes sense. One case is when the relay has only link-local address
- // and another is when there is a shared subnet scenario.
- "relay": {
- "ip-address": "3000::1"
- }
+ // This defines PD (prefix delegation) pools. In this case
+ // we have only one pool. That consists of /64 prefixes
+ // being delegated out of large /48 pool. Each delegated
+ // prefix will contain an excluded-prefix option.
+ "pd-pools": [
+ {
+ "prefix": "2001:db8:abcd::",
+ "prefix-len": 48,
+ "delegated-len": 64,
+ "excluded-prefix": "2001:db8:abcd:1234::",
+ "excluded-prefix-len": 62,
+
+ // Another user-context for this PD pool. Again, you can put
+ // anything you want in there as long as it's valid JSON and
+ // starts with a map.
+ "user-context": {
+ "purpose": "For CPE devices"
+ }
+ }
+ ], // end of pools
+
+ "subnet": "2001:db8:1::/64",
+ "interface": "ethX",
+
+ // Sometimes the relay may use an odd IPv6 address that's not matching
+ // the subnet. This is discouraged, but there are valid cases when it
+ // makes sense. One case is when the relay has only link-local address
+ // and another is when there is a shared subnet scenario.
+ "relay": {
+ "ip-address": "3000::1"
+ }
}
- ]
+ ]
},
// The following configures logging. It assumes that messages with at
projects / thirdparty / kea.git / commitdiff
