[#4340] Unified to datatracker

Author: fxdupont

doc/devel/bison.dox

@@ -9,7 +9,7 @@
 
 @section parserIntro Parser background
 
-Kea's data format of choice is JSON (defined in https://tools.ietf.org/html/rfc7159), which is used
+Kea's data format of choice is JSON (defined in https://datatracker.ietf.org/doc/html/rfc7159), which is used
 in configuration files, in the command channel and also when communicating between the DHCP servers
 and the DHCP-DDNS component. It is almost certain to be used as the data format for any new
 features.

doc/sphinx/arm/classify.rst

@@ -473,15 +473,15 @@ Notes:
 
 -  "Vendor option" means the Vendor-Identifying Vendor-Specific Information
    option in DHCPv4 (code 125; see `Section 4 of RFC
-   3925 <https://tools.ietf.org/html/rfc3925#section-4>`__) and the
+   3925 <https://datatracker.ietf.org/doc/html/rfc3925#section-4>`__) and the
    Vendor-Specific Information Option in DHCPv6 (code 17, defined in
    `Section 21.17 of RFC
-   8415 <https://tools.ietf.org/html/rfc8415#section-21.17>`__). "Vendor
+   8415 <https://datatracker.ietf.org/doc/html/rfc8415#section-21.17>`__). "Vendor
    class option" means the Vendor-Identifying Vendor Class Option in DHCPv4
    (code 124; see `Section 3 of RFC
-   3925 <https://tools.ietf.org/html/rfc3925#section-3>`__) in DHCPv4 and
+   3925 <https://datatracker.ietf.org/doc/html/rfc3925#section-3>`__) in DHCPv4 and
    the Class Option in DHCPv6 (code 16; see `Section 21.16 of RFC
-   8415 <https://tools.ietf.org/html/rfc8415#section-21.16>`__). Vendor
+   8415 <https://datatracker.ietf.org/doc/html/rfc8415#section-21.16>`__). Vendor
    options may have sub-options that are referenced by their codes.
    Vendor class options do not have sub-options, but rather data chunks,
    which are referenced by index value. Index 0 means the first data
@@ -494,8 +494,8 @@ Notes:
 -  Vendor Class Identifier (option 60 in DHCPv4) can be accessed using the
    option[60] expression.
 
--  `RFC 3925 <https://tools.ietf.org/html/rfc3925>`__ and `RFC
-   8415 <https://tools.ietf.org/html/rfc8415>`__ allow for multiple
+-  `RFC 3925 <https://datatracker.ietf.org/doc/html/rfc3925>`__ and `RFC
+   8415 <https://datatracker.ietf.org/doc/html/rfc8415>`__ allow for multiple
    instances of vendor options to appear in a single message. The client
    classification code currently examines the first instance if more
    than one appear. For the ``vendor.enterprise`` and ``vendor-class.enterprise``

doc/sphinx/arm/config.rst

@@ -29,7 +29,7 @@ JSON Syntax
 
 Configuration files for the DHCPv4, DHCPv6, DDNS, Control Agent, and
 NETCONF modules are defined in an extended JSON format. Basic JSON is
-defined in `RFC 7159 <https://tools.ietf.org/html/rfc7159>`__ and `ECMA
+defined in `RFC 7159 <https://datatracker.ietf.org/doc/html/rfc7159>`__ and `ECMA
 404 <https://www.ecma-international.org/publications/standards/Ecma-404.htm>`__.
 In particular, the only boolean values allowed are true or false (all
 lowercase). The capitalized versions (True or False) are not accepted.

doc/sphinx/arm/ddns.rst

@@ -11,7 +11,7 @@ Overview
 
 The DHCP-DDNS Server (:iscman:`kea-dhcp-ddns`, known informally as D2) conducts
 the client side of the Dynamic DNS protocol (DDNS, defined in `RFC
-2136 <https://tools.ietf.org/html/rfc2136>`__) on behalf of the DHCPv4
+2136 <https://datatracker.ietf.org/doc/html/rfc2136>`__) on behalf of the DHCPv4
 and DHCPv6 servers (:iscman:`kea-dhcp4` and :iscman:`kea-dhcp6`, respectively).
 The DHCP servers construct DDNS update requests, known as NameChangeRequests
 (NCRs), based on DHCP lease change events and then post them to D2. D2
@@ -67,7 +67,7 @@ Conflict Resolution
 -------------------
 
 D2 implements the conflict resolution strategy prescribed by `RFC
-4703 <https://tools.ietf.org/html/rfc4703>`__. Conflict resolution is
+4703 <https://datatracker.ietf.org/doc/html/rfc4703>`__. Conflict resolution is
 intended to prevent different clients from mapping to the same FQDN at
 the same time. To make this possible, the RFC requires that forward DNS
 entries for a given FQDN must be accompanied by a DHCID resource record
@@ -98,12 +98,12 @@ Dual-Stack Environments
 -----------------------
 
 `RFC 4703, section
-5.2, <https://tools.ietf.org/html/rfc4703#section-5.2>`__ describes
+5.2, <https://datatracker.ietf.org/doc/html/rfc4703#section-5.2>`__ describes
 issues that may arise with dual-stack clients. These are clients that
 wish to have both IPv4 and IPv6 mappings for the same FQDN.
 To work properly, clients must embed their IPv6 DUID
 within their IPv4 client identifier option, as described in `RFC
-4361 <https://tools.ietf.org/html/rfc4361>`__. In this way, DNS updates
+4361 <https://datatracker.ietf.org/doc/html/rfc4361>`__. In this way, DNS updates
 for both IPv4 and IPv6 can be managed under the same DHCID RR. This feature
 is supported by Kea beginning with release 2.1.2.
 
@@ -496,7 +496,7 @@ TSIG Key List
 
 A DDNS protocol exchange can be conducted with or without a transaction
 signature, or TSIG (defined
-in `RFC 2845 <https://tools.ietf.org/html/rfc2845>`__). This
+in `RFC 2845 <https://datatracker.ietf.org/doc/html/rfc2845>`__). This
 configuration section allows the administrator to define the set of TSIG
 keys that may be used in such exchanges.
 
@@ -1150,19 +1150,19 @@ Supported Standards
 The following RFCs are supported by the DHCP-DDNS server:
 
 - *Secret Key Transaction Authentication for DNS (TSIG)*, `RFC 2845
-  <https://tools.ietf.org/html/rfc2845>`__: All DNS update packets sent and
+  <https://datatracker.ietf.org/doc/html/rfc2845>`__: All DNS update packets sent and
   received by the DHCP-DDNS server can be protected by TSIG signatures.
 
 - *Dynamic Updates in the Domain Name System (DNS UPDATE)*, `RFC 2136
-  <https://tools.ietf.org/html/rfc2136>`__: The complete DNS update mechanism is
+  <https://datatracker.ietf.org/doc/html/rfc2136>`__: The complete DNS update mechanism is
   supported.
 
 - *Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host
   Configuration Protocol (DHCP) Clients*, `RFC 4703
-  <https://tools.ietf.org/html/rfc4703>`__: DHCP-DDNS takes care of
+  <https://datatracker.ietf.org/doc/html/rfc4703>`__: DHCP-DDNS takes care of
   conflict resolution, for both DHCPv4 and DHCPv6 servers.
 
 - *A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol
   (DHCP) Information (DHCID RR)*, `RFC 4701
-  <https://tools.ietf.org/html/rfc4701>`__: The DHCP-DDNS server uses DHCID
+  <https://datatracker.ietf.org/doc/html/rfc4701>`__: The DHCP-DDNS server uses DHCID
   records.