rfc9886.original   rfc9886.txt 
drip Working Group A. Wiethuechter, Ed. Internet Engineering Task Force (IETF) A. Wiethuechter, Ed.
Internet-Draft AX Enterprize, LLC Request for Comments: 9886 AX Enterprize, LLC
Intended status: Standards Track J. Reid Category: Standards Track J. Reid
Expires: 20 February 2026 RTFM llp ISSN: 2070-1721 RTFM llp
19 August 2025 December 2025
DRIP Entity Tags in the Domain Name System DRIP Entity Tags (DETs) in the Domain Name System
draft-ietf-drip-registries-33
Abstract Abstract
This document defines the Domain Name System (DNS) functionality of a This document defines the Domain Name System (DNS) functionality of a
Drone Remote Identification Protocol (DRIP) Identity Management Drone Remote Identification Protocol (DRIP) Identity Management
Entity (DIME). It is built around DRIP Entity Tags (DETs) to Entity (DIME). It is built around DRIP Entity Tags (DETs) to
standardize a hierarchical registry structure and associated standardize a hierarchical registry structure and associated
processes to facilitate trustable and scalable registration and processes to facilitate trustable and scalable registration and
lookup of information related to Unmanned Aircraft Systems (UAS). lookup of information related to Unmanned Aircraft Systems (UAS).
The registry system supports issuance, discovery, and verification of The registry system supports issuance, discovery, and verification of
DETs, enabling secure identification and association of UAS and their DETs, enabling secure identification and association of UAS and their
operators. It also defines the interactions between different operators. It also defines the interactions between different
classes of registries (root, organizational, and individual) and classes of registries (root, organizational, and individual) and
their respective roles in maintaining the integrity of the their respective roles in maintaining the integrity of the
registration data. This architecture enables decentralized, registration data. This architecture enables decentralized,
federated operation while supporting privacy, traceability, and federated operation while supporting privacy, traceability, and
regulatory compliance requirements in the context of UAS Remote ID regulatory compliance requirements in the context of UAS Remote
and other services. Identification and other services.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 20 February 2026. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9886.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. General Concept . . . . . . . . . . . . . . . . . . . . . 4 1.1. General Concept
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Scope
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
2.1. Required Terminology . . . . . . . . . . . . . . . . . . 4 2.1. Required Terminology
2.2. Additional Definitions . . . . . . . . . . . . . . . . . 5 2.2. Additional Definitions
3. DET Hierarchy in DNS . . . . . . . . . . . . . . . . . . . . 5 3. DET Hierarchy in DNS
3.1. Use of Existing DNS Models . . . . . . . . . . . . . . . 6 3.1. Use of Existing DNS Models
3.1.1. DNS Model Considerations for DIMEs . . . . . . . . . 7 3.1.1. DNS Model Considerations for DIMEs
4. Public Information Registry . . . . . . . . . . . . . . . . . 8 4. Public Information Registry
5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 9 5. Resource Records
5.1. HHIT Resource Record . . . . . . . . . . . . . . . . . . 9 5.1. HHIT Resource Record
5.1.1. Text Representation . . . . . . . . . . . . . . . . . 10 5.1.1. Text Representation
5.1.2. Field Descriptions . . . . . . . . . . . . . . . . . 10 5.1.2. Field Descriptions
5.2. UAS Broadcast RID Resource Record . . . . . . . . . . . . 11 5.2. UAS Broadcast RID Resource Record
5.2.1. Text Representation . . . . . . . . . . . . . . . . . 11 5.2.1. Text Representation
5.2.2. Field Descriptions . . . . . . . . . . . . . . . . . 11 5.2.2. Field Descriptions
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations
6.1. DET Prefix Delegation . . . . . . . . . . . . . . . . . . 13 6.1. DET Prefix Delegation
6.2. IANA DRIP Registry . . . . . . . . . . . . . . . . . . . 13 6.2. IANA DRIP Registry
6.2.1. DRIP RAA Allocations . . . . . . . . . . . . . . . . 13 6.2.1. DRIP RAA Allocations
6.2.2. HHIT Entity Type . . . . . . . . . . . . . . . . . . 16 6.2.2. HHIT Entity Type
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations
7.1. DNS Operational & Registration Considerations . . . . . . 18 7.1. DNS Operational and Registration Considerations
7.2. DET & Public Key Exposure . . . . . . . . . . . . . . . . 19 7.2. DET and Public Key Exposure
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 8. References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 19 8.2. Informative References
9.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Example Zone Files and RRType Contents
Appendix A. Example Zone Files & RRType Contents . . . . . . . . 23 A.1. Example RAA
A.1. Example RAA . . . . . . . . . . . . . . . . . . . . . . . 23 A.1.1. Authentication HHIT
A.1.1. Authentication HHIT . . . . . . . . . . . . . . . . . 23 A.1.2. Delegation of HDA
A.1.2. Delegation of HDA . . . . . . . . . . . . . . . . . . 25 A.2. Example HDA
A.2. Example HDA . . . . . . . . . . . . . . . . . . . . . . . 25 A.2.1. Authentication and Issue HHITs
A.2.1. Authentication & Issue HHITs . . . . . . . . . . . . 25 A.2.2. Registratant HHIT and BRID
A.2.2. Registratant HHIT & BRID . . . . . . . . . . . . . . 30 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses
1. Introduction 1. Introduction
Registries are fundamental to Unmanned Aircraft System (UAS) Remote Registries are fundamental to Unmanned Aircraft System (UAS) Remote
Identification (RID). Only very limited operational information can Identification (RID). Only very limited operational information can
be sent via Broadcast RID, but extended information is sometimes be sent via Broadcast RID, but extended information is sometimes
needed. The most essential element of information from RID is the needed. The most essential element of information from RID is the
UAS ID, the unique key for lookup of extended information in relevant UAS ID, the unique key for lookup of extended information in relevant
registries (see Figure 1; Figure 4 of [RFC9434]). registries (see Figure 1, which is the same as Figure 4 of
[RFC9434]).
*************** *************** *************** ***************
* UAS1 * * UAS2 * * UAS1 * * UAS2 *
* * * * * * * *
* +--------+ * DAA/V2V * +--------+ * * +--------+ * DAA/V2V * +--------+ *
* | UA o--*----------------------------------------*--o UA | * * | UA o--*----------------------------------------*--o UA | *
* +--o--o--+ * * +--o--o--+ * * +--o--o--+ * * +--o--o--+ *
* | | * +------+ Lookups +------+ * | | * * | | * +------+ Lookups +------+ * | | *
* | | * | GPOD o------. .------o PSOD | * | | * * | | * | GPOD o------. .------o PSOD | * | | *
* | | * +------+ | | +------+ * | | * * | | * +------+ | | +------+ * | | *
skipping to change at page 4, line 4 skipping to change at line 140
+----------+ | +----------+ +----------+ | +----------+
+--o--+ +--o--+
| DNS | | DNS |
+-----+ +-----+
DAA: Detect And Avoid DAA: Detect And Avoid
GPOD: General Public Observer Device GPOD: General Public Observer Device
PSOD: Public Safety Observer Device PSOD: Public Safety Observer Device
V2I: Vehicle-to-Infrastructure V2I: Vehicle-to-Infrastructure
V2V: Vehicle-to-Vehicle V2V: Vehicle-to-Vehicle
Figure 1: Global UAS RID Usage Scenario (Figure 4 of RFC9434)
Figure 1: Global UAS RID Usage Scenario (Figure 4 of RFC 9434)
When a DRIP Entity Tag (DET) [RFC9374] is used as the UAS ID in RID, When a DRIP Entity Tag (DET) [RFC9374] is used as the UAS ID in RID,
extended information can be retrieved from a DRIP Identity Management extended information can be retrieved from a DRIP Identity Management
Entity (DIME), which manages registration of and associated lookups Entity (DIME), which manages registration of and associated lookups
from DETs. In this document it is assumed the DIME is a function of from DETs. In this document it is assumed the DIME is a function of
UAS Service Suppliers (USS) (Appendix A.2 of [RFC9434]) but a DIME UAS Service Suppliers (USS) (Appendix A.2 of [RFC9434]), but a DIME
can be independent or handled by another entity as well. can be independent or handled by another entity as well.
1.1. General Concept 1.1. General Concept
DRIP Entity Tags (DETs) embed a hierarchy scheme which is mapped onto DRIP Entity Tags (DETs) embed a hierarchy scheme that is mapped onto
the Domain Name System (DNS) [STD13]. DIMEs enforce registration and the Domain Name System (DNS) [STD13]. DIMEs enforce registration and
information access of data associated with a DET while also providing information access of data associated with a DET while also providing
the trust inherited from being a member of the hierarchy. Other the trust inherited from being a member of the hierarchy. Other
identifiers and their methods are out of scope for this document. identifiers and their methods are out of scope for this document.
Authoritative Name Servers of the DNS provide the public information Authoritative Name Servers of the DNS provide the public information
such as the cryptographic keys, endorsements and certificates of DETs such as the cryptographic keys, endorsements and certificates of
and pointers to private information resources. Cryptographic DETs, and pointers to private information resources. Cryptographic
(public) keys are used to authenticate anything signed by a DET, such (public) keys are used to authenticate anything signed by a DET, such
as in the Authentication defined in [RFC9575] for Broadcast RID. as in the Authentication defined in [RFC9575] for Broadcast RID.
Endorsements and certificates are used to endorse the claim of being Endorsements and certificates are used to endorse the claim of being
part of the hierarchy. part of the hierarchy.
This document does not specify AAA mechanisms used by Private This document does not specify AAA mechanisms used by Private
Information Registries to store and protect Personally Identifiable Information Registries to store and protect Personally Identifiable
Information (PII). Information (PII).
1.2. Scope 1.2. Scope
The scope of this document is the DNS registration of DETs with the The scope of this document is the DNS registration of DETs with the
DNS delegation of the reverse domain of IPv6 Prefix, assigned by IANA DNS delegation of the reverse domain of the IPv6 prefix, assigned by
for DETs 2001:30::/28 and RRsets used to handle DETs. IANA for DETs 2001:30::/28 and RRsets used to handle DETs.
2. Terminology 2. Terminology
2.1. Required Terminology 2.1. Required Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. Additional Definitions 2.2. Additional Definitions
This document makes use of the terms and abbreviations from previous This document makes use of the terms and abbreviations from previous
DRIP documents. Below are subsets, grouped by original document, of DRIP documents. Below are subsets, grouped by original document, of
terms used this document. Please see those documents for additional terms used this document. Please see those documents for additional
context, definitions and any further referenced material. context, definitions, and any further referenced material.
From Section 2.2 of [RFC9153] this document uses: AAA, CAA, GCS, From Section 2.2 of [RFC9153], this document uses: AAA, CAA, GCS,
ICAO, PII, Observer, Operator, UA, UAS, USS, and UTM. ICAO, PII, Observer, Operator, UA, UAS, USS, and UTM.
From Section 2 of [RFC9434] this document uses: Certificate, DIME, From Section 2 of [RFC9434], this document uses: Certificate, DIME,
and Endorsement. and Endorsement.
From Section 2 of [RFC9374] this document uses: HDA, HID, and RAA. From Section 2 of [RFC9374], this document uses: HDA, HID, and RAA.
3. DET Hierarchy in DNS 3. DET Hierarchy in DNS
[RFC9374] defines the HHIT and further specifies an instance of them [RFC9374] defines the Hierarchical Host Identity Tags (HHIT) and
used for UAS RID called DETs. The HHIT/DET is a 128-bit value that further specifies an instance of them used for UAS RID called DETs.
is as an IPv6 address intended primarily as an identifier rather than The HHIT/DET is a 128-bit value that is as an IPv6 address intended
locator. Its format is in Figure 2, shown here for reference, and primarily as an identifier rather than locator. The format is shown
further information is in [RFC9374]. in Figure 2 and further information is in [RFC9374].
+-------------+--------------+---------------+-------------+ +-------------+--------------+---------------+-------------+
| IPv6 Prefix | Hierarchy ID | HHIT Suite ID | ORCHID Hash | | IPv6 Prefix | Hierarchy ID | HHIT Suite ID | ORCHID Hash |
| (28 bits) | (28 bits) | (8 bits) | (64 bits) | | (28 bits) | (28 bits) | (8 bits) | (64 bits) |
+-------------+--------------+---------------+-------------+ +-------------+--------------+---------------+-------------+
/ \ / \
/ \ / \
/ \-----------------------------\ / \-----------------------------\
/ \ / \
/ \ / \
skipping to change at page 5, line 50 skipping to change at line 231
+--------------------------------+-----------------------+ +--------------------------------+-----------------------+
Figure 2: DRIP Entity Tag Breakdown Figure 2: DRIP Entity Tag Breakdown
[RFC9374] assigns the IPv6 prefix 2001:30::/28 for DETs. Its [RFC9374] assigns the IPv6 prefix 2001:30::/28 for DETs. Its
corresponding domain name for reverse lookups is corresponding domain name for reverse lookups is
3.0.0.1.0.0.2.ip6.arpa.. The IAB has administrative control of this 3.0.0.1.0.0.2.ip6.arpa.. The IAB has administrative control of this
domain name. domain name.
Due to the nature of the hierarchy split and its relationship to Due to the nature of the hierarchy split and its relationship to
nibble reversing of the IPv6 address (Section 2.5 of [STD88]), the nibble reversing of the IPv6 address (Section 2.5 of RFC 3596
upper level of hierarchy (i.e., Registered Assigning Authority (RAA)) [STD88]), the upper level of the hierarchy (i.e., Registered
"borrows" the upper two bits of their respective HHIT Domain Assigning Authority (RAA)) "borrows" the upper two bits of their
Authority (HDA) space for DNS delegation. As such the IPv6 prefix of respective HHIT Domain Authority (HDA) space for DNS delegation. As
RAAs are 2001:3x:xxx0::/44 and HDAs are 2001:3x:xxxy:yy00::/56 with such, the IPv6 prefix of RAAs is 2001:3x:xxx0::/44 and HDAs is
respective nibble reverse domains of x.x.x.x.3.0.0.1.0.0.2.ip6.arpa. 2001:3x:xxxy:yy00::/56 with respective nibble reverse domains of
and y.y.y.x.x.x.x.3.0.0.1.0.0.2.ip6.arpa.. x.x.x.x.3.0.0.1.0.0.2.ip6.arpa. and
y.y.y.x.x.x.x.3.0.0.1.0.0.2.ip6.arpa..
This document preallocates a subset of RAAs based on the ISO 3166-1 This document preallocates a subset of RAAs based on the ISO 3166-1
Numeric Nation Code [ISO3166-1]. This is to support the initial use Numeric Nation Code [ISO3166-1]. This is to support the initial use
case of DETs in UAS RID on an international level. See Section 6.2.1 case of DETs in UAS RID on an international level. See Section 6.2.1
for the RAA allocations. for the RAA allocations.
The HDA values of 0, 4096, 8192 and 12288 are reserved for The HDA values of 0, 4096, 8192, and 12288 are reserved for
operational use of an RAA (a by-product of the above mentioned operational use of an RAA (a by-product of the above mentioned
borrowing of bits), specifically when to register with the apex and borrowing of bits), in particular to specify when to register with
endorse delegations of HDAs in their namespace. the apex and endorse delegations of HDAs in their namespace.
The administration, management and policy for the operation of a DIME The administration, management, and policy for the operation of a
at any level in the hierarchy (Apex, RAA or HDA) is out of scope for DIME at any level in the hierarchy (Apex, RAA or HDA) is out of scope
this document. For RAAs or DETs allocated on a per-country basis, for this document. For RAAs or DETs allocated on a per-country
these considerations should be be determined by the appropriate basis, these considerations should be determined by the appropriate
national authorities, presumably the Civil Aviation Authority (CAA). national authorities, presumably the Civil Aviation Authority (CAA).
3.1. Use of Existing DNS Models 3.1. Use of Existing DNS Models
DRIP relies on the DNS and as such roughly follows the registrant- DRIP relies on the DNS and as such roughly follows the registrant-
registrar-registry model. In the UAS ecosystem, the registrant would registrar-registry model. In the UAS ecosystem, the registrant would
be the end user who owns/controls the Unmanned Aircraft. They are be the end user who owns/controls the Unmanned Aircraft. They are
ultimately responsible for the DET and any other information that ultimately responsible for the DET and any other information that
gets published in the DNS. Registrants use agents known as gets published in the DNS. Registrants use agents known as
registrars to manage their interactions with the registry. registrars to manage their interactions with the registry.
Registrars typically provide optional additional services such as DNS Registrars typically provide optional additional services such as DNS
hosting. hosting.
The registry maintains a database of the registered domain names and The registry maintains a database of the registered domain names and
their related metadata such as the contact details for domain name their related metadata such as the contact details for domain name
holder and the relevant registrar. The registry provides DNS service holder and the relevant registrar. The registry provides DNS service
for the zone apex which contains delegation information for domain for the zone apex, which contains delegation information for domain
names. Registries generally provide services such RDAP [STD95] or names. Registries generally provide services such as the
equivalent to publish metadata about the registered domain names and Registration Data Access Protocol (RDAP) [STD95] or equivalent to
their registrants and registrars. publish metadata about the registered domain names and their
registrants and registrars.
Registrants have contracts with registrars who in turn have contracts Registrants have contracts with registrars who in turn have contracts
with registries. Payments follow this model too: the registrant buys with registries. Payments follow this model too: the registrant buys
services from a registrar who pays for services provided by the services from a registrar who pays for services provided by the
registry. registry.
By definition, there can only be one registry for a domain name. A By definition, there can only be one registry for a domain name. A
registry can have an arbitrary number of registrars who compete with registry can have an arbitrary number of registrars who compete with
each other on price, service and customer support. each other on price, service, and customer support.
3.1.1. DNS Model Considerations for DIMEs 3.1.1. DNS Model Considerations for DIMEs
Apex Apex
Registry/Registrar Registry/Registrar
(IANA) (IANA)
+=========================+ +=========================+
| 3.0.0.1.0.0.2.ip6.arpa. | | 3.0.0.1.0.0.2.ip6.arpa. |
+============o============+ +============o============+
| |
skipping to change at page 7, line 47 skipping to change at line 327
Local | Local |
Registrants | Registrants |
+=====================o================+ +=====================o================+
| x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.5.0. | | x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.5.0. |
+======================================+ +======================================+
Figure 3: Example DRIP DNS Model Figure 3: Example DRIP DNS Model
While the registrant-registrar-registry model is mature and well While the registrant-registrar-registry model is mature and well
understood, it may not be appropriate for DRIP registrations in some understood, it may not be appropriate for DRIP registrations in some
circumstances. It could add costs and complexity; developing circumstances. It could add costs and complexity to develop policies
policies and contracts as outlined above. On the other hand, and contracts as outlined above. On the other hand, registries and
registries and registrars offer customer service/support and can registrars offer customer service and support and can provide the
provide the supporting infrastructure for reliable DNS and RDAP supporting infrastructure for reliable DNS and RDAP service.
service.
Another approach could be to handle DRIP registrations in a Another approach could be to handle DRIP registrations in a
comparable way to how IP address space gets provisioned. Here, comparable way to how IP address space gets provisioned. Here,
blocks of addresses get delegated to a "trusted" third party, blocks of addresses get delegated to a "trusted" third party,
typically an ISP, who then issues IP addresses to its customers. For typically an ISP, who then issues IP addresses to its customers. For
DRIP, blocks of IP addresses could be delegated from the DRIP, blocks of IP addresses could be delegated from the
3.0.0.1.0.0.2.ip6.arpa. domain (reverse domain of prefix allocated by 3.0.0.1.0.0.2.ip6.arpa. domain (reverse domain of prefix allocated by
[RFC9374]) to an entity chosen by the appropriate Civil Aviation [RFC9374]) to an entity chosen by the appropriate Civil Aviation
Authority (CAA). This third party would be responsible for the Authority (CAA). This third party would be responsible for the
corresponding DNS and RDAP infrastructure for these IP address corresponding DNS and RDAP infrastructure for these IP address
blocks. They would also provision the Hierarchical Host Identity Tag blocks. They would also provision the HHIT records [RFC9374] for
(HHIT, [RFC9374]) records for these IP addresses. In principle a these IP addresses. In principle, a manufacturer or vendor of UAS
manufacturer or vendor of UAS devices could provide that role. This devices could provide that role. This is shown as an example in
is shown as an example in Figure 3. Figure 3.
Dynamic DRIP registration is another possible solution, for example Dynamic DRIP registration is another possible solution, for example
when the operator of a UAS device registers its corresponding HHIT when the operator of a UAS device registers its corresponding HHIT
record and other resources before a flight and deletes them record and other resources before a flight and deletes them
afterwards. This may be feasible in controlled environments with afterwards. This may be feasible in controlled environments with
well-behaved actors. However, this approach may not scale since each well-behaved actors. However, this approach may not scale since each
device is likely to need credentials for updating the IT device is likely to need credentials for updating the IT
infrastructure which provisions the DNS. infrastructure that provisions the DNS.
Registration policies (pricing, renewals, registrar and registrant Registration policies (pricing, renewals, registrar, and registrant
agreements, etc.) will need to be developed. These considerations agreements, etc.) will need to be developed. These considerations
should be determined by the CAA, perhaps in consultation with local should be determined by the CAA, perhaps in consultation with local
stakeholders to assess the cost-benefits of these approaches (and stakeholders to assess the cost-benefits of these approaches (and
others). All of these are out of scope for this document. The others). All of these are out of scope for this document. The
specifics for the UAS RID use case are detailed in the rest of specifics for the UAS RID use case are detailed in the rest of
document. document.
4. Public Information Registry 4. Public Information Registry
Per [RFC9434] all information classified as public is stored in the Per [RFC9434], all information classified as public is stored in the
DNS, specifically Authoritative Name Servers, to satisfy REG-1 from DNS, specifically Authoritative Name Servers, to satisfy REG-1 from
[RFC9153]. [RFC9153].
Authoritative Name Servers use domain names as identifiers and data Authoritative Name Servers use domain names as identifiers and data
is stored in Resource Records (RR) with associated RRTypes. This is stored in Resource Records (RRs) with associated RRTypes. This
document defines two new RRTypes, one for HHIT metadata (HHIT, document defines two new RRTypes, one for HHIT metadata (HHIT,
Section 5.1) and another for UAS Broadcast RID information (BRID, Section 5.1) and another for UAS Broadcast RID information (BRID,
Section 5.2). The former RRType is particularly important as it Section 5.2). The former RRType is particularly important as it
contains a URI (as part of the certificate) that points to Private contains a URI (as part of the certificate) that points to Private
Information resources. Information resources.
DETs, being IPv6 addresses, are to be under ip6.arpa. (nibble DETs, being IPv6 addresses, are to be under ip6.arpa. (nibble
reversed per Section 2.5 of [STD88]) and MUST resolve to an HHIT reversed per Section 2.5 of RFC 3596 [STD88]) and MUST resolve to an
RRType. Depending on local circumstances or additional use cases HHIT RRType. Depending on local circumstances or additional use
other RRTypes MAY be present (for example the inclusion of the DS cases, other RRTypes MAY be present (for example the inclusion of the
RRTypes or equivalent when using DNSSEC). For UAS RID the BRID DS RRTypes or equivalent when using DNSSEC). For UAS RID, the BRID
RRType MUST be present to provide the Broadcast Endorsements (BEs) RRType MUST be present to provide the Broadcast Endorsements (BEs)
defined in Section 3.1.2.1 of [RFC9575]. defined in Section 3.1.2.1 of [RFC9575].
DNSSEC MUST be used for apex entities (those which use a self-signed DNSSEC MUST be used for apex entities (those which use a self-signed
Canonical Registration Certificate) and is RECOMMENDED for other Canonical Registration Certificate) and is RECOMMENDED for other
entities. When a DIME decides to use DNSSEC they SHOULD define a entities. When a DIME decides to use DNSSEC, they SHOULD define a
framework for cryptographic algorithms and key management [RFC6841]. framework for cryptographic algorithms and key management [RFC6841].
This may be influenced by frequency of updates, size of the zone, and This may be influenced by the frequency of updates, size of the zone,
policies. and policies.
UAS-specific information, such as physical characteristics, may also UAS-specific information, such as physical characteristics, may also
be stored in DNS but is out of scope for this document. be stored in DNS but is out of scope for this document.
A DET IPv6 address gets mapped into domain names using the scheme A DET IPv6 address gets mapped into domain names using the scheme
defined in Section 2.5 of [STD88]. However DNS lookups of these defined in Section 2.5 of RFC 3596 [STD88]. However, DNS lookups of
names query for HHIT and/or BRID resource records rather than the PTR these names query for HHIT and/or BRID resource records rather than
resource records conventionally used in reverse lookups of IP the PTR resource records conventionally used in reverse lookups of IP
addresses. For example, the HHIT resource record for the DET addresses. For example, the HHIT resource record for the DET
2001:30::1 would be returned from a DNS lookup for the HHIT QTYPE for 2001:30::1 would be returned from a DNS lookup for the HHIT QTYPE for
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.0.0.1.0.0.2.ip6.a 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.0.0.1.0.0.2.ip6.a
rpa.. rpa..
The HHIT RRType provides the public key for signature verification The HHIT RRType provides the public key for signature verification
and URIs via the certificate. The BRID RRType provides static and URIs via the certificate. The BRID RRType provides static
Broadcast RID information such as the Broadcast Endorsements sent Broadcast RID information such as the Broadcast Endorsements sent as
following [RFC9575]. described in [RFC9575].
5. Resource Records 5. Resource Records
5.1. HHIT Resource Record 5.1. HHIT Resource Record
The HHIT Resource Record (HHIT, RRType 67) is a metadata record for The HHIT Resource Record (HHIT, RRType 67) is a metadata record for
various bits of HHIT-specific information that isn't available in the various bits of HHIT-specific information that isn't available in the
pre-existing HIP RRType. The HHIT RRType does not replace the HIP pre-existing HIP RRType. The HHIT RRType does not replace the HIP
RRType. The primary advantage of the HHIT RRType over the existing RRType. The primary advantage of the HHIT RRType over the existing
RRType is the mandatory inclusion of the Canonical Registration RRType is the mandatory inclusion of the Canonical Registration
Certificate containing an entity's public key signed by the Certificate containing an entity's public key signed by the
registrar, or other trust anchor, to confirm registration. registrar, or other trust anchor, to confirm registration.
The data MUST be encoded in CBOR [RFC8949] bytes. The CDDL [RFC8610] The data MUST be encoded in the Concise Binary Object Representation
of the data is provided in Figure 4. (CBOR) [RFC8949] bytes. The Concise Data Definition Language (CDDL)
[RFC8610] of the data is provided in Figure 4.
5.1.1. Text Representation 5.1.1. Text Representation
The data are represented in base64 [RFC4648] and may be divided into The data are represented in base64 [RFC4648] and may be divided into
any number of white-space-separated substrings, down to single base64 any number of white-space-separated substrings, down to single base64
digits, which are concatenated to obtain the full object. These digits, which are concatenated to obtain the full object. These
substrings can span lines using the standard parenthesis. Note that substrings can span lines using the standard parenthesis. Note that
the data has internal subfields but these do not appear in the master the data has internal subfields but these do not appear in the master
file representation; only a single logical base64 string will appear. file representation; only a single logical base64 string will appear.
skipping to change at page 10, line 34 skipping to change at line 453
canonical-registration-cert: bstr canonical-registration-cert: bstr
] ]
Figure 4: HHIT Wire Format CDDL Figure 4: HHIT Wire Format CDDL
All fields of the HHIT RRType MUST be included to be properly formed. All fields of the HHIT RRType MUST be included to be properly formed.
HHIT Entity Type: The HHIT Entity Type field is a number with values HHIT Entity Type: The HHIT Entity Type field is a number with values
defined in Section 6.2.2. It is envisioned that there may be many defined in Section 6.2.2. It is envisioned that there may be many
types of HHITs in use. In some cases, it may be helpful to types of HHITs in use. In some cases, it may be helpful to
understand the HHITs role in the ecosystem like described in understand the role of the HHITs in the ecosystem, like that
[drip-dki]. This field provides such context. This field MAY described in [drip-dki]. This field provides such context. This
provide a signal of additional information and/or different field MAY provide a signal of additional information and/or
handling of the data beyond what is defined in this document. different handling of the data beyond what is defined in this
document.
HID Abbreviation: The HID Abbreviation field is a string that HID Abbreviation: The HID Abbreviation field is a string that
provides an abbreviation to the HID structure of a DET for display provides an abbreviation to the HID (Hierarchy ID) structure of a
devices. The convention for such abbreviations is a matter of DET for display devices. The convention for such abbreviations is
local policy. Absent of such a policy, this field MUST be filled a matter of local policy. Absent of such a policy, this field
with the four character hexadecimal representations of the RAA and MUST be filled with the four character hexadecimal representations
HDA (in that order) with a separator character such as a space. of the RAA and HDA (in that order) with a separator character,
For example, a DET with an RAA value of 10 and HDA value of 20 such as a space, in between. For example, a DET with an RAA value
would be abbreviated as: 000A 0014. of 10 and HDA value of 20 would be abbreviated as: 000A 0014.
Canonical Registration Certificate: The Canonical Registration Canonical Registration Certificate: The Canonical Registration
Certificate field is for a certificate endorsing registration of Certificate field is for a certificate-endorsing registration of
the DET. It MUST be encoded as X.509 DER [RFC5280]. This the DET. It MUST be encoded as X.509 DER [RFC5280]. This
certificate MAY be self-signed when the entity is acting as a root certificate MAY be self-signed when the entity is acting as a root
of trust (i.e., an apex). Such self-signed behavior is defined by of trust (i.e., an apex). Such self-signed behavior is defined by
policy, such as in [drip-dki], and is out of scope for this policy, such as in [drip-dki], and is out of scope for this
document. This certificate is part of chain of certificates that document. This certificate is part of a chain of certificates
can be used to validate inclusion in the heirarchy. that can be used to validate inclusion in the hierarchy.
5.2. UAS Broadcast RID Resource Record 5.2. UAS Broadcast RID Resource Record
The UAS Broadcast RID Resource Record (BRID, RRType 68) is a format The UAS Broadcast RID Resource Record (BRID, RRType 68) is a format
to hold public information typically sent over UAS Broadcast RID that to hold public information typically sent over UAS Broadcast RID that
is static. It can act as a data source if information is not is static. It can act as a data source if information is not
received over Broadcast RID or for cross validation. The primary received over Broadcast RID or for cross validation. The primary
function for DRIP is the inclusion of one or more Broadcast function for DRIP is to include of one or more Broadcast Endorsements
Endorsements as defined in [RFC9575] in the auth field. These as defined in [RFC9575] in the auth field. These Endorsements are
Endorsements are generated by the registrar upon successful generated by the registrar upon successful registration and broadcast
registration and broadcast by the entity. by the entity.
The data MUST be encoded in CBOR [RFC8949] bytes. The CDDL [RFC8610] The data MUST be encoded in CBOR [RFC8949] bytes. The CDDL [RFC8610]
of the data is provided in Figure 5. of the data is provided in Figure 5.
5.2.1. Text Representation 5.2.1. Text Representation
The data are represented in base64 [RFC4648] and may be divided into The data are represented in base64 [RFC4648] and may be divided into
any number of white-space-separated substrings, down to single base64 any number of white-space-separated substrings, down to single base64
digits, which are concatenated to obtain the full object. These digits, which are concatenated to obtain the full object. These
substrings can span lines using the standard parenthesis. Note that substrings can span lines using the standard parenthesis. Note that
skipping to change at page 13, line 5 skipping to change at line 558
uas_type = 0 uas_type = 0
uas_ids = 1 uas_ids = 1
auth = 2 auth = 2
self_id = 3 self_id = 3
area = 4 area = 4
classification = 5 classification = 5
operator_id = 6 operator_id = 6
Figure 5: BRID Wire Format CDDL Figure 5: BRID Wire Format CDDL
The field names and their general typing are borrowed from the ASTM The field names and their general typing are taken from the ASTM data
[F3411] data dictionary (Table 1 and Table 2). See that document for dictionary (Tables 1 and 2) [F3411]. See that document for
additional context and background information on aviation additional context and background information on aviation
application-specific interpretation of the field semantics. The application-specific interpretation of the field semantics. The
explicitly enumerated values included in the CDDL above are relevant explicitly enumerated values included in the CDDL above are relevant
to DRIP for its operation. Other values may be valid but are outside to DRIP for its operation. Other values may be valid but are outside
the scope of DRIP operation. Application-specific fields, such as the scope of DRIP operation. Application-specific fields, such as
UAS Type are transported and authenticated by DRIP but are regarded UAS Type, are transported and authenticated by DRIP but are regarded
as opaque user data to DRIP. as opaque user data to DRIP.
6. IANA Considerations 6. IANA Considerations
6.1. DET Prefix Delegation 6.1. DET Prefix Delegation
The reverse domain for the DET Prefix, i.e., 3.0.0.1.0.0.2.ip6.arpa., The reverse domain for the DET Prefix, i.e., 3.0.0.1.0.0.2.ip6.arpa.,
is managed by the IANA following the usual IANA rules. IANA will is managed by IANA. IANA will liaise, as needed, with the
liaise, as needed, with the International Civil Aviation Organization International Civil Aviation Organization (ICAO) to verify the
(ICAO) to verify the authenticity of delegations to CAAs (see authenticity of delegations to CAAs (see Section 6.2.1.4).
Section 6.2.1.4).
6.2. IANA DRIP Registry 6.2. IANA DRIP Registry
6.2.1. DRIP RAA Allocations 6.2.1. DRIP RAA Allocations
This document requests a new registry for RAA Allocations under the IANA has created the registry for RAA Allocations under the "Drone
DRIP registry group (https://www.iana.org/assignments/drip) to be Remote ID Protocol" registry group <https://www.iana.org/assignments/
managed by IANA. drip>.
RAA Allocations: a 14-bit value used to represent RAAs. Future RAA Allocations: a 14-bit value used to represent RAAs. Future
additions to this registry are to be made based on the following additions to this registry are to be made based on the following
range/policy table: range and policy table:
+===========+======================+================================+ +===========+======================+================================+
| RAA Range | Allocation | Policy | | RAA Range | Allocation | Policy |
+===========+======================+================================+ +===========+======================+================================+
| 0 - 3 | Reserved | N/A | | 0 - 3 | Reserved | |
+-----------+----------------------+--------------------------------+ +-----------+----------------------+--------------------------------+
| 4 - 3999 | ISO 3166-1 | IESG Approval (Section 4.10 of | | 4 - 3999 | ISO 3166-1 | IESG Approval (Section 4.10 of |
| | Countries | [RFC8126]), Section 6.2.1.4 | | | Countries | [RFC8126]), Section 6.2.1.4 |
+-----------+----------------------+--------------------------------+ +-----------+----------------------+--------------------------------+
| 4000 - | Reserved | N/A | | 4000 - | Reserved | |
| 8191 | | | | 8191 | | |
+-----------+----------------------+--------------------------------+ +-----------+----------------------+--------------------------------+
| 8192 - | Unassigned | First Come First Served | | 8192 - | Unassigned | First Come First Served |
| 15359 | | (Section 4.4 of [RFC8126]) | | 15359 | | (Section 4.4 of [RFC8126]) |
+-----------+----------------------+--------------------------------+ +-----------+----------------------+--------------------------------+
| 15360 - | Private | Private Use (Section 4.1 of | | 15360 - | Private | Private Use (Section 4.1 of |
| 16383 | Use | [RFC8126]), Section 6.2.1.5 | | 16383 | Use | [RFC8126]), Section 6.2.1.5 |
+-----------+----------------------+--------------------------------+ +-----------+----------------------+--------------------------------+
Table 1: RAA Ranges Table 1: RAA Ranges
skipping to change at page 14, line 37 skipping to change at line 621
Value: The RAA value delegated for this entry. Value: The RAA value delegated for this entry.
Name: Name of the delegated RAA. For the ISO 3166-1 Countries Name: Name of the delegated RAA. For the ISO 3166-1 Countries
(Section 6.2.1.4), this should be the name of the country. (Section 6.2.1.4), this should be the name of the country.
Policy Reference: A publicly accessible link to the requirements for Policy Reference: A publicly accessible link to the requirements for
prospective HDA operators to register under this RAA. This field prospective HDA operators to register under this RAA. This field
is OPTIONAL. is OPTIONAL.
Contact: Contact details of the administrator of this RAA that Contact: Contact details of the administrator of this RAA that
prospective HDAs operators can make informational queries to. prospective HDA operators can make informational queries to.
6.2.1.2. RAA Registration Form 6.2.1.2. RAA Registration Form
Value: Value:
Name: Name:
Policy Reference: Policy Reference:
Contact: Contact:
NS RRType Content (HDA=0): NS RRType Content (HDA=0):
NS RRType Content (HDA=4096): NS RRType Content (HDA=4096):
NS RRType Content (HDA=8192): NS RRType Content (HDA=8192):
NS RRType Content (HDA=12288): NS RRType Content (HDA=12288):
Figure 6: RAA Delegation Request Form Figure 6: RAA Delegation Request Form
The NS RRType Content (HDA=X) fields are used by IANA to perform the The NS RRType Content (HDA=X) fields are used by IANA to perform the
DNS delegations under 3.0.0.1.0.0.2.ip6.arpa.. See Section 6.2.1.3 DNS delegations under 3.0.0.1.0.0.2.ip6.arpa.. See Section 6.2.1.3
for technical details. for technical details.
6.2.1.3. Handling Nibble Split 6.2.1.3. Handling Nibble Split
To support DNS delegation in 3.0.0.1.0.0.2.ip6.arpa. a single RAA is To support DNS delegation in 3.0.0.1.0.0.2.ip6.arpa., a single RAA is
given 4 delegations by borrowing the upper two bits of HDA space (see given 4 delegations by borrowing the upper two bits of HDA space (see
Figure 7 for an example). This enables a clean nibble boundary in Figure 7 for an example). This enables a clean nibble boundary in
DNS to delegate from (i.e., the prefix 2001:3x:xxx0::/44). These the DNS to delegate from (i.e., the prefix 2001:3x:xxx0::/44). These
HDAs (0, 4096, 8192 and 12288) are reserved for the RAA. HDAs (0, 4096, 8192 and 12288) are reserved for the RAA.
7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 0 0 0 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 0 0 0
2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 9 8 7 6 5 4 3 2 1 0 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | x | RAA=16376 | | 0 | x | RAA=16376 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 | 0 | 0 | 0 | E | F | F HDA=0,x=00 0 | 0 | 0 | 0 | E | F | F HDA=0,x=00
0 | 0 | 0 | 1 | E | F | F HDA=4096,x=01 0 | 0 | 0 | 1 | E | F | F HDA=4096,x=01
0 | 0 | 0 | 2 | E | F | F HDA=8192,x=10 0 | 0 | 0 | 2 | E | F | F HDA=8192,x=10
0 | 0 | 0 | 3 | E | F | F HDA=12288,x=11 0 | 0 | 0 | 3 | E | F | F HDA=12288,x=11
Figure 7: Example Bit Borrowing of RAA=16376 Figure 7: Example Bit Borrowing of RAA=16376
6.2.1.4. ISO 3166-1 Countries Range 6.2.1.4. ISO 3166-1 Countries Range
The mapping between ISO 3166-1 Numeric Nation Codes and RAAs is The mapping between ISO 3166-1 Numeric Nation Codes and RAAs is
specified and documented by IANA. Each Nation is assigned four RAAs specified and documented by IANA. Each Nation is assigned 4 RAAs
that are left to the national authority for their purpose. For RAAs that are left to the national authority for their purpose. For RAAs
under this range, a shorter prefix of 2001:3x:xx00::/40 MAY be under this range, a shorter prefix of 2001:3x:xx00::/40 MAY be
delegated to each CAA, which covers all 4 RAAs (and reserved HDAs) delegated to each CAA, which covers all 4 RAAs (and reserved HDAs)
assigned to them. assigned to them.
This range is set to IESG Approval (Section 4.10 of [RFC8126]) and This range is set to IESG Approval (Section 4.10 of [RFC8126]) and
IANA will liaise with the ICAO to verify the authenticity of IANA will liaise with the ICAO to verify the authenticity of
delegation requests (using Figure 6) by CAAs. delegation requests (using Figure 6) by CAAs.
The CSV file found for the ISO to RAA mapping is on GitHub
(https://github.com/ietf-wg-drip/draft-ietf-drip-
registries/commit/a8da51bfcafcdf91878f8862c52830aa736782c9). RFC
Editor, please remove this note after IANA initializes the
registry but before publication.
6.2.1.5. Private Range 6.2.1.5. Private Range
If nibble-reversed lookup in DNS is desired it can only provided by If nibble-reversed lookup in DNS is desired, it can only be provided
private DNS servers as zone delegations from the global root will not by private DNS servers as zone delegations from the global root will
be performed for this address range. Thus the RAAs (with its not be performed for this address range. Thus the RAAs (with its
subordinate HDAs) in this range may be used in like manner and IANA subordinate HDAs) in this range may be used in like manner and IANA
will not delegate any value in this range to any party (as per will not delegate any value in this range to any party (as per
Private Use, Section 4.1 of [RFC8126]). Private Use, Section 4.1 of [RFC8126]).
One anticipated acceptable use of the private range is for One anticipated acceptable use of the private range is for
experimentation and testing prior to request allocation or assignment experimentation and testing prior to request allocation or assignment
from IANA. from IANA.
6.2.2. HHIT Entity Type 6.2.2. HHIT Entity Type
This document requests a new registry for HHIT Entity Type under the This document requests a new registry for HHIT Entity Type under the
DRIP registry group (https://www.iana.org/assignments/drip). "Drone Remote ID Protocol" registry group
<https://www.iana.org/assignments/drip>.
HHIT Entity Type: numeric, field of the HHIT RRType to encode the HHIT Entity Type: Numeric, field of the HHIT RRType to encode the
HHIT Entity Type. All entries in this registry are under a First HHIT Entity Type. All entries in this registry are under the
Come First Served (Section 4.4 of [RFC8126]) policy. First Come First Served policy (Section 4.4 of [RFC8126]).
6.2.2.1. HHIT Type Registry Fields 6.2.2.1. HHIT Type Registry Fields
Value: HHIT Type value of entry. Value: HHIT Type value of the entry.
HHIT Type: Name of the entry and optional abbreviation. HHIT Type: Name of the entry and an optional abbreviation.
Reference: Public document allocating the value and any additional Reference: Public document allocating the value and any additional
information such as semantics. This can be a URL pointing to an information such as semantics. This can be a URL pointing to an
Internet-Draft, IETF RFC, or web-page among others. Internet-Draft, IETF RFC, or web page among others.
6.2.2.2. HHIT Type Registration Form 6.2.2.2. HHIT Type Registration Form
Value: Value:
HHIT Type: HHIT Type:
Reference: Reference:
Figure 8: HHIT Type Registration Form Figure 8: HHIT Type Registration Form
6.2.2.3. Initial Values 6.2.2.3. Initial Values
The following values are defined by this document: The following values are defined by this document:
+=======+===========================================+===========+ +=======+===========================================+===========+
| Value | HHIT Type | Reference | | Value | HHIT Type | Reference |
+=======+===========================================+===========+ +=======+===========================================+===========+
| 0 | Not Defined | This RFC | | 0 | Not Defined | RFC 9886 |
+-------+-------------------------------------------+-----------+ +-------+-------------------------------------------+-----------+
| 1 | DRIP Identity Management Entity (DIME) | This RFC | | 1 | DRIP Identity Management Entity (DIME) | RFC 9886 |
+-------+-------------------------------------------+-----------+ +-------+-------------------------------------------+-----------+
| 5 | Apex | This RFC | | 5 | Apex | RFC 9886 |
+-------+-------------------------------------------+-----------+ +-------+-------------------------------------------+-----------+
| 9 | Registered Assigning Authority (RAA) | This RFC | | 9 | Registered Assigning Authority (RAA) | RFC 9886 |
+-------+-------------------------------------------+-----------+ +-------+-------------------------------------------+-----------+
| 13 | HHIT Domain Authority (HDA) | This RFC | | 13 | HHIT Domain Authority (HDA) | RFC 9886 |
+-------+-------------------------------------------+-----------+ +-------+-------------------------------------------+-----------+
| 16 | Unmanned Aircraft (UA) | This RFC | | 16 | Unmanned Aircraft (UA) | RFC 9886 |
+-------+-------------------------------------------+-----------+ +-------+-------------------------------------------+-----------+
| 17 | Ground Control Station (GCS) | This RFC | | 17 | Ground Control Station (GCS) | RFC 9886 |
+-------+-------------------------------------------+-----------+ +-------+-------------------------------------------+-----------+
| 18 | Unmanned Aircraft System (UAS) | This RFC | | 18 | Unmanned Aircraft System (UAS) | RFC 9886 |
+-------+-------------------------------------------+-----------+ +-------+-------------------------------------------+-----------+
| 19 | Remote Identification (RID) Module | This RFC | | 19 | Remote Identification (RID) Module | RFC 9886 |
+-------+-------------------------------------------+-----------+ +-------+-------------------------------------------+-----------+
| 20 | Pilot | This RFC | | 20 | Pilot | RFC 9886 |
+-------+-------------------------------------------+-----------+ +-------+-------------------------------------------+-----------+
| 21 | Operator | This RFC | | 21 | Operator | RFC 9886 |
+-------+-------------------------------------------+-----------+ +-------+-------------------------------------------+-----------+
| 22 | Discovery & Synchronization Service (DSS) | This RFC | | 22 | Discovery & Synchronization Service (DSS) | RFC 9886 |
+-------+-------------------------------------------+-----------+ +-------+-------------------------------------------+-----------+
| 23 | UAS Service Supplier (USS) | This RFC | | 23 | UAS Service Supplier (USS) | RFC 9886 |
+-------+-------------------------------------------+-----------+ +-------+-------------------------------------------+-----------+
| 24 | Network RID Service Provider (SP) | This RFC | | 24 | Network RID Service Provider (SP) | RFC 9886 |
+-------+-------------------------------------------+-----------+ +-------+-------------------------------------------+-----------+
| 25 | Network RID Display Provider (DP) | This RFC | | 25 | Network RID Display Provider (DP) | RFC 9886 |
+-------+-------------------------------------------+-----------+ +-------+-------------------------------------------+-----------+
| 26 | Supplemental Data Service Provider (SDSP) | This RFC | | 26 | Supplemental Data Service Provider (SDSP) | RFC 9886 |
+-------+-------------------------------------------+-----------+ +-------+-------------------------------------------+-----------+
| 27 | Crowd Sourced RID Finder | This RFC | | 27 | Crowd Sourced RID Finder | RFC 9886 |
+-------+-------------------------------------------+-----------+ +-------+-------------------------------------------+-----------+
Table 2: HHIT Entity Type Initial Values Table 2: HHIT Entity Type Initial Values
7. Security Considerations 7. Security Considerations
7.1. DNS Operational & Registration Considerations
7.1. DNS Operational and Registration Considerations
The Registrar and Registry are commonly used concepts in the DNS. The Registrar and Registry are commonly used concepts in the DNS.
These components interface the DIME into the DNS hierarchy and thus These components interface the DIME into the DNS hierarchy and thus
operation SHOULD follow best common practices, specifically in operation SHOULD follow best common practices, specifically in
security (such as running DNSSEC) as appropriate except when national security (such as running DNSSEC) as appropriate except when national
regulations prevent it. [BCP237] provides suitable guidance. regulations prevent it. [BCP237] provides suitable guidance.
If DNSSEC is used, a DNSSEC Practice Statement SHOULD be developed If DNSSEC is used, a DNSSEC Practice Statement SHOULD be developed
and published. It SHOULD explain how DNSSEC has been deployed and and published. It SHOULD explain how DNSSEC has been deployed and
what security measures are in place. [RFC6841] documents a Framework what security measures are in place. [RFC6841] documents a framework
for DNSSEC Policies and DNSSEC Practice Statements. A self-signed for DNSSEC policies and DNSSEC Practice Statements. A self-signed
entity (i.e. an entity that self-signed it certificate as part of the entity (i.e., an entity that self-signed its certificate as part of
HHIT RRType) MUST use DNSSEC. the HHIT RRType) MUST use DNSSEC.
The interfaces and protocol specifications for registry-registrar The interfaces and protocol specifications for registry-registrar
interactions are intentionally not specified in this document. These interactions are intentionally not specified in this document. These
will depend on nationally defined policy and prevailing local will depend on nationally defined policy and prevailing local
circumstances. It is expected registry-registrar activity will use circumstances. It is expected that registry-registrar activity will
the Extensible Provisioning Protocol (EPP) [STD69] or equivalent. use the Extensible Provisioning Protocol (EPP) [STD69] or equivalent.
The registry SHOULD provide a lookup service such as RDAP [STD95] or The registry SHOULD provide a lookup service such as RDAP [STD95] or
equivalent to publish public information about registered domain equivalent to publish public information about registered domain
names. names.
Decisions about DNS or registry best practices and other operational Decisions about DNS or registry best practices and other operational
matters that influence security SHOULD be made by the CAA, ideally in matters that influence security SHOULD be made by the CAA, ideally in
consultation with local stakeholders. consultation with local stakeholders.
The guidance above is intended to reduce the likelihood of The guidance above is intended to reduce the likelihood of
interoperability problems and minimize security and stability interoperability problems and minimize security and stability
concerns. For instance, validation and authentication of DNS concerns. For instance, validation and authentication of DNS
responses depends on DNSSEC. If this is not used, entities using responses depends on DNSSEC. If this is not used, entities using
DRIP will be vulnerable to DNS spoofing attacks and could be exposed DRIP will be vulnerable to DNS spoofing attacks and could be exposed
to bogus data. DRIP DNS responses that have not been validated by to bogus data. DRIP DNS responses that have not been validated by
DNSSEC could contain bogus data which have the potential to create DNSSEC could contain bogus data that have the potential to create
serious security problems and operational concerns for DRIP entities. serious security problems and operational concerns for DRIP entities.
These threats include denial of service attacks, replay attacks, These threats include denial-of-service attacks, replay attacks,
impersonation or cloning of UAVs, hijacking of DET registrations, impersonation or cloning of UAVs, hijacking of DET registrations,
injection of corrupt metadata and compromising established trust injection of corrupt metadata, and compromising established trust
architecture/relationships. Some regulatory and legal considerations architecture/relationships. Some regulatory and legal considerations
are expected to be simplified by providing a lookup service for are expected to be simplified by providing a lookup service for
access to public information about registered domain names for DETs. access to public information about registered domain names for DETs.
When DNSSEC is not in use, due to the length of the ORCHID hash When DNSSEC is not in use, due to the length of the ORCHID hash
selected for DETs (Section 3.5 of [RFC9374]), clients MUST "walk" the selected for DETs (Section 3.5 of [RFC9374]), clients MUST "walk" the
tree of certificates locating each certificate by performing DNS tree of certificates locating each certificate by performing DNS
lookups of HHIT RRTypes for each DET verifying inclusion into the lookups of HHIT RRTypes for each DET verifying inclusion into the
hierarchy. The collection of these certificates (which provide both hierarchy. The collection of these certificates (which provide both
signature protection from the parent entity and the public key of the signature protection from the parent entity and the public key of the
entity) is the only way without DNSSEC to prove valid registration. entity) is the only way without DNSSEC to prove valid registration.
The contents of the BRID RRType auth key, containing Endorsements as The contents of the BRID RRType auth key, containing Endorsements as
described in Section 4.2 of [RFC9575], are a shadow of the X.509 described in Section 4.2 of [RFC9575], are a shadow of the X.509
certificate found in the HHIT RRType. The validation of these certificate found in the HHIT RRType. The validation of these
Endorsements follow the guidelines written in Section 6.4.2 of Endorsements follow the guidelines written in Section 6.4.2 of
[RFC9575] for Broadcast RID Observers and when present MUST also be [RFC9575] for Broadcast RID Observers and when present MUST also be
validated. validated.
7.2. DET & Public Key Exposure 7.2. DET and Public Key Exposure
DETs are built upon asymmetric keys. As such the public key must be DETs are built upon asymmetric keys. As such the public key must be
revealed to enable clients to perform signature verifications. revealed to enable clients to perform signature verifications.
[RFC9374] security considerations cover various attacks on such keys. [RFC9374] security considerations cover various attacks on such keys.
While unlikely, the forging of a corresponding private key is While unlikely, the forging of a corresponding private key is
possible if given enough time (and computational power). possible if given enough time (and computational power).
When practical, it is RECOMMENDED that no RRTypes under a DET's When practical, it is RECOMMENDED that no RRTypes under a DET's
specific domain name be published unless and until it is required for specific domain name be published unless and until it is required for
use by other parties. Such action would cause at least the HHIT use by other parties. Such action would cause at least the HHIT
RRType to not be in DNS, protecting the public key in the certificate RRType to not be in the DNS, protecting the public key in the
from being exposed before its needed. The combination of this "just certificate from being exposed before its needed. The combination of
in time" publishing mechanism and DNSSEC is out of scope for this this "just in time" publishing mechanism and DNSSEC is out of scope
document. for this document.
Optimally this requires that the UAS somehow signal the DIME that a
flight using a Specific Session ID will soon be underway or complete.
It may also be facilitated under UTM if the USS (which may or may not
be a DIME) signals when a given operation using a Session ID goes
active.
8. Acknowledgements
Thanks to Stuart Card (AX Enterprize, LLC) and Bob Moskowitz (HTT Optimally this requires that the UAS somehow signal to the DIME that
Consulting, LLC) for their early work on the DRIP registries concept. a flight using a Specific Session ID will soon be underway or
Their early contributions laid the foundations for the content and complete. It may also be facilitated under UTM if the USS (which may
processes of this architecture and document. or may not be a DIME) signals when a given operation using a Session
ID goes active.
9. References 8. References
9.1. Normative References 8.1. Normative References
[F3411] ASTM International, "Standard Specification for Remote ID [F3411] ASTM International, "Standard Specification for Remote ID
and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July
2022, <https://www.astm.org/f3411-22a.html>. 2022, <https://www.astm.org/f3411-22a.html>.
[ISO3166-1] [ISO3166-1]
International Standards Organization (ISO), "Codes for the ISO, "Codes for the representation of names of countries
representation of names of countries and their and their subdivisions - Part 1: Country code",
subdivisions", ISO 3166-1:2020, August 2020, ISO 3166-1:2020, August 2020,
<https://www.iso.org/iso-3166-country-codes.html>. <https://www.iso.org/iso-3166-country-codes.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
[RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, [RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
"DRIP Entity Tag (DET) for Unmanned Aircraft System Remote "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023, ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
<https://www.rfc-editor.org/rfc/rfc9374>. <https://www.rfc-editor.org/info/rfc9374>.
9.2. Informative References 8.2. Informative References
[BCP237] Best Current Practice 237, [BCP237] Best Current Practice 237,
<https://www.rfc-editor.org/info/bcp237>. <https://www.rfc-editor.org/info/bcp237>.
At the time of writing, this BCP comprises the following: At the time of writing, this BCP comprises the following:
Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023, RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>. <https://www.rfc-editor.org/info/rfc9364>.
[drip-dki] Moskowitz, R. and S. W. Card, "The DRIP DET public Key [drip-dki] Moskowitz, R. and S. W. Card, "The DRIP DET public Key
Infrastructure", Work in Progress, Internet-Draft, draft- Infrastructure", Work in Progress, Internet-Draft, draft-
ietf-drip-dki-08, 22 April 2025, ietf-drip-dki-09, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-drip- <https://datatracker.ietf.org/doc/html/draft-ietf-drip-
dki-08>. dki-09>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A
Framework for DNSSEC Policies and DNSSEC Practice Framework for DNSSEC Policies and DNSSEC Practice
Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013, Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013,
<https://www.rfc-editor.org/rfc/rfc6841>. <https://www.rfc-editor.org/info/rfc6841>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/rfc/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A. [RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A.
Gurtov, "Drone Remote Identification Protocol (DRIP) Gurtov, "Drone Remote Identification Protocol (DRIP)
Requirements and Terminology", RFC 9153, Requirements and Terminology", RFC 9153,
DOI 10.17487/RFC9153, February 2022, DOI 10.17487/RFC9153, February 2022,
<https://www.rfc-editor.org/rfc/rfc9153>. <https://www.rfc-editor.org/info/rfc9153>.
[RFC9434] Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed., [RFC9434] Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed.,
and A. Gurtov, "Drone Remote Identification Protocol and A. Gurtov, "Drone Remote Identification Protocol
(DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July (DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July
2023, <https://www.rfc-editor.org/rfc/rfc9434>. 2023, <https://www.rfc-editor.org/info/rfc9434>.
[RFC9575] Wiethuechter, A., Ed., Card, S., and R. Moskowitz, "DRIP [RFC9575] Wiethuechter, A., Ed., Card, S., and R. Moskowitz, "DRIP
Entity Tag (DET) Authentication Formats and Protocols for Entity Tag (DET) Authentication Formats and Protocols for
Broadcast Remote Identification (RID)", RFC 9575, Broadcast Remote Identification (RID)", RFC 9575,
DOI 10.17487/RFC9575, June 2024, DOI 10.17487/RFC9575, June 2024,
<https://www.rfc-editor.org/rfc/rfc9575>. <https://www.rfc-editor.org/info/rfc9575>.
[STD13] Internet Standard 13, [STD13] Internet Standard 13,
<https://www.rfc-editor.org/info/std13>. <https://www.rfc-editor.org/info/std13>.
At the time of writing, this STD comprises the following: At the time of writing, this STD comprises the following:
Mockapetris, P., "Domain names - concepts and facilities", Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
Mockapetris, P., "Domain names - implementation and Mockapetris, P., "Domain names - implementation and
skipping to change at page 23, line 25 skipping to change at line 1008
Hollenbeck, S. and A. Newton, "JSON Responses for the Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95, Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021, RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/info/rfc9083>. <https://www.rfc-editor.org/info/rfc9083>.
Blanchet, M., "Finding the Authoritative Registration Data Blanchet, M., "Finding the Authoritative Registration Data
Access Protocol (RDAP) Service", STD 95, RFC 9224, Access Protocol (RDAP) Service", STD 95, RFC 9224,
DOI 10.17487/RFC9224, March 2022, DOI 10.17487/RFC9224, March 2022,
<https://www.rfc-editor.org/info/rfc9224>. <https://www.rfc-editor.org/info/rfc9224>.
Appendix A. Example Zone Files & RRType Contents Appendix A. Example Zone Files and RRType Contents
An example zone file ip6.arpa., run by IANA, is not shown. It would An example zone file ip6.arpa., run by IANA, is not shown. It would
contain NS RRTypes to delegate to a respective RAA. To avoid any contain NS RRTypes to delegate to a respective RAA. To avoid any
future collisions with production deployments an apex of future collisions with production deployments an apex of
ip6.example.com. is used instead of ip6.arpa.. All hexadecimal ip6.example.com. is used instead of ip6.arpa.. All hexadecimal
strings in the examples are broken into the lengths of a word, for strings in the examples are broken into the lengths of a word, for
document formatting purposes. document formatting purposes.
An RAA with a HID of RAA=16376, HDA=0 and HDA with a the HID An RAA with a HID of RAA=16376, HDA=0 and HDA with a the HID
RAA=16376, HDA=10 were used in the examples. RAA=16376, HDA=10 were used in the examples.
skipping to change at page 25, line 50 skipping to change at line 1119
A.1.2. Delegation of HDA A.1.2. Delegation of HDA
$ORIGIN c.d.f.f.3.0.0.1.0.0.2.ip6.example.com. $ORIGIN c.d.f.f.3.0.0.1.0.0.2.ip6.example.com.
a.0.0. IN NS ns1.hda-10.example.com a.0.0. IN NS ns1.hda-10.example.com
Figure 12: HDA Delegation Example Figure 12: HDA Delegation Example
A.2. Example HDA A.2. Example HDA
A.2.1. Authentication & Issue HHITs A.2.1. Authentication and Issue HHITs
$ORIGIN 5.0.a.0.0.0.e.f.f.3.0.0.1.0.0.2.ip6.example.com. $ORIGIN 5.0.a.0.0.0.e.f.f.3.0.0.1.0.0.2.ip6.example.com.
0.a.9.0.7.2.4.d.5.4.e.e.5.1.6.6.5.0. IN HHIT ( 0.a.9.0.7.2.4.d.5.4.e.e.5.1.6.6.5.0. IN HHIT (
gw5pM2ZmOCAwMDBhWQFHMIIBQzCB9qAD gw5pM2ZmOCAwMDBhWQFHMIIBQzCB9qAD
AgECAgFfMAUGAytlcDArMSkwJwYDVQQD AgECAgFfMAUGAytlcDArMSkwJwYDVQQD
DCAyMDAxMDAzZmZlMDAwMDA1NWU2MGEx DCAyMDAxMDAzZmZlMDAwMDA1NWU2MGEx
NTcxZTkxYTBiNzAeFw0yNTA0MDkyMTAz NTcxZTkxYTBiNzAeFw0yNTA0MDkyMTAz
MTlaFw0yNTA0MDkyMjAzMTlaMB4xHDAa MTlaFw0yNTA0MDkyMjAzMTlaMB4xHDAa
BgNVBAMME0RSSVAtSERBLUEtMTYzNzYt BgNVBAMME0RSSVAtSERBLUEtMTYzNzYt
MTAwKjAFBgMrZXADIQDOaB424RQa61YN MTAwKjAFBgMrZXADIQDOaB424RQa61YN
bna8eWt7fLRU5GPMsfEt4wo4AQGAP6NM bna8eWt7fLRU5GPMsfEt4wo4AQGAP6NM
skipping to change at page 30, line 37 skipping to change at line 1289
URI:https://hda.example.com URI:https://hda.example.com
Signature Algorithm: ED25519 Signature Algorithm: ED25519
Signature Value: Signature Value:
5a:f2:56:72:7e:dc:47:26:a0:c5:56:0b:f8:46:df:9c:31:49: 5a:f2:56:72:7e:dc:47:26:a0:c5:56:0b:f8:46:df:9c:31:49:
9c:f1:a4:30:7a:de:14:65:d3:b7:c9:03:81:f6:ea:b8:b0:b5: 9c:f1:a4:30:7a:de:14:65:d3:b7:c9:03:81:f6:ea:b8:b0:b5:
40:49:c6:99:09:68:c2:d2:79:9e:46:48:15:46:18:b3:7b:57: 40:49:c6:99:09:68:c2:d2:79:9e:46:48:15:46:18:b3:7b:57:
ac:7f:28:b7:45:15:38:e0:80:04 ac:7f:28:b7:45:15:38:e0:80:04
Figure 17: 2001:3f:fe00:a05:260e:d437:6b25:6e28 Decoded Certificate Figure 17: 2001:3f:fe00:a05:260e:d437:6b25:6e28 Decoded Certificate
A.2.2. Registratant HHIT & BRID A.2.2. Registratant HHIT and BRID
$ORIGIN 5.0.a.0.0.0.e.f.f.3.0.0.1.0.0.2.ip6.example.com. $ORIGIN 5.0.a.0.0.0.e.f.f.3.0.0.1.0.0.2.ip6.example.com.
2.b.6.c.b.4.a.9.9.6.4.2.8.0.3.1. IN HHIT ( 2.b.6.c.b.4.a.9.9.6.4.2.8.0.3.1. IN HHIT (
gxJpM2ZmOCAwMDBhWQEYMIIBFDCBx6AD gxJpM2ZmOCAwMDBhWQEYMIIBFDCBx6AD
AgECAgFUMAUGAytlcDArMSkwJwYDVQQD AgECAgFUMAUGAytlcDArMSkwJwYDVQQD
DCAyMDAxMDAzZmZlMDAwYTA1MjYwZWQ0 DCAyMDAxMDAzZmZlMDAwYTA1MjYwZWQ0
Mzc2YjI1NmUyODAeFw0yNTA0MDkyMTEz Mzc2YjI1NmUyODAeFw0yNTA0MDkyMTEz
MDBaFw0yNTA0MDkyMjEzMDBaMAAwKjAF MDBaFw0yNTA0MDkyMjEzMDBaMAAwKjAF
BgMrZXADIQDJLi+dl+iWD5tfFlT4sJA5 BgMrZXADIQDJLi+dl+iWD5tfFlT4sJA5
+drcW88GHqxPDOp56Oh3+qM7MDkwNwYD +drcW88GHqxPDOp56Oh3+qM7MDkwNwYD
VR0RAQH/BC0wK4cQIAEAP/4ACgUTCCRp VR0RAQH/BC0wK4cQIAEAP/4ACgUTCCRp
skipping to change at page 35, line 4 skipping to change at line 1446
05130824699A4BC6B2C92E2F9D97E8960F 05130824699A4BC6B2C92E2F9D97E8960F
9B5F1654F8B09039F9DADC5BCF061EAC4F 9B5F1654F8B09039F9DADC5BCF061EAC4F
0CEA79E8E877FA2001003FFE000A05260E 0CEA79E8E877FA2001003FFE000A05260E
D4376B256E2880E7DCF234E29982E64CE3 D4376B256E2880E7DCF234E29982E64CE3
B2159A14C768CE3B0B41D639EA509AFA6D B2159A14C768CE3B0B41D639EA509AFA6D
86B03283EB4773252860465AC573D725CD 86B03283EB4773252860465AC573D725CD
A94511A02A98770B187BAD6F7798BA609A A94511A02A98770B187BAD6F7798BA609A
A701' A701'
] ]
} }
Figure 21: 2001:3f:fe00:a05:1308:2469:9a4b:c6b2 Decoded BRID Figure 21: 2001:3f:fe00:a05:1308:2469:9a4b:c6b2 Decoded BRID
RRType CBOR RRType CBOR
Acknowledgements
Thanks to Stuart Card (AX Enterprize, LLC) and Bob Moskowitz (HTT
Consulting, LLC) for their early work on the DRIP registries concept.
Their early contributions laid the foundation for the content and
processes of this architecture and document.
Authors' Addresses Authors' Addresses
Adam Wiethuechter (editor) Adam Wiethuechter (editor)
AX Enterprize, LLC AX Enterprize, LLC
4947 Commercial Drive 4947 Commercial Drive
Yorkville, NY 13495 Yorkville, NY 13495
United States of America United States of America
Email: adam.wiethuechter@axenterprize.com Email: adam.wiethuechter@axenterprize.com
Jim Reid Jim Reid
 End of changes. 110 change blocks. 
248 lines changed or deleted 248 lines changed or added

This html diff was produced by rfcdiff 1.48.