Browse Source

[5212] Comments # converted to //

Tomek Mrugalski 8 years ago
parent
commit
b2ba456fee

+ 68 - 68
doc/examples/kea6/backends.json

@@ -1,92 +1,92 @@
-# This is an example configuration file for the DHCPv6 server in Kea.
-# It is a basic scenario with one IPv6 subnet configured. It demonstrates
-# how to configure Kea to use various backends to store leases:
-# - memfile
-# - MySQL
-# - PostgreSQL
-# - CQL (Cassandra) backend
+// This is an example configuration file for the DHCPv6 server in Kea.
+// It is a basic scenario with one IPv6 subnet configured. It demonstrates
+// how to configure Kea to use various backends to store leases:
+// - memfile
+// - MySQL
+// - PostgreSQL
+// - CQL (Cassandra) backend
 
 
 { "Dhcp6":
 { "Dhcp6":
 
 
 {
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
   "interfaces-config": {
     "interfaces": [ "ethX" ]
     "interfaces": [ "ethX" ]
   },
   },
 
 
-# We need to specify lease type. Exactly one lease-database section
-# should be present. Make sure you uncomment only one.
+// We need to specify lease type. Exactly one lease-database section
+// should be present. Make sure you uncomment only one.
 
 
-# 1. memfile backend. Leases information will be stored in flat CSV file.
-# This is the easiest backend to use as it does not require any extra
-# dependencies or services running.
+// 1. memfile backend. Leases information will be stored in flat CSV file.
+// This is the easiest backend to use as it does not require any extra
+// dependencies or services running.
   "lease-database": {
   "lease-database": {
       "type": "memfile",
       "type": "memfile",
       "persist": true,
       "persist": true,
       "lfc-interval": 3600
       "lfc-interval": 3600
   },
   },
 
 
-# 2. MySQL backend. Leases will be stored in MySQL 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 and name. If other parameters are not specified,
-# Kea will assume the database is available on localhost, that user and
-# password is not necessary to connect and that timeout is 5 seconds.
-# Kea must be compiled with --with-dhcp-mysql option to use this backend.
-#  "lease-database": {
-#      "type": "mysql",
-#      "name": "keatest",
-#      "host": "localhost",
-#      "port": 3306,
-#      "user": "keatest",
-#      "password": "secret1",
-#      "connect-timeout": 3
-#  },
+// 2. MySQL backend. Leases will be stored in MySQL 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 and name. If other parameters are not specified,
+// Kea will assume the database is available on localhost, that user and
+// password is not necessary to connect and that timeout is 5 seconds.
+// Kea must be compiled with --with-dhcp-mysql option to use this backend.
+//  "lease-database": {
+//      "type": "mysql",
+//      "name": "keatest",
+//      "host": "localhost",
+//      "port": 3306,
+//      "user": "keatest",
+//      "password": "secret1",
+//      "connect-timeout": 3
+//  },
 
 
-# 3. PostgreSQL backend. Leases will be stored in PostgreSQL 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 and name. If other parameters are not specified,
-# Kea will assume the database is available on localhost, that user and
-# password is not necessary to connect and that timeout is 5 seconds.
-# Kea must be compiled with --with-dhcp-pgsql option to use this backend.
-#  "lease-database": {
-#      "type": "pgsql",
-#      "name": "keatest",
-#      "host": "localhost",
-#      "port": 5432,
-#      "user": "keatest",
-#      "password": "secret1",
-#      "connect-timeout": 3
-#  },
+// 3. PostgreSQL backend. Leases will be stored in PostgreSQL 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 and name. If other parameters are not specified,
+// Kea will assume the database is available on localhost, that user and
+// password is not necessary to connect and that timeout is 5 seconds.
+// Kea must be compiled with --with-dhcp-pgsql option to use this backend.
+//  "lease-database": {
+//      "type": "pgsql",
+//      "name": "keatest",
+//      "host": "localhost",
+//      "port": 5432,
+//      "user": "keatest",
+//      "password": "secret1",
+//      "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.
-#  "lease-database": {
-#      "type": "cql",
-#      "keyspace": "keatest",
-#      "contact-points": "192.0.2.1,192.0.2.2,192.0.2.3",
-#      "port": 9042
-#  },
+// 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",
+//      "contact-points": "192.0.2.1,192.0.2.2,192.0.2.3",
+//      "port": 9042
+//  },
 
 
-# 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).
+// 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,
   "preferred-lifetime": 3000,
   "valid-lifetime": 4000,
   "valid-lifetime": 4000,
   "renew-timer": 1000,
   "renew-timer": 1000,
   "rebind-timer": 2000,
   "rebind-timer": 2000,
 
 
-# The following list defines subnets. Each subnet consists of at
-# least subnet and pool entries.
+// The following list defines subnets. Each subnet consists of at
+// least subnet and pool entries.
   "subnet6": [
   "subnet6": [
     {
     {
       "pools": [ { "pool": "2001:db8:1::/80" } ],
       "pools": [ { "pool": "2001:db8:1::/80" } ],
@@ -96,8 +96,8 @@
   ]
   ]
 },
 },
 
 
-# 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": {
 "Logging": {
     "loggers": [
     "loggers": [
         {
         {

+ 20 - 20
doc/examples/kea6/classify.json

@@ -1,16 +1,16 @@
-# This is an example configuration file for the DHCPv4 server in Kea.
-# The purpose of this example is to showcase how clients can be classified.
+// This is an example configuration file for the DHCPv4 server in Kea.
+// The purpose of this example is to showcase how clients can be classified.
 
 
 { "Dhcp6":
 { "Dhcp6":
 
 
 {
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
   "interfaces-config": {
     "interfaces": [ "ethX" ]
     "interfaces": [ "ethX" ]
   },
   },
 
 
-# Let's use the simplest backend: memfile and use some reasonable values
-# for timers. They are of no concern for the classification demonstration.
+// Let's use the simplest backend: memfile and use some reasonable values
+// for timers. They are of no concern for the classification demonstration.
   "lease-database": {
   "lease-database": {
       "type": "memfile",
       "type": "memfile",
       "lfc-interval": 3600
       "lfc-interval": 3600
@@ -20,11 +20,11 @@
   "preferred-lifetime": 3000,
   "preferred-lifetime": 3000,
   "valid-lifetime": 4000,
   "valid-lifetime": 4000,
 
 
-# This list defines several classes that incoming packets can be assigned to.
-# One packet can belong to zero or more classes.
+// This list defines several classes that incoming packets can be assigned to.
+// One packet can belong to zero or more classes.
   "client-classes": [
   "client-classes": [
 
 
-# The first class attempts to match all packets coming in on ethX interface.
+// The first class attempts to match all packets coming in on ethX interface.
   {
   {
       "name": "lab",
       "name": "lab",
       "test": "pkt.iface == 'ethX'",
       "test": "pkt.iface == 'ethX'",
@@ -34,16 +34,16 @@
       }]
       }]
   },
   },
 
 
-# Let's classify all incoming RENEW (message type 5) to a separate
-# class.
+// Let's classify all incoming RENEW (message type 5) to a separate
+// class.
   {
   {
       "name": "renews",
       "name": "renews",
       "test": "pkt6.msgtype == 5"
       "test": "pkt6.msgtype == 5"
   },
   },
 
 
-# Let's pick cable modems. In this simple example we'll assume the device
-# is a cable modem if it sends a vendor option with enterprise-id equal
-# to 4491.
+// Let's pick cable modems. In this simple example we'll assume the device
+// is a cable modem if it sends a vendor option with enterprise-id equal
+// to 4491.
   {
   {
       "name": "cable-modems",
       "name": "cable-modems",
       "test": "vendor.enterprise == 4491"
       "test": "vendor.enterprise == 4491"
@@ -52,8 +52,8 @@
   ],
   ],
 
 
 
 
-# The following list defines subnets. Each subnet consists of at
-# least subnet and pool entries.
+// The following list defines subnets. Each subnet consists of at
+// least subnet and pool entries.
   "subnet6": [
   "subnet6": [
     {
     {
         "pools": [ { "pool": "2001:db8:1::/80" } ],
         "pools": [ { "pool": "2001:db8:1::/80" } ],
@@ -61,9 +61,9 @@
         "client-class": "cable-modems",
         "client-class": "cable-modems",
         "interface": "ethX"
         "interface": "ethX"
     },
     },
-# The following subnet contains a class reservation for a client using
-# DUID 01:02:03:04:05:0A:0B:0C:0D:0E. This client will always be assigned
-# to this class.
+// The following subnet contains a class reservation for a client using
+// DUID 01:02:03:04:05:0A:0B:0C:0D:0E. This client will always be assigned
+// to this class.
     {
     {
         "pools": [ { "pool": "2001:db8:2::/80" } ],
         "pools": [ { "pool": "2001:db8:2::/80" } ],
         "subnet": "2001:db8:2::/64",
         "subnet": "2001:db8:2::/64",
@@ -77,8 +77,8 @@
   ]
   ]
 },
 },
 
 
-# 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": {
 "Logging": {
     "loggers": [
     "loggers": [
         {
         {

+ 30 - 30
doc/examples/kea6/duid.json

@@ -1,23 +1,23 @@
-# This is an example configuration file for DHCPv6 server in Kea.
-# It demonstrates how to configure Kea to use DUID-LLT with some
-# values specified explicitly.
+// This is an example configuration file for DHCPv6 server in Kea.
+// It demonstrates how to configure Kea to use DUID-LLT with some
+// values specified explicitly.
 
 
 { "Dhcp6":
 { "Dhcp6":
 
 
 {
 {
 
 
-# Configure server identifier (DUID-LLT). The hexadecimal value of the
-# identifier will be used as link layer address component of the DUID.
-# The link layer type will be ethernet. The value of time is set to 0
-# which indicates that the server must generate this value, i.e. use
-# current time. Note that it is easy to move from this configuration
-# to DUID-EN or DUID-LL. It would require changing the "type" value
-# to "EN" or "LL" respectively. The "identifier" would hold a
-# DUID-EN variable length identifier or DUID-LL link layer address.
-# The values of "time" and "htype" would be ignored for DUID-EN.
-# If one wanted to use a non-default enterprise-id for DUID-EN, the
-# "enterprise-id" parameter would need to be added. Note that only
-# a "type" parameter is mandatory while specifying "server-id" map.
+// Configure server identifier (DUID-LLT). The hexadecimal value of the
+// identifier will be used as link layer address component of the DUID.
+// The link layer type will be ethernet. The value of time is set to 0
+// which indicates that the server must generate this value, i.e. use
+// current time. Note that it is easy to move from this configuration
+// to DUID-EN or DUID-LL. It would require changing the "type" value
+// to "EN" or "LL" respectively. The "identifier" would hold a
+// DUID-EN variable length identifier or DUID-LL link layer address.
+// The values of "time" and "htype" would be ignored for DUID-EN.
+// If one wanted to use a non-default enterprise-id for DUID-EN, the
+// "enterprise-id" parameter would need to be added. Note that only
+// a "type" parameter is mandatory while specifying "server-id" map.
   "server-id": {
   "server-id": {
     "type": "LLT",
     "type": "LLT",
     "identifier": "12C4D5AF870C",
     "identifier": "12C4D5AF870C",
@@ -25,33 +25,33 @@
     "htype": 1
     "htype": 1
   },
   },
 
 
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
   "interfaces-config": {
     "interfaces": [ "ethX" ]
     "interfaces": [ "ethX" ]
   },
   },
 
 
-# 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'll use memfile  because it doesn't require any prior set up.
+// 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'll use memfile  because it doesn't require any prior set up.
   "lease-database": {
   "lease-database": {
       "type": "memfile",
       "type": "memfile",
       "lfc-interval": 3600
       "lfc-interval": 3600
   },
   },
 
 
-# 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).
+// 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,
   "preferred-lifetime": 3000,
   "valid-lifetime": 4000,
   "valid-lifetime": 4000,
   "renew-timer": 1000,
   "renew-timer": 1000,
   "rebind-timer": 2000,
   "rebind-timer": 2000,
 
 
-# The following list defines subnets. Each subnet consists of at
-# least subnet and pool entries.
+// The following list defines subnets. Each subnet consists of at
+// least subnet and pool entries.
   "subnet6": [
   "subnet6": [
     {
     {
       "pools": [ { "pool": "2001:db8:1::/80" } ],
       "pools": [ { "pool": "2001:db8:1::/80" } ],
@@ -61,8 +61,8 @@
   ]
   ]
 },
 },
 
 
-# The following configures logging. It assumes that messages with at least
-# informational level (info, warn, error) will will be logged to stdout.
+// The following configures logging. It assumes that messages with at least
+// informational level (info, warn, error) will will be logged to stdout.
 "Logging": {
 "Logging": {
     "loggers": [
     "loggers": [
         {
         {

+ 26 - 26
doc/examples/kea6/leases-expiration.json

@@ -1,32 +1,32 @@
-# This is an example configuration file for DHCPv6 server in Kea.
-# It provides parameters controlling processing of expired leases,
-# a.k.a. leases reclamation.
+// This is an example configuration file for DHCPv6 server in Kea.
+// It provides parameters controlling processing of expired leases,
+// a.k.a. leases reclamation.
 
 
 { "Dhcp6":
 { "Dhcp6":
 
 
 {
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
   "interfaces-config": {
     "interfaces": [ "ethX" ]
     "interfaces": [ "ethX" ]
   },
   },
 
 
-# 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'll use memfile  because it doesn't require any prior set up.
+// 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'll use memfile  because it doesn't require any prior set up.
   "lease-database": {
   "lease-database": {
       "type": "memfile",
       "type": "memfile",
       "lfc-interval": 3600
       "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": {
   "expired-leases-processing": {
     "reclaim-timer-wait-time": 5,
     "reclaim-timer-wait-time": 5,
     "hold-reclaimed-time": 1800,
     "hold-reclaimed-time": 1800,
@@ -36,19 +36,19 @@
     "unwarned-reclaim-cycles": 10
     "unwarned-reclaim-cycles": 10
   },
   },
 
 
-# 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).
+// 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,
   "preferred-lifetime": 3000,
   "valid-lifetime": 4000,
   "valid-lifetime": 4000,
   "renew-timer": 1000,
   "renew-timer": 1000,
   "rebind-timer": 2000,
   "rebind-timer": 2000,
 
 
-# The following list defines subnets. Each subnet consists of at
-# least subnet and pool entries.
+// The following list defines subnets. Each subnet consists of at
+// least subnet and pool entries.
   "subnet6": [
   "subnet6": [
     {
     {
       "pools": [ { "pool": "2001:db8:1::/80" } ],
       "pools": [ { "pool": "2001:db8:1::/80" } ],
@@ -58,8 +58,8 @@
   ]
   ]
 },
 },
 
 
-# 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": {
 "Logging": {
     "loggers": [
     "loggers": [
         {
         {

+ 31 - 31
doc/examples/kea6/mysql-reservations.json

@@ -1,46 +1,46 @@
-# This is an example configuration file for the DHCPv6 server in Kea.
-# It contains configuration of the MySQL host database backend, used
-# to retrieve reserved addresses, host names, DHCPv4 message fields
-# and DHCP options from MySQL database.
+// This is an example configuration file for the DHCPv6 server in Kea.
+// It contains configuration of the MySQL host database backend, used
+// to retrieve reserved addresses, host names, DHCPv4 message fields
+// and DHCP options from MySQL database.
 { "Dhcp6":
 { "Dhcp6":
 
 
 {
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
   "interfaces-config": {
     "interfaces": [ "ethX" ]
     "interfaces": [ "ethX" ]
   },
   },
 
 
-# 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'll use memfile  because it doesn't require any prior set up.
+// 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'll use memfile  because it doesn't require any prior set up.
   "lease-database": {
   "lease-database": {
       "type": "memfile",
       "type": "memfile",
       "lfc-interval": 3600
       "lfc-interval": 3600
   },
   },
 
 
-# This is pretty basic stuff, it has nothing to do with reservations.
+// This is pretty basic stuff, it has nothing to do with reservations.
   "preferred-lifetime": 3000,
   "preferred-lifetime": 3000,
   "valid-lifetime": 4000,
   "valid-lifetime": 4000,
   "renew-timer": 1000,
   "renew-timer": 1000,
   "rebind-timer": 2000,
   "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" ],
     "host-reservation-identifiers": [ "duid", "hw-address" ],
 
 
-# Specify connection to the database holding host reservations. The type
-# specifies that the MySQL database is used. user and password are the
-# credentials used to connect to the database. host and name specify
-# location of the host where the database instance is running, and the
-# name of the database to use. The server processing a packet will first
-# check if there are any reservations specified for this client in the
-# reservations list, within the subnet (configuration file). If there are
-# no reservations there, the server will try to retrieve reservations
-# from this database.
+// Specify connection to the database holding host reservations. The type
+// specifies that the MySQL database is used. user and password are the
+// credentials used to connect to the database. host and name specify
+// location of the host where the database instance is running, and the
+// name of the database to use. The server processing a packet will first
+// check if there are any reservations specified for this client in the
+// reservations list, within the subnet (configuration file). If there are
+// no reservations there, the server will try to retrieve reservations
+// from this database.
   "hosts-database": {
   "hosts-database": {
     "type": "mysql",
     "type": "mysql",
     "name": "kea",
     "name": "kea",
@@ -51,11 +51,11 @@
     "readonly": true
     "readonly": true
   },
   },
 
 
-# Define a subnet with a pool of dynamic addresses and a pool of dynamic
-# prefixes. Addresses and prefixes from those pools will be assigned to
-# clients which don't have reservations in the database. Subnet identifier
-# is equal to 1. If this subnet is selected for the client, this subnet
-# id will be used to search for the reservations within the database.
+// Define a subnet with a pool of dynamic addresses and a pool of dynamic
+// prefixes. Addresses and prefixes from those pools will be assigned to
+// clients which don't have reservations in the database. Subnet identifier
+// is equal to 1. If this subnet is selected for the client, this subnet
+// id will be used to search for the reservations within the database.
   "subnet6": [
   "subnet6": [
     {
     {
       "subnet": "2001:db8:1::/48",
       "subnet": "2001:db8:1::/48",
@@ -75,8 +75,8 @@
   ]
   ]
 },
 },
 
 
-# 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": {
 "Logging": {
     "loggers": [
     "loggers": [
         {
         {

+ 19 - 19
doc/examples/kea6/simple.json

@@ -1,38 +1,38 @@
-# This is an example configuration file for DHCPv6 server in Kea.
-# It's a basic scenario with one IPv6 subnet configured. It is
-# assumed that one subnet (2001:db8:1::/64 is available directly
-# over ethX interface.
+// This is an example configuration file for DHCPv6 server in Kea.
+// It's a basic scenario with one IPv6 subnet configured. It is
+// assumed that one subnet (2001:db8:1::/64 is available directly
+// over ethX interface.
 
 
 { "Dhcp6":
 { "Dhcp6":
 
 
 {
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
   "interfaces-config": {
     "interfaces": [ "ethX" ]
     "interfaces": [ "ethX" ]
   },
   },
 
 
-# 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'll use memfile  because it doesn't require any prior set up.
+// 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'll use memfile  because it doesn't require any prior set up.
   "lease-database": {
   "lease-database": {
       "type": "memfile",
       "type": "memfile",
       "lfc-interval": 3600
       "lfc-interval": 3600
   },
   },
 
 
-# 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).
+// 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,
   "preferred-lifetime": 3000,
   "valid-lifetime": 4000,
   "valid-lifetime": 4000,
   "renew-timer": 1000,
   "renew-timer": 1000,
   "rebind-timer": 2000,
   "rebind-timer": 2000,
 
 
-# The following list defines subnets. Each subnet consists of at
-# least subnet and pool entries.
+// The following list defines subnets. Each subnet consists of at
+// least subnet and pool entries.
   "subnet6": [
   "subnet6": [
     {
     {
       "pools": [ { "pool": "2001:db8:1::/80" } ],
       "pools": [ { "pool": "2001:db8:1::/80" } ],
@@ -42,8 +42,8 @@
   ]
   ]
 },
 },
 
 
-# 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": {
 "Logging": {
     "loggers": [
     "loggers": [
         {
         {

+ 10 - 10
doc/examples/kea6/stateless.json

@@ -1,9 +1,9 @@
-# A very simply stateless configuration that provides information about DNS
-# servers to all clients, regardless of their point of attachment.
-#
-# It is also possible to specify options on a per subnet basis
-# in the same way as in stateful mode.
-#
+// A very simply stateless configuration that provides information about DNS
+// servers to all clients, regardless of their point of attachment.
+//
+// It is also possible to specify options on a per subnet basis
+// in the same way as in stateful mode.
+//
 
 
 {
 {
 "Dhcp6": {
 "Dhcp6": {
@@ -11,15 +11,15 @@
         "interfaces": [ "ethX" ]
         "interfaces": [ "ethX" ]
     },
     },
 
 
-# This is the list of options that will be granted to all clients that ask.
+// This is the list of options that will be granted to all clients that ask.
     "option-data": [ {
     "option-data": [ {
         "name": "dns-servers",
         "name": "dns-servers",
         "data": "2001:db8::1, 2001:db8::2"
         "data": "2001:db8::1, 2001:db8::2"
     } ],
     } ],
 
 
-# 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).
+// 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).
     "lease-database": {
     "lease-database": {
         "type": "memfile",
         "type": "memfile",
         "lfc-interval": 3600
         "lfc-interval": 3600