[5198] # comments converted to //

doc/examples/ddns/sample1.json

@@ -1,40 +1,40 @@
-# This is an example configuration file for D2, Kea's DHCP-DDNS processor.
-# It supports updating two Forward DNS zones "four.example.com" and
-# "six.example.com"; and one Reverse DNS zone, "2.0.192.in-addr.arpa."
+// This is an example configuration file for D2, Kea's DHCP-DDNS processor.
+// It supports updating two Forward DNS zones "four.example.com" and
+// "six.example.com"; and one Reverse DNS zone, "2.0.192.in-addr.arpa."
 
 {
-# ------------------ DHCP-DDNS ---------------------
-#
+// ------------------ DHCP-DDNS ---------------------
+//
 "DhcpDdns":
 {
 
-# --------------  Global Parameters ----------------
-#
-#   D2 will listen for update requests for Kea DHCP servers at 172.16.1.10
-#   on port 53001.  Maximum time to we will  wait for a DNS server to
-#   respond to us is 1000 ms.
+// --------------  Global Parameters ----------------
+//
+//   D2 will listen for update requests for Kea DHCP servers at 172.16.1.10
+//   on port 53001.  Maximum time to we will  wait for a DNS server to
+//   respond to us is 1000 ms.
 
     "ip-address": "172.16.1.10",
     "port": 53001,
     "dns-server-timeout" : 1000,
 
-#
-# ----------------- Forward DDNS  ------------------
-#
-#   1. Zone - "four.example.com.
-#      It uses TSIG, key name is "d2.md5.key"
-#      It is served by one DNS server which listens for DDNS requests at
-#      172.16.1.1 on the default port 53 (standard  DNS port)
-#
-#   2. Zone - "six.example.com."
-#      It does not use TSIG.
-#      It is server by one DNS server at "2001:db8:1::10" on port 7802
+//
+// ----------------- Forward DDNS  ------------------
+//
+//   1. Zone - "four.example.com.
+//      It uses TSIG, key name is "d2.md5.key"
+//      It is served by one DNS server which listens for DDNS requests at
+//      172.16.1.1 on the default port 53 (standard  DNS port)
+//
+//   2. Zone - "six.example.com."
+//      It does not use TSIG.
+//      It is server by one DNS server at "2001:db8:1::10" on port 7802
 
     "forward-ddns":
     {
         "ddns-domains":
         [
-#           DdnsDomain for zone "four.example.com."
+//           DdnsDomain for zone "four.example.com."
             {
                 "name": "four.example.com.",
                 "key-name": "d2.md5.key",
@@ -46,7 +46,7 @@
                 ]
             },
 
-#           DdnsDomain for zone "six.example.com."
+//           DdnsDomain for zone "six.example.com."
             {
                 "name": "six.example.com.",
                 "dns-servers":
@@ -60,13 +60,13 @@
         ]
     },
 
-#
-# ----------------- Reverse DDNS  ------------------
-#
-# We will update Reverse DNS for one zone "2.0.192.in-addr-arpa". It
-# uses TSIG with key "d2.sha1.key" and is served by two DNS servers:
-# one listening at "172.16.1.1" on 53001 and the other at "192.168.2.10".
-#
+//
+// ----------------- Reverse DDNS  ------------------
+//
+// We will update Reverse DNS for one zone "2.0.192.in-addr-arpa". It
+// uses TSIG with key "d2.sha1.key" and is served by two DNS servers:
+// one listening at "172.16.1.1" on 53001 and the other at "192.168.2.10".
+//
     "reverse-ddns":
     {
         "ddns-domains":
@@ -88,12 +88,12 @@
         ]
     },
 
-#
-# ------------------ TSIG keys ---------------------
-#
-#   Each key has a name, an algorithm (HMAC-MD5, HMAC-SHA1, HMAC-SHA224...)
-#   and a base-64 encoded shared secret.
-#
+//
+// ------------------ TSIG keys ---------------------
+//
+//   Each key has a name, an algorithm (HMAC-MD5, HMAC-SHA1, HMAC-SHA224...)
+//   and a base-64 encoded shared secret.
+//
     "tsig-keys":
     [
         {

doc/examples/ddns/template.json

@@ -1,108 +1,108 @@
-# This file may be used a template for constructing DHCP-DDNS JSON
-# configuration.
-#
-# Default values that may be omitted are '#' commented out.
+// This file may be used a template for constructing DHCP-DDNS JSON
+// configuration.
+//
+// Default values that may be omitted are '//' commented out.
 
-# If in a file by itself, it must start with a left-curly-bracket.
+// If in a file by itself, it must start with a left-curly-bracket.
 {
 
 "DhcpDdns" :
 {
-#
-# --------------  Global Parameters ----------------
-#
-#    All of the global parameters have default values as shown.  If these
-#    are satisfactory you may omit them.
-#
-#    "ip-address" : "127.0.0.1",
-#    "port" : 53001,
-#    "dns-server-timeout" : 100,
-#    "ncr-protocol" : "UDP"
-#    "ncr-format" : "JSON"
+//
+// --------------  Global Parameters ----------------
+//
+//    All of the global parameters have default values as shown.  If these
+//    are satisfactory you may omit them.
+//
+//    "ip-address" : "127.0.0.1",
+//    "port" : 53001,
+//    "dns-server-timeout" : 100,
+//    "ncr-protocol" : "UDP"
+//    "ncr-format" : "JSON"
 
-#
-# ----------------- Forward DDNS  ------------------
-#
+//
+// ----------------- Forward DDNS  ------------------
+//
     "forward-ddns" :
     {
         "ddns-domains" :
         [
             {
                 "name" : "<zone name 1>",
-#                "key-name" : "<key name>",
+//                "key-name" : "<key name>",
                 "dns-servers" :
                 [
                     {
                         "ip-address" : "<ip address>"
-#                       ,"port" : 53
+//                       ,"port" : 53
                     }
-#                   ,
-#                   {
-#                       next DNS server for this DdnsDomain
-#                   }
-#                   :
+//                   ,
+//                   {
+//                       next DNS server for this DdnsDomain
+//                   }
+//                   :
                 ]
             }
-#           ,
-#           {
-#                next Forward DdnsDomain
-#           }
-#           :
+//           ,
+//           {
+//                next Forward DdnsDomain
+//           }
+//           :
         ]
     },
 
-#
-# ----------------- Reverse DDNS  ------------------
-#
+//
+// ----------------- Reverse DDNS  ------------------
+//
     "reverse-ddns" :
     {
         "ddns-domains" :
         [
             {
                 "name" : "<reverse zone name 1>",
-#                "key-name" : "<key name>",
+//                "key-name" : "<key name>",
                 "dns-servers" :
                 [
                     {
                         "ip-address" : "<ip address>"
-#                        ,"port" : 53
+//                        ,"port" : 53
                     }
-#                   ,
-#                   {
-#                       next DNS server for this DdnsDomain
-#                   }
-#                   :
+//                   ,
+//                   {
+//                       next DNS server for this DdnsDomain
+//                   }
+//                   :
                 ]
             }
-#           ,
-#           {
-#                next Reverse DdnsDomain
-#           }
-#           :
+//           ,
+//           {
+//                next Reverse DdnsDomain
+//           }
+//           :
         ]
     },
-#
-# ------------------ TSIG keys ---------------------
-#
+//
+// ------------------ TSIG keys ---------------------
+//
     "tsig-keys" :
     [
         {
             "name" : "<key name>",
             "algorithm" : "<algorithm name>",
-#            Valid values for algorithm are:    HMAC-MD5, HMAC-SHA1,
-#                                               HMAC-SHA224, HMAC-SHA256,
-#                                               HMAC-SHA384, HMAC-SHA512
-#           "digest-bits" : 256,
-#           Minimum truncated length in bits.
-#           Default 0 (means truncation is forbidden).
+//            Valid values for algorithm are:    HMAC-MD5, HMAC-SHA1,
+//                                               HMAC-SHA224, HMAC-SHA256,
+//                                               HMAC-SHA384, HMAC-SHA512
+//           "digest-bits" : 256,
+//           Minimum truncated length in bits.
+//           Default 0 (means truncation is forbidden).
             "secret" : "<shared secret value>"
         }
-#       ,
-#        {
-#                next TSIG Key
-#        }
+//       ,
+//        {
+//                next TSIG Key
+//        }
     ]
 }
 
-# If in a file by itself, it must end with an right-curly-bracket.
+// If in a file by itself, it must end with an right-curly-bracket.
 }

doc/examples/kea4/backends.json

@@ -1,91 +1,91 @@
-# This is an example configuration file for the DHCPv4 server in Kea.
-# It is a basic scenario with one IPv4 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 DHCPv4 server in Kea.
+// It is a basic scenario with one IPv4 subnet configured. It demonstrates
+// how to configure Kea to use various backends to store leases:
+// - memfile
+// - MySQL
+// - PostgreSQL
+// - CQL (Cassandra) backend
 
 { "Dhcp4":
 
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
     "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.
-#  "lease-database": {
-#      "type": "memfile",
-#      "persist": true,
-#      "lfc-interval": 3600
-#  },
+// 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": {
+//      "type": "memfile",
+//      "persist": true,
+//      "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 a lifetime of 4000 seconds.
+// Addresses will be assigned with a lifetime of 4000 seconds.
   "valid-lifetime": 4000,
 
-# Renew and rebind timers are commented out. This implies that options
-# 58 and 59 will not be sent to the client. In this case it is up to
-# the client to pick the timer values according to RFC2131. Uncomment the
-# timers to send these options to the client.
-#  "renew-timer": 1000,
-#  "rebind-timer": 2000,
+// Renew and rebind timers are commented out. This implies that options
+// 58 and 59 will not be sent to the client. In this case it is up to
+// the client to pick the timer values according to RFC2131. Uncomment the
+// timers to send these options to the client.
+//  "renew-timer": 1000,
+//  "rebind-timer": 2000,
 
-# The following list defines subnets. We have only one subnet
-# here. We tell Kea that it is directly available over local interface.
+// The following list defines subnets. We have only one subnet
+// here. We tell Kea that it is directly available over local interface.
   "subnet4": [
     {
        "pools": [ { "pool":  "192.0.2.1 - 192.0.2.200" } ],
@@ -95,8 +95,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": {
     "loggers": [
         {

doc/examples/kea4/classify.json

@@ -1,30 +1,30 @@
-# 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.
 
 { "Dhcp4": {
 
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
       "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": { "type": "memfile" },
   "renew-timer": 1000,
   "rebind-timer": 2000,
   "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": [
 
-# The first class attempts to match the whole hardware address to a specific
-# value. All incoming packets with that MAC address will get a special
-# value of the option. If there are many hosts that require special
-# treatment, it is much better to use host reservations. However, doing
-# tricks with MAC addresses may prove useful in some cases, e.g.
-# by matching OUI to known values we can detect certain vendors.
+// The first class attempts to match the whole hardware address to a specific
+// value. All incoming packets with that MAC address will get a special
+// value of the option. If there are many hosts that require special
+// treatment, it is much better to use host reservations. However, doing
+// tricks with MAC addresses may prove useful in some cases, e.g.
+// by matching OUI to known values we can detect certain vendors.
   {
       "name": "special_snowflake",
       "test": "pkt4.mac == 0x010203040506",
@@ -34,27 +34,27 @@
       }]
   },
 
-# Let's classify all incoming DISCOVER (message type 1) to a separate
-# class.
+// Let's classify all incoming DISCOVER (message type 1) to a separate
+// class.
   {
       "name": "discovers",
       "test": "pkt4.msgtype == 1"
   },
 
-# Clients are supposed to set the transaction-id field to a random value.
-# Clients that send it with 0 are most likely broken. Let's mark them
-# as such.
+// Clients are supposed to set the transaction-id field to a random value.
+// Clients that send it with 0 are most likely broken. Let's mark them
+// as such.
   {
       "name": "broken",
       "test": "pkt4.transid == 0"
   },
 
-# Let's pick VoIP phones. Those that send their class identifiers
-# as Aastra, should belong to VoIP class. For a list of all options,
-# see www.iana.org/assignments/bootp-dhcp-parameters/.
-# In this particular class, we want to set specific values
-# of certain DHCPv4 fields. If the incoming packet matches the
-# test, those fields will be set in outgoing responses.
+// Let's pick VoIP phones. Those that send their class identifiers
+// as Aastra, should belong to VoIP class. For a list of all options,
+// see www.iana.org/assignments/bootp-dhcp-parameters/.
+// In this particular class, we want to set specific values
+// of certain DHCPv4 fields. If the incoming packet matches the
+// test, those fields will be set in outgoing responses.
   {
       "name": "VoIP",
       "test": "substring(option[60].hex,0,6) == 'Aastra'",
@@ -65,23 +65,23 @@
 
   ],
 
-# The following list defines subnets. For some subnets we defined
-# a class that is allowed in that subnet. If not specified,
-# everyone is allowed. When a class is specified, only packets belonging
-# to that class are allowed for that subnet.
+// The following list defines subnets. For some subnets we defined
+// a class that is allowed in that subnet. If not specified,
+// everyone is allowed. When a class is specified, only packets belonging
+// to that class are allowed for that subnet.
   "subnet4": [
     {
-# This one is for VoIP devices only.
+// This one is for VoIP devices only.
         "pools": [ { "pool":  "192.0.2.1 - 192.0.2.200" } ],
         "subnet": "192.0.2.0/24",
         "client-class": "VoIP",
         "interface": "ethX"
     },
-# This one doesn't have any client-class specified, so everyone
-# is allowed in. The normal subnet selection rules still apply,
-# though. There is also a static class reservation for a client
-# using MAC address 1a:1b:1c:1d:1e:1f. This client will always
-# be assigned to this class.
+// This one doesn't have any client-class specified, so everyone
+// is allowed in. The normal subnet selection rules still apply,
+// though. There is also a static class reservation for a client
+// using MAC address 1a:1b:1c:1d:1e:1f. This client will always
+// be assigned to this class.
     {
         "pools": [ { "pool":  "192.0.3.1 - 192.0.3.200" } ],
         "subnet": "192.0.3.0/24",
@@ -95,8 +95,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": {
     "loggers": [
         {

doc/examples/kea4/dhcpv4-over-dhcpv6.json

@@ -1,9 +1,9 @@
-# This is an example configuration file for the DHCPv4 server of
-# DHCPv4-over-DHCPv6 tests in Kea.
+// This is an example configuration file for the DHCPv4 server of
+// DHCPv4-over-DHCPv6 tests in Kea.
 
 {
 
-# DHCPv4 conf
+// DHCPv4 conf
 "Dhcp4":
 {
   "interfaces-config": {
@@ -20,13 +20,13 @@
 
   "subnet4": [
    {    "subnet": "10.10.10.0/24",
-# Don't forget the "4o6-" before "interface" here!
+// Don't forget the "4o6-" before "interface" here!
         "4o6-interface": "eno33554984",
         "4o6-subnet": "2001:db8:1:1::/64",
         "pools": [ { "pool": "10.10.10.100 - 10.10.10.199" } ] }
   ],
 
-# This enables DHCPv4-over-DHCPv6 support
+// This enables DHCPv4-over-DHCPv6 support
   "dhcp4o6-port": 6767
 
 },

doc/examples/kea4/hooks.json

@@ -1,23 +1,23 @@
-# This is an example configuration file for the DHCPv4 server in Kea
-# illustrating the configuration of hooks libraries.  It uses a basic scenario
-# of one IPv4 subnet configured with the default values for all parameters.
+// This is an example configuration file for the DHCPv4 server in Kea
+// illustrating the configuration of hooks libraries.  It uses a basic scenario
+// of one IPv4 subnet configured with the default values for all parameters.
 
 {"Dhcp4":
 
 {
-# Kea is told to listen on the ethX interface only.
+// Kea is told to listen on the ethX interface only.
   "interfaces-config": {
     "interfaces": [ "ethX" ]
   },
 
-# Set up the storage for leases.
+// Set up the storage for leases.
   "lease-database": {
     "type": "memfile"
   },
 
   "valid-lifetime": 1800,
 
-# Define a single subnet.
+// Define a single subnet.
   "subnet4": [
     {
       "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
@@ -26,11 +26,11 @@
     }
   ],
 
-# Set up the hooks libraries.  For this example, we assume that two libraries
-# are loaded, called "security" and "charging".  Note that order is important:
-# "security" is specified first so if both libraries supply a hook function
-# for a given hook, the function in "security" will be called before that in
-# "charging".
+// Set up the hooks libraries.  For this example, we assume that two libraries
+// are loaded, called "security" and "charging".  Note that order is important:
+// "security" is specified first so if both libraries supply a hook function
+// for a given hook, the function in "security" will be called before that in
+// "charging".
 
   "hooks-libraries": [
      {

doc/examples/kea4/leases-expiration.json

@@ -1,32 +1,32 @@
-# This is an example configuration file for the DHCPv4 server in Kea.
-# It provides parameters controlling processing of expired leases,
-# a.k.a. leases reclamation.
+// This is an example configuration file for the DHCPv4 server in Kea.
+// It provides parameters controlling processing of expired leases,
+// a.k.a. leases reclamation.
 
 { "Dhcp4":
 
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
     "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": {
       "type": "memfile",
       "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,
@@ -36,11 +36,11 @@
     "unwarned-reclaim-cycles": 10
   },
 
-# Addresses will be assigned with a lifetime of 4000 seconds.
+// Addresses will be assigned with a lifetime of 4000 seconds.
   "valid-lifetime": 4000,
 
-# The following list defines subnets. We have only one subnet
-# here. We tell Kea that it is directly available over local interface.
+// The following list defines subnets. We have only one subnet
+// here. We tell Kea that it is directly available over local interface.
   "subnet4": [
     {
        "pools": [ { "pool":  "192.0.2.1 - 192.0.2.200" } ],
@@ -50,8 +50,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": {
     "loggers": [
         {

doc/examples/kea4/mysql-reservations.json

@@ -1,58 +1,58 @@
-# This is an example configuration file for the DHCPv4 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 DHCPv4 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.
 { "Dhcp4":
 
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
     "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": {
       "type": "memfile",
       "lfc-interval": 3600
   },
 
-# Addresses will be assigned with a lifetime of 4000 seconds.
+// Addresses will be assigned with a lifetime of 4000 seconds.
   "valid-lifetime": 4000,
 
-# Renew and rebind timers are commented out. This implies that options
-# 58 and 59 will not be sent to the client. In this case it is up to
-# the client to pick the timer values according to RFC2131. Uncomment the
-# timers to send these options to the client.
-#  "renew-timer": 1000,
-#  "rebind-timer": 2000,
+// Renew and rebind timers are commented out. This implies that options
+// 58 and 59 will not be sent to the client. In this case it is up to
+// the client to pick the timer values according to RFC2131. Uncomment the
+// timers to send these options to the client.
+//  "renew-timer": 1000,
+//  "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.
+// 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" ],
 
-# 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": {
     "type": "mysql",
     "name": "kea",
@@ -62,11 +62,11 @@
     "port": 3306
   },
 
-# Define a subnet with a single pool of dynamic addresses. Addresses from
-# this pool 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 single pool of dynamic addresses. Addresses from
+// this pool 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.
   "subnet4": [
     {
        "pools": [ { "pool":  "192.0.2.10 - 192.0.2.200" } ],
@@ -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": {
     "loggers": [
         {

doc/examples/kea4/pgsql-reservations.json

@@ -1,57 +1,57 @@
-# This is an example configuration file for the DHCPv4 server in Kea.
-# It contains configuration of the PostgreSQL host database backend, used
-# to retrieve reserved addresses, host names, DHCPv4 message fields
-# and DHCP options from PostgreSQL database.
+// This is an example configuration file for the DHCPv4 server in Kea.
+// It contains configuration of the PostgreSQL host database backend, used
+// to retrieve reserved addresses, host names, DHCPv4 message fields
+// and DHCP options from PostgreSQL database.
 { "Dhcp4":
 
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
     "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": {
     "type": "memfile"
   },
 
-# Addresses will be assigned with a lifetime of 4000 seconds.
+// Addresses will be assigned with a lifetime of 4000 seconds.
   "valid-lifetime": 4000,
 
-# Renew and rebind timers are commented out. This implies that options
-# 58 and 59 will not be sent to the client. In this case it is up to
-# the client to pick the timer values according to RFC2131. Uncomment the
-# timers to send these options to the client.
-#  "renew-timer": 1000,
-#  "rebind-timer": 2000,
+// Renew and rebind timers are commented out. This implies that options
+// 58 and 59 will not be sent to the client. In this case it is up to
+// the client to pick the timer values according to RFC2131. Uncomment the
+// timers to send these options to the client.
+//  "renew-timer": 1000,
+//  "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.
+// 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" ],
 
-# Specify connection to the database holding host reservations. The type
-# specifies that the PostgreSQL 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 PostgreSQL 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": {
     "type": "postgresql",
     "name": "kea",
@@ -60,11 +60,11 @@
     "host": "localhost"
   },
 
-# Define a subnet with a single pool of dynamic addresses. Addresses from
-# this pool 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 single pool of dynamic addresses. Addresses from
+// this pool 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.
   "subnet4": [
     {
        "pools": [ { "pool":  "192.0.2.10 - 192.0.2.200" } ],
@@ -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": {
     "loggers": [
         {

doc/examples/kea4/several-subnets.json

@@ -1,54 +1,54 @@
-# This is an example configuration file for DHCPv4 server in Kea.
-# It's a basic scenario with three IPv4 subnets configured. In each
-# subnet, there's a smaller pool of dynamic addresses.
+// This is an example configuration file for DHCPv4 server in Kea.
+// It's a basic scenario with three IPv4 subnets configured. In each
+// subnet, there's a smaller pool of dynamic addresses.
 
 { "Dhcp4":
 
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
     "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": {
     "type": "memfile"
   },
 
-# Addresses will be assigned with a lifetime of 4000 seconds.
-# The client is told to start renewing after 1000 seconds. If the server
-# does not respond within 2000 seconds of the lease being granted, client
-# is supposed to start REBIND procedure (emergency renewal that allows
-# switching to a different server).
+// Addresses will be assigned with a lifetime of 4000 seconds.
+// The client is told to start renewing after 1000 seconds. If the server
+// does not respond within 2000 seconds of the lease being granted, client
+// is supposed to start REBIND procedure (emergency renewal that allows
+// switching to a different server).
   "valid-lifetime": 4000,
   "renew-timer": 1000,
   "rebind-timer": 2000,
 
-# RFC6842 says that the server is supposed to echo back client-id option.
-# However, some older clients do not support this and are getting confused
-# when they get their own client-id. Kea can disable RFC6842 support.
+// RFC6842 says that the server is supposed to echo back client-id option.
+// However, some older clients do not support this and are getting confused
+// 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
-# least subnet and pool entries.
+// The following list defines subnets. Each subnet consists of at
+// least subnet and pool entries.
   "subnet4": [
   {
       "pools": [ { "pool":  "192.0.2.1 - 192.0.2.200" } ],
       "subnet": "192.0.2.0/24"
   },
   {
-# This particular subnet has match-client-id value changed.
+// This particular subnet has match-client-id value changed.
       "pools": [ { "pool": "192.0.3.100 - 192.0.3.200" } ],
       "subnet": "192.0.3.0/24",
       "match-client-id": false
@@ -59,8 +59,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": {
     "loggers": [
         {

doc/examples/kea4/single-subnet.json

@@ -1,36 +1,36 @@
-# This is an example configuration file for the DHCPv4 server in Kea.
-# It is a basic scenario with one IPv4 subnet configured. The subnet
-# contains a single pool of dynamically allocated addresses.
+// This is an example configuration file for the DHCPv4 server in Kea.
+// It is a basic scenario with one IPv4 subnet configured. The subnet
+// contains a single pool of dynamically allocated addresses.
 
 { "Dhcp4":
 
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
     "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": {
       "type": "memfile",
       "lfc-interval": 3600
   },
 
-# Addresses will be assigned with a lifetime of 4000 seconds.
+// Addresses will be assigned with a lifetime of 4000 seconds.
   "valid-lifetime": 4000,
 
-# Renew and rebind timers are commented out. This implies that options
-# 58 and 59 will not be sent to the client. In this case it is up to
-# the client to pick the timer values according to RFC2131. Uncomment the
-# timers to send these options to the client.
-#  "renew-timer": 1000,
-#  "rebind-timer": 2000,
+// Renew and rebind timers are commented out. This implies that options
+// 58 and 59 will not be sent to the client. In this case it is up to
+// the client to pick the timer values according to RFC2131. Uncomment the
+// timers to send these options to the client.
+//  "renew-timer": 1000,
+//  "rebind-timer": 2000,
 
-# The following list defines subnets. We have only one subnet
-# here. We tell Kea that it is directly available over local interface.
+// The following list defines subnets. We have only one subnet
+// here. We tell Kea that it is directly available over local interface.
   "subnet4": [
     {
        "pools": [ { "pool":  "192.0.2.1 - 192.0.2.200" } ],
@@ -40,8 +40,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": {
     "loggers": [
         {

doc/examples/kea4/with-ddns.json

@@ -1,36 +1,36 @@
-# This is an example configuration file for the DHCPv4 server in Kea.
-# It is a basic scenario with one IPv4 subnet configured but with DDNS
-# enabled. 
+// This is an example configuration file for the DHCPv4 server in Kea.
+// It is a basic scenario with one IPv4 subnet configured but with DDNS
+// enabled. 
 
 { "Dhcp4":
 
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
     "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": {
       "type": "memfile",
       "lfc-interval": 3600
   },
 
-# Addresses will be assigned with a lifetime of 4000 seconds.
+// Addresses will be assigned with a lifetime of 4000 seconds.
   "valid-lifetime": 4000,
 
-# Renew and rebind timers are commented out. This implies that options
-# 58 and 59 will not be sent to the client. In this case it is up to
-# the client to pick the timer values according to RFC2131. Uncomment the
-# timers to send these options to the client.
-#  "renew-timer": 1000,
-#  "rebind-timer": 2000,
+// Renew and rebind timers are commented out. This implies that options
+// 58 and 59 will not be sent to the client. In this case it is up to
+// the client to pick the timer values according to RFC2131. Uncomment the
+// timers to send these options to the client.
+//  "renew-timer": 1000,
+//  "rebind-timer": 2000,
 
-# The following list defines subnets. We have only one subnet
-# here. We tell Kea that it is directly available over local interface.
+// The following list defines subnets. We have only one subnet
+// here. We tell Kea that it is directly available over local interface.
   "subnet4": [
     {
        "pools": [ { "pool":  "192.0.2.1 - 192.0.2.200" } ],
@@ -39,7 +39,7 @@
     }
   ],
 
-# Enable dynamic DNS updates
+// Enable dynamic DNS updates
   "dhcp-ddns" : {
         "enable-updates" : true,
         "server-ip" : "192.0.2.0",
@@ -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": {
     "loggers": [
         {

doc/examples/kea6/dhcpv4-over-dhcpv6.json

@@ -1,13 +1,13 @@
-# This is an example configuration file for the DHCPv6 server of
-# DHCPv4-over-DHCPv6 tests in Kea.
+// This is an example configuration file for the DHCPv6 server of
+// DHCPv4-over-DHCPv6 tests in Kea.
 
 {
 
-# DHCPv6 conf
+// DHCPv6 conf
 "Dhcp6":
 {
   "interfaces-config": {
-# Enable unicast
+// Enable unicast
     "interfaces": [ "eno33554984/2001:db8:1:1::1" ]
   },
 
@@ -27,16 +27,16 @@
        "pools": [ { "pool": "2001:db8:1:1::1:0/112" } ] }
    ],
 
-# This enables DHCPv4-over-DHCPv6 support
+// This enables DHCPv4-over-DHCPv6 support
   "dhcp4o6-port": 6767,
 
-# Required by DHCPv4-over-DHCPv6 clients
+// Required by DHCPv4-over-DHCPv6 clients
   "option-data": [
    {  "name": "dhcp4o6-server-addr",
       "code": 88,
       "space": "dhcp6",
       "csv-format": true,
-# Put the server address here
+// Put the server address here
       "data": "2001:db8:1:1::1" }
    ]
 },

doc/examples/kea6/hooks.json

@@ -1,27 +1,27 @@
-# This is an example configuration file for the DHCPv6 server in Kea
-# illustrating the configuration of hooks libraries.  It uses a basic scenario
-# of one IPv6 subnet configured with the default values for all parameters.
+// This is an example configuration file for the DHCPv6 server in Kea
+// illustrating the configuration of hooks libraries.  It uses a basic scenario
+// of one IPv6 subnet configured with the default values for all parameters.
 
 {"Dhcp6":
 
 {
-# Kea is told to listen on the ethX interface only.
+// Kea is told to listen on the ethX interface only.
   "interfaces-config": {
     "interfaces": [ "ethX" ]
   },
 
-# Set up the storage for leases.
+// Set up the storage for leases.
   "lease-database": {
     "type": "memfile"
   },
 
-# Set values to mandatory timers
+// Set values to mandatory timers
   "renew-timer": 900,
   "rebind-timer": 1200,
   "preferred-lifetime": 1800,
   "valid-lifetime": 2700,
 
-# Define a single subnet.
+// Define a single subnet.
   "subnet6": [
     {
       "pools": [
@@ -34,11 +34,11 @@
     }
   ],
 
-# Set up the hooks libraries.  For this example, we assume that two libraries
-# are loaded, called "security" and "charging".  Note that order is important:
-# "security" is specified first so if both libraries supply a hook function
-# for a given hook, the function in "security" will be called before that in
-# "charging".
+// Set up the hooks libraries.  For this example, we assume that two libraries
+// are loaded, called "security" and "charging".  Note that order is important:
+// "security" is specified first so if both libraries supply a hook function
+// for a given hook, the function in "security" will be called before that in
+// "charging".
 
   "hooks-libraries": [
      {

doc/examples/kea6/pgsql-reservations.json

@@ -1,45 +1,45 @@
-# This is an example configuration file for the DHCPv6 server in Kea.
-# It contains configuration of the PostgreSQL host database backend, used
-# to retrieve reserved addresses, host names, DHCPv4 message fields
-# and DHCP options from PostgreSQL database.
+// This is an example configuration file for the DHCPv6 server in Kea.
+// It contains configuration of the PostgreSQL host database backend, used
+// to retrieve reserved addresses, host names, DHCPv4 message fields
+// and DHCP options from PostgreSQL database.
 { "Dhcp6":
 
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
     "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": {
     "type": "memfile"
   },
 
-# 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,
   "valid-lifetime": 4000,
   "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
-# specifies that the PostgreSQL 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 PostgreSQL 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": {
     "type": "postgresql",
     "name": "kea",
@@ -48,11 +48,11 @@
     "host": "localhost"
   },
 
-# 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": [
     {
       "subnet": "2001:db8:1::/48",
@@ -72,8 +72,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": {
     "loggers": [
         {

doc/examples/kea6/several-subnets.json

@@ -1,36 +1,36 @@
-# This is an example configuration file for DHCPv6 server in Kea.
-# It's a basic scenario with four IPv6 subnets configured. In each
-# subnet, there's a smaller pool of dynamic addresses.
+// This is an example configuration file for DHCPv6 server in Kea.
+// It's a basic scenario with four IPv6 subnets configured. In each
+// subnet, there's a smaller pool of dynamic addresses.
 
 { "Dhcp6":
 
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
     "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": {
     "type": "memfile"
   },
 
-# 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,
   "valid-lifetime": 4000,
   "renew-timer": 1000,
   "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": [
   {    "pools": [ { "pool": "2001:db8:1::/80" } ],
        "subnet": "2001:db8:1::/64"  },
@@ -42,8 +42,8 @@
        "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": [
         {

doc/examples/kea6/softwire46.json

@@ -1,50 +1,50 @@
-# This is an example configuration file for DHCPv6 server in Kea.
-# It demonstrates how user can specify values for Softwire options
-# defined in RFC 7598 for Lightweight 4over6 architecture.
+// This is an example configuration file for DHCPv6 server in Kea.
+// It demonstrates how user can specify values for Softwire options
+// defined in RFC 7598 for Lightweight 4over6 architecture.
 
 { "Dhcp6":
 
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
     "interfaces": [ "ethX" ]
   },
 
-# Let's use a Memfile backend to store leases.
+// Let's use a Memfile backend to store leases.
   "lease-database": {
     "type": "memfile"
   },
 
-# 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,
   "valid-lifetime": 4000,
   "renew-timer": 1000,
   "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": [
     {
       "pools": [ { "pool": "2001:db8:1::/80" } ],
       "subnet": "2001:db8:1::/64",
       "interface": "ethX",
-# Include MAP-E Container option for hosts connected to this subnet.
+// Include MAP-E Container option for hosts connected to this subnet.
       "option-data": [
         {
             "name": "s46-cont-mape"
         }
       ],
-# Send host specific softwire options.
+// Send host specific softwire options.
       "reservations": [
         {
             "duid": "01:02:03:04:05:06:07:08:09:0A",
             "option-data": [
-# These two options will be included in the MAP-E Container
+// These two options will be included in the MAP-E Container
               {
                 "space": "s46-cont-mape-options",
                 "name": "s46-rule",
@@ -55,10 +55,10 @@
                 "name": "s46-br",
                 "data": "2001:db8:cafe::1"
               },
-# This option will be included in the S46 Rule option. It includes
-# PSID/PSID length value in a user friendly form. The PSID length
-# specifies the number of bits on which PSID is coded. The PSID
-# value 3 is a 4th value that is coded on these 4 bits: "0011b".
+// This option will be included in the S46 Rule option. It includes
+// PSID/PSID length value in a user friendly form. The PSID length
+// specifies the number of bits on which PSID is coded. The PSID
+// value 3 is a 4th value that is coded on these 4 bits: "0011b".
               {
                 "space": "s46-rule-options",
                 "name": "s46-portparams",
@@ -71,8 +71,8 @@
   ]
 },
 
-# The following configures logging. Kea will log all debug messages
-# to /var/log/kea-debug.log file.
+// The following configures logging. Kea will log all debug messages
+// to /var/log/kea-debug.log file.
 "Logging": {
     "loggers": [
         {

doc/examples/kea6/with-ddns.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":
 
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
     "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": {
       "type": "memfile",
       "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,
   "valid-lifetime": 4000,
   "renew-timer": 1000,
   "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": [
     {
       "pools": [ { "pool": "2001:db8:1::/80" } ],
@@ -41,7 +41,7 @@
     }
   ],
 
-# Enable dynamic DNS updates
+// Enable dynamic DNS updates
   "dhcp-ddns" : {
         "enable-updates" : true,
         "server-ip" : "3001::1",
@@ -61,8 +61,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": {
     "loggers": [
         {