1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
|
// This is an example configuration file for DHCPv6 server in Kea.
// It attempts to showcase some of the more advanced features.
// Topology wise, it's a basic scenario with one IPv6 subnet configured.
// It is assumed that one subnet (2001:db8:1::/64) is available directly
// over eth0 interface.
//
// The following features are currently showcased here:
// 1. Configuration of MAC/hardware address sources in DHCPv6
// 2. RSOO (Relay supplied options) - Some relays may insert options with the
// intention for the server to insert them into client directed messages.
// 3. Control socket. Kea can open a socket and listen for incoming
// commands.
{ "Dhcp6":
{
// Kea is told to listen on eth0 network interface only.
"interfaces-config": {
"interfaces": [ "eth0" ],
// This makes interfaces to be re-detected at each (re-)configuration.
// By default it is true.
"re-detect": true
},
// We need to specify the database used to store leases. As of
// June 2022, three database backends are supported: MySQL,
// PostgreSQL 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
},
"sanity-checks": {
// This parameter determines what to do when a new lease appears in the
// system (i.e. either is read from disk during memfile startup or is
// added via lease commands). There are five modes supported:
// none - do nothing, accept them as is
// warn - if subnet-id problems are detected, print a warning, but
// otherwise load the lease as is. This is the default value.
// fix - attempt to fix the lease by finding appropriate subnet-id value.
// if there is no suitable subnet, the lease is loaded as is.
// fix-del - attempt to fix the lease by finding appropriate subnet-id
// value. If there is no suitable subnet, the lease is deleted.
// del - delete leases that have incorrect subnet-id values.
"lease-checks": "fix-del"
},
// 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
// Guide for list of supported commands.
"control-socket": {
"socket-type": "unix",
"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 and it starts with a map (i.e.
// is enclosed by curly brackets).
// A comment entry is translated into a user-context with a
// "comment" property so you can include comments inside the
// configuration itself.
"subnet6": [
{
"pools": [
{
"pool": "2001:db8:1::/80",
// This is user context specified for this particular
// pool. You can use it to describe the pool in some way.
// Just keep in mind that the structure will not be used
// by Kea itself. It will be made available to hooks if
// they want to use it.
"user-context": { "department": "engineering" }
}],
// Here's the user-context for the whole subnet.
"user-context": { "comment": "Floor one, west wing" },
// Equivalent using smart parser
// "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:0:1234::",
"excluded-prefix-len": 80,
// 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": "eth0",
// 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
// least informational level (info, warn, error and fatal) should be
// logged to stdout.
"loggers": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "stdout",
// Several additional parameters are possible in addition
// to the typical output. Flush determines whether logger
// flushes output to a file. Maxsize determines maximum
// filesize before the file is being rotated. maxver
// specifies the maximum number of rotated files being
// kept.
"flush": true,
"maxsize": 204800,
"maxver": 4,
// We use pattern to specify custom log message layout
"pattern": "%d{%y.%m.%d %H:%M:%S.%q} %-5p [%c/%i] %m\n"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}
|
