// when they get their own client-id. Kea can disable RFC6842 support.
"echo-client-id": false,
- // Some clients don't use stable client identifier, but rather generate them
- // during each boot. This may cause a client that reboots frequently to get
- // multiple leases, which may not be desirable. As such, sometimes admins
- // prefer to tell their DHCPv4 server to ignore client-id value altogether
- // and rely exclusively on MAC address. This is a parameter that is defined
- // globally, but can be overridden on a subnet level.
+ // Some clients don't use stable client identifier, but rather
+ // generate them during each boot. This may cause a client that
+ // reboots frequently to get multiple leases, which may not be
+ // desirable. As such, sometimes admins prefer to tell their DHCPv4
+ // server to ignore client-id value altogether and rely exclusively
+ // on MAC address. This is a parameter that is defined globally, but
+ // can be overridden on a subnet level.
"match-client-id": true,
// The following list defines subnets. Each subnet consists of at
"pools": [ { "pool": "192.0.4.1 - 192.0.4.254" } ],
"subnet": "192.0.4.0/24",
- // Sometimes the relay may use an IPv4 address that does not match
- // the subnet. This is discouraged, but there are valid cases when it
- // makes sense. One case is when there is a shared subnet.
+ // Sometimes the relay may use an IPv4 address that does
+ // not match the subnet. This is discouraged, but there are
+ // valid cases when it makes sense. One case is when there
+ // is a shared subnet.
"relay": {
"ip-address": "192.168.1.1"
}
]
},
- // The following configures logging. It assumes that messages with at least
- // informational level (info, warn, error and fatal) should be logged to stdout.
+ // The following configures logging. It assumes that messages with
+ // at least informational level (info, warn, error and fatal) should
+ // be logged to stdout.
"Logging": {
"loggers": [
{
// "connect-timeout": 3
// },
-// 4. CQL (Cassandra) backend. Leases will be stored in Cassandra database. Make
-// sure it is up, running and properly initialized. See kea-admin documentation
-// for details on how to initialize the database. The only strictly required
-// parameters are type, keyspace and contact-points. At least one contact point
-// must be specified, but more than one is required for redundancy. Make sure
-// you specify the contact points without spaces. Kea must be compiled with
-// --with-cql option to use this backend.
+// 4. CQL (Cassandra) backend. Leases will be stored in Cassandra
+// database. Make sure it is up, running and properly initialized. See
+// kea-admin documentation for details on how to initialize the
+// database. The only strictly required parameters are type, keyspace
+// and contact-points. At least one contact point must be specified, but
+// more than one is required for redundancy. Make sure you specify the
+// contact points without spaces. Kea must be compiled with --with-cql
+// option to use this backend.
// "lease-database": {
// "type": "cql",
// "keyspace": "keatest",
]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
"interfaces": [ "ethX" ]
},
-// 4. CQL (Cassandra) backend. Leases will be stored in Cassandra database. Make
-// sure it is up, running and properly initialized. See kea-admin documentation
-// for details on how to initialize the database. The only strictly required
-// parameters are type, keyspace and contact-points. At least one contact point
-// must be specified, but more than one is required for redundancy. Make sure
-// you specify the contact points without spaces. Kea must be compiled with
-// --with-cql option to use this backend.
+// 4. CQL (Cassandra) backend. Leases will be stored in Cassandra
+// database. Make sure it is up, running and properly initialized. See
+// kea-admin documentation for details on how to initialize the
+// database. The only strictly required parameters are type, keyspace
+// and contact-points. At least one contact point must be specified, but
+// more than one is required for redundancy. Make sure you specify the
+// contact points without spaces. Kea must be compiled with --with-cql
+// option to use this backend.
"lease-database": {
"type": "cql",
"keyspace": "keatest",
]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
"lfc-interval": 3600
},
-// The following parameters control processing expired leases. Expired leases
-// will be reclaimed periodically according to the "reclaim-timer-wait-time"
-// parameter. Reclaimed leases will be held in the database for 1800s to
-// facilitate lease affinity. After this period the leases will be removed.
-// The frequency of removal is controlled by the "flush-reclaimed-timer-wait-time"
-// parameter. The lease reclamation routine will process at most 500 leases
-// or will last for at most 100ms, during a single run. If there are still
-// some unreclaimed leases after 10 attempts, a warning message is issued.
+// The following parameters control processing expired leases. Expired
+// leases will be reclaimed periodically according to the
+// "reclaim-timer-wait-time" parameter. Reclaimed leases will be held in
+// the database for 1800s to facilitate lease affinity. After this
+// period the leases will be removed. The frequency of removal is
+// controlled by the "flush-reclaimed-timer-wait-time" parameter. The
+// lease reclamation routine will process at most 500 leases or will
+// last for at most 100ms, during a single run. If there are still some
+// unreclaimed leases after 10 attempts, a warning message is issued.
"expired-leases-processing": {
"reclaim-timer-wait-time": 5,
"hold-reclaimed-time": 1800,
]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
},
// Note the Kea provides some of the options on its own. In
// particular:
- // - IP address lease time (option 51) is governed by valid-lifetime
- // parameter, so you don't need to specify it as option.
+
+ // - IP address lease time (option 51) is governed by
+ // valid-lifetime parameter, so you don't need to specify
+ // it as option.
// - Subnet mask (option 1) is calculated automatically from the
// subnet parameter specified for each "subnet4" entry.
// - renewal-timer (option 58) is calculated from renew-timer
"name": "routers",
"data": "192.0.2.1"
},
- // Typically people prefer to refer to options by their names, so they
- // don't need to remember the code names. However, some people like
- // to use numerical values. For example, option "domain-name" uses
- // option code 15, so you can reference to it either by
+
+ // Typically people prefer to refer to options by their
+ // names, so they don't need to remember the code names.
+ // However, some people like to use numerical values. For
+ // example, option "domain-name" uses option code 15, so you
+ // can reference to it either by
// "name": "domain-name" or "code": 15.
{
"code": 15,
// Domain search is also a popular option. It tells the client to
// attempt to resolve names within those specificed domains. For
// example, name "foo" would be attempted to be resolved as
- // foo.mydomain.example.com and if it fails, then as foo.example.com
+ // foo.mydomain.example.com and if it fails, then as
+ // foo.example.com
+
{
"name": "domain-search",
"data": "mydomain.example.com, example.com"
]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
// "rebind-timer": 2000,
-// Kea supports reservations by several different types of identifiers:
-// hw-address (hardware/MAC address of the client), duid (DUID inserted by the
-// client), client-id (client identifier inserted by the client) and circuit-id
-// (circuit identifier inserted by the relay agent). When told to do so, Kea can
-// check for all of those identifier types, but it takes a costly database lookup
-// to do so. It is therefore useful from a performance perspective to use only
-// the reservation types that are actually used in a given network.
+// Kea supports reservations by several different types of
+// identifiers: hw-address (hardware/MAC address of the client), duid
+// (DUID inserted by the client), client-id (client identifier inserted
+// by the client) and circuit-id (circuit identifier inserted by the
+// relay agent). When told to do so, Kea can check for all of those
+// identifier types, but it takes a costly database lookup to do so. It
+// is therefore useful from a performance perspective to use only the
+// reservation types that are actually used in a given network.
// The example below is not optimal from a performance perspective, but it
// nicely showcases the host reservation capabilities. Please use the minimum
// set of identifier types used in your network.
- "host-reservation-identifiers": [ "circuit-id", "hw-address", "duid", "client-id" ],
+ "host-reservation-identifiers":
+ [ "circuit-id", "hw-address", "duid", "client-id" ],
// Specify connection to the database holding host reservations. The type
// specifies that the MySQL database is used. user and password are the
]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
// "rebind-timer": 2000,
-// Kea supports reservations by several different types of identifiers:
-// hw-address (hardware/MAC address of the client), duid (DUID inserted by the
-// client), client-id (client identifier inserted by the client) and circuit-id
-// (circuit identifier inserted by the relay agent). When told to do so, Kea can
-// check for all of those identifier types, but it takes a costly database lookup
-// to do so. It is therefore useful from a performance perspective to use only
-// the reservation types that are actually used in a given network.
+// Kea supports reservations by several different types of
+// identifiers: hw-address (hardware/MAC address of the client), duid
+// (DUID inserted by the client), client-id (client identifier inserted
+// by the client) and circuit-id (circuit identifier inserted by the
+// relay agent). When told to do so, Kea can check for all of those
+// identifier types, but it takes a costly database lookup to do so. It
+// is therefore useful from a performance perspective to use only the
+// reservation types that are actually used in a given network.
// The example below is not optimal from a performance perspective, but it
// nicely showcases the host reservation capabilities. Please use the minimum
// set of identifier types used in your network.
- "host-reservation-identifiers": [ "circuit-id", "hw-address", "duid", "client-id" ],
+ "host-reservation-identifiers":
+ [ "circuit-id", "hw-address", "duid", "client-id" ],
// Specify connection to the database holding host reservations. The type
// specifies that the PostgreSQL database is used. user and password are the
]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
// "rebind-timer": 2000,
-// Kea supports reservations by several different types of identifiers:
-// hw-address (hardware/MAC address of the client), duid (DUID inserted by the
-// client), client-id (client identifier inserted by the client) and circuit-id
-// (circuit identifier inserted by the relay agent). When told to do so, Kea can
-// check for all of those identifier types, but it takes a costly database lookup
-// to do so. It is therefore useful from a performance perspective to use only
-// the reservation types that are actually used in a given network.
+// Kea supports reservations by several different types of
+// identifiers: hw-address (hardware/MAC address of the client), duid
+// (DUID inserted by the client), client-id (client identifier inserted
+// by the client) and circuit-id (circuit identifier inserted by the
+// relay agent). When told to do so, Kea can check for all of those
+// identifier types, but it takes a costly database lookup to do so. It
+// is therefore useful from a performance perspective to use only the
+// reservation types that are actually used in a given network.
// The example below is not optimal from a performance perspective, but it
// nicely showcases the host reservation capabilities. Please use the minimum
// set of identifier types used in your network.
-"host-reservation-identifiers": [ "circuit-id", "hw-address", "duid", "client-id" ],
+"host-reservation-identifiers":
+ [ "circuit-id", "hw-address", "duid", "client-id" ],
// Define a subnet with four reservations. Some of the reservations belong
// to the dynamic pool. Kea is able to handle this case, but it is not
"boot-file-name": "/dev/null"
},
-// This reservation is using flexible identifier. Instead of relying on specific
-// field, sysadmin can define an expression similar to what is used for client
-// classification, e.g. substring(relay[0].option[17],0,6). Then, based on the
-// value of that expression for incoming packet, the reservation is matched.
+// This reservation is using flexible identifier. Instead of relying
+// on specific field, sysadmin can define an expression similar to what
+// is used for client classification,
+// e.g. substring(relay[0].option[17],0,6). Then, based on the value of
+// that expression for incoming packet, the reservation is matched.
// Expression can be specified either as hex or plain text using single
// quotes.
-// Note: flexible identifier requires flex_id hook library to be loaded to work.
+// Note: flexible identifier requires flex_id hook library to be
+// loaded to work.
{
"flex-id": "s0mEVaLue",
"ip-address": "192.0.2.206"
]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
} ]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
}
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
// "connect-timeout": 3
// },
-// 4. CQL (Cassandra) backend. Leases will be stored in Cassandra database. Make
-// sure it is up, running and properly initialized. See kea-admin documentation
-// for details on how to initialize the database. The only strictly required
-// parameters are type, keyspace and contact-points. At least one contact point
-// must be specified, but more than one is required for redundancy. Make sure
-// you specify the contact points without spaces. Kea must be compiled with
-// --with-cql option to use this backend.
+// 4. CQL (Cassandra) backend. Leases will be stored in Cassandra
+// database. Make sure it is up, running and properly initialized. See
+// kea-admin documentation for details on how to initialize the
+// database. The only strictly required parameters are type, keyspace
+// and contact-points. At least one contact point must be specified, but
+// more than one is required for redundancy. Make sure you specify the
+// contact points without spaces. Kea must be compiled with --with-cql
+// option to use this backend.
// "lease-database": {
// "type": "cql",
// "keyspace": "keatest",
]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
// will be reclaimed periodically according to the "reclaim-timer-wait-time"
// parameter. Reclaimed leases will be held in the database for 1800s to
// facilitate lease affinity. After this period the leases will be removed.
-// The frequency of removal is controlled by the "flush-reclaimed-timer-wait-time"
-// parameter. The lease reclamation routine will process at most 500 leases
-// or will last for at most 100ms, during a single run. If there are still
-// some unreclaimed leases after 10 attempts, a warning message is issued.
+// The frequency of removal is controlled by the
+// "flush-reclaimed-timer-wait-time" parameter. The lease reclamation
+// routine will process at most 500 leases or will last for at most
+// 100ms, during a single run. If there are still some unreclaimed
+// leases after 10 attempts, a warning message is issued.
"expired-leases-processing": {
"reclaim-timer-wait-time": 5,
"hold-reclaimed-time": 1800,
]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
"data": "2001:db8:2::45, 2001:db8:2::100"
},
- // Typically people prefer to refer to options by their names, so they
- // don't need to remember the code names. However, some people like
- // to use numerical values. For example, DHCPv6 can optionally use
- // server unicast communication, if extra option is present. Option
- // "unicast" uses option code 12, so you can reference to it either
- // by "name": "unicast" or "code": 12.
+ // Typically people prefer to refer to options by their
+ // names, so they don't need to remember the code
+ // names. However, some people like to use numerical
+ // values. For example, DHCPv6 can optionally use server
+ // unicast communication, if extra option is present. Option
+ // "unicast" uses option code 12, so you can reference to it
+ // either by "name": "unicast" or "code": 12.
{
"code": 12,
"data": "2001:db8:1:0:ff00::1"
]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
"renew-timer": 1000,
"rebind-timer": 2000,
-// Kea supports two types of identifiers in DHCPv6: hw-address (hardware/MAC address
-// of the client) and duid (DUID inserted by the client). When told to do so, Kea can
-// check for each of these identifier types, but it takes a costly database lookup
-// to do so. It is therefore useful from a performance perspective to use only
-// the reservation types that are actually used in a given network.
+// Kea supports two types of identifiers in DHCPv6: hw-address
+// (hardware/MAC address of the client) and duid (DUID inserted by the
+// client). When told to do so, Kea can check for each of these
+// identifier types, but it takes a costly database lookup to do so. It
+// is therefore useful from a performance perspective to use only the
+// reservation types that are actually used in a given network.
"host-reservation-identifiers": [ "duid", "hw-address" ],
// Specify connection to the database holding host reservations. The type
]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
"renew-timer": 1000,
"rebind-timer": 2000,
-// Kea supports two types of identifiers in DHCPv6: hw-address (hardware/MAC address
-// of the client) and duid (DUID inserted by the client). When told to do so, Kea can
-// check for each of these identifier types, but it takes a costly database lookup
-// to do so. It is therefore useful from a performance perspective to use only
-// the reservation types that are actually used in a given network.
+// Kea supports two types of identifiers in DHCPv6: hw-address
+// (hardware/MAC address of the client) and duid (DUID inserted by the
+// client). When told to do so, Kea can check for each of these
+// identifier types, but it takes a costly database lookup to do so. It
+// is therefore useful from a performance perspective to use only the
+// reservation types that are actually used in a given network.
"host-reservation-identifiers": [ "duid", "hw-address" ],
// Specify connection to the database holding host reservations. The type
]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
"renew-timer": 1000,
"rebind-timer": 2000,
-// Kea supports two types of identifiers in DHCPv6: hw-address (hardware/MAC address
-// of the client) and duid (DUID inserted by the client). When told to do so, Kea can
-// check for each of these identifier types, but it takes a costly database lookup
-// to do so. It is therefore useful from a performance perspective to use only
-// the reservation types that are actually used in a given network.
+// Kea supports two types of identifiers in DHCPv6: hw-address
+// (hardware/MAC address of the client) and duid (DUID inserted by the
+// client). When told to do so, Kea can check for each of these
+// identifier types, but it takes a costly database lookup to do so. It
+// is therefore useful from a performance perspective to use only the
+// reservation types that are actually used in a given network.
"host-reservation-identifiers": [ "duid", "hw-address" ],
// The following list defines subnets. Subnet, pools and interface definitions
"duid": "01:02:03:04:05:0A:0B:0C:0D:0E",
"ip-addresses": [ "2001:db8:1::100" ]
},
-// This is similar to the previous one, but this time the reservation is done
-// based on hardware/MAC address. The server will do its best to extract
-// the hardware/MAC address from received packets (see 'mac-sources' directive
-// for details). This particular reservation also specifies two extra options
-// to be available for this client. If there are options with the same code
-// specified in a global, subnet or class scope, the values defined at host level
-// take precedence.
+// This is similar to the previous one, but this time the reservation
+// is done based on hardware/MAC address. The server will do its best to
+// extract the hardware/MAC address from received packets (see
+// 'mac-sources' directive for details). This particular reservation
+// also specifies two extra options to be available for this client. If
+// there are options with the same code specified in a global, subnet or
+// class scope, the values defined at host level take precedence.
{
"hw-address": "00:01:02:03:04:05",
"ip-addresses": [ "2001:db8:1::101" ],
} ]
},
-// This reservation is using flexible identifier. Instead of relying on specific
-// field, sysadmin can define an expression similar to what is used for client
-// classification, e.g. substring(relay[0].option[17],0,6). Then, based on the
-// value of that expression for incoming packet, the reservation is matched.
+// This reservation is using flexible identifier. Instead of relying
+// on specific field, sysadmin can define an expression similar to what
+// is used for client classification,
+// e.g. substring(relay[0].option[17],0,6). Then, based on the value of
+// that expression for incoming packet, the reservation is matched.
// Expression can be specified either as hex or plain text using single
// quotes.
-// Note: flexible identifier requires flex_id hook library to be loaded to work.
+// Note: flexible identifier requires flex_id hook library to be
+//loaded to work.
{
"flex-id": "'somevalue'",
"ip-addresses": [ "2001:db8:1:cafe::2" ]
]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
"subnet": "2001:db8:4::/64" } ]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
]
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
} ],
// Kea 0.9.1 requires lease-database to be specified, even it is not used.
-// In stateless mode, only options are granted, not addresses or prefixes, so
-// there will be no leases (unless stateless and stateful mode is used together).
+// In stateless mode, only options are granted, not addresses or
+// prefixes, so there will be no leases (unless stateless and stateful
+// mode is used together).
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
"Logging": {
"loggers": [
{
projects / thirdparty / kea.git / commitdiff
