]> AX Enterprize, LLC

4947 Commercial Drive Yorkville NY 13495 USA adam.wiethuechter@axenterprize.com

RTFM llp

St Andrews House 382 Hillington Road, Glasgow Scotland G51 4BL UK jim@rfc1035.com

Internet drip Working Group Internet-Draft This document describes the discovery and management of DRIP Entity Tags (DETs) in DNS. Authoritative Name Servers, with DRIP specific DNS structures and standard DNS methods, are the Public Information Registries for DETs and their related metadata.

Introduction Registries are fundamental to Unmanned Aircraft System (UAS) Remote Identification (RID). Only very limited operational information can be sent via Broadcast RID, but extended information is sometimes needed. The most essential element of information from RID is the UAS ID, the unique key for lookup of extended information in relevant registries (see ; Figure 4 of ).

Global UAS RID Usage Scenario (Figure 4 of RFC9434)

When a DRIP Entity Tag (DET) is used as the UAS ID in RID, extended information can be retrieved from a DRIP Identity Management Entity (DIME), which manages registration of and associated lookups from DETs. In this document it is assumed the DIME is a function of UAS Service Suppliers (USS) (Appendix A.2 of ) but a DIME can be independent or handled by another entity as well.

General Concept DRIP Entity Tags (DETs) embed a hierarchy scheme which is mapped onto the Domain Name System (DNS) . DIMEs enforce registration and information access of data associated with a DET while also providing the trust inherited from being a member of the hierarchy. Other identifiers and their methods are out of scope for this document. Authoritative Name Servers of the DNS provide the public information such as the cryptographic keys, endorsements and certificates of DETs and pointers to private information resources. Cryptographic (public) keys are used to authenticate anything signed by a DET, such as in the Authentication defined in for Broadcast RID. Endorsements and certificates are used to endorse the claim of being part of the hierarchy. This document does not specify AAA mechanisms used by Private Information Registries to store and protect Personally Identifiable Information (PII).

Scope 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 for DETs 2001:30::/28 and RRsets used to handle DETs.

Terminology

Required Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Additional Definitions This document makes use of the terms/abbreviations (USS, etc.) defined in . Other terms/abbreviations (DIME, Endorsement, etc.) are from , while others (RAA, HDA, etc.) are from .

DET Hierarchy in DNS defines the HHIT and further specifies an instance of them used for UAS RID called DETs. The HHIT/DET is a 128-bit value that is as an IPv6 address intended primarily as an identifier rather than locator. Its format is in , shown here for reference, and further information is in .

DRIP Entity Tag Breakdown

assigns the IPv6 prefix 2001:30::/28 for DETs. Its corresponding domain name for reverse lookups is 3.0.0.1.0.0.2.ip6.arpa.. The IAB has administrative control of this domain name. Due to the nature of the hierarchy split and its relationship to nibble reversing of the IPv6 address, the upper level of hierarchy (i.e., Registered Assigning Authority (RAA)) "borrows" the upper two bits of their respective HHIT Domain Authority (HDA) space for DNS delegation. As such the IPv6 prefix of RAAs are 2001:3x:xxx0::/44 and HDAs are 2001:3x:xxxy:yy00::/56 with respective nibble reverse domains of 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 Numeric Nation Code . This is to support the initial use case of DETs in UAS RID on an international level. See for the RAA allocations. The HDA values of 0, 4096, 8192 and 12288 are reserved for operational use of an RAA (a by-product of the above mentioned borrowing of bits), specifically when to register with the apex and endorse delegations of HDAs in their namespace. The administration, management and policy for the operation of a DIME at any level in the hierarchy (Apex, RAA or HDA) is out of scope for this document. For RAAs or DETs allocated on a per-country basis, these considerations should be be determined by the appropriate national authorities, presumably the Civil Aviation Authority (CAA).

Use of Existing DNS Models DRIP relies on the DNS and as such roughly follows the registrant-registrar-registry model. In the UAS ecosystem, the registrant would be the end user who owns/controls the Unmanned Aircraft. They are ultimately responsible for the DET and any other information that gets published in the DNS. Registrants use agents known as registrars to manage their interactions with the registry. Registrars typically provide optional additional services such as DNS hosting. The registry maintains a database of the registered domain names and their related metadata such as the contact details for domain name holder and the relevant registrar. The registry provides DNS service for the zone apex which contains delegation information for domain names. Registries generally provide services such as WHOIS or RDAP to publish metadata about the registered domain names and their registrants and registrars. Registrants have contracts with registrars who in turn have contracts with registries. Payments follow this model too: the registrant buys services from a registrar who pays for services provided by the registry. By definition, there can only be one registry for a domain name. Since that registry is a de facto monopoly, the scope of its activities is usually kept to a minimum to reduce the potential for market distortions or anti-competitive practices. A registry can have an arbitrary number of registrars who compete with each other on price, service and customer support.

DNS Model Considerations for DIMEs

Example DRIP DNS Model

While the registrant-registrar-registry model is mature and well understood, it may not be appropriate for DRIP registrations in some circumstances. It could add costs and complexity; developing policies and contracts as outlined above. On the other hand, registries and registrars offer customer service/support and can provide the supporting infrastructure for reliable DNS and WHOIS or RDAP service. Another approach could be to handle DRIP registrations in a comparable way to how IP address space gets provisioned. Here, blocks of addresses get delegated to a "trusted" third party, typically an ISP, who then issues IP addresses to its customers. For 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 ) to an entity chosen by the appropriate Civil Aviation Authority (CAA). This third party would be responsible for the corresponding DNS and WHOIS or RDAP infrastructure for these IP address blocks. They would also provision the Hierarchical Host Identity Tag (HHIT, ) records for these IP addresses. In principle a manufacturer or vendor of UAS devices could provide that role. This is shown as an example in . Dynamic DRIP registration is another possible solution, for example when the operator of a UAS device registers its corresponding HHIT record and other resources before a flight and deletes them afterwards. This may be feasible in controlled environments with well-behaved actors. However, this approach may not scale since each device is likely to need credentials for updating the IT infrastructure which provisions the DNS. Registration policies (pricing, renewals, registrar and registrant agreements, etc.) will need to be developed. These considerations should be determined by the CAA, perhaps in consultation with local stakeholders to assess the cost-benefits of these approaches (and 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 document.

Public Information Registry Per all information classified as public is stored in the DNS, specifically Authoritative Name Servers, to satisfy REG-1 from . Authoritative Name Servers use domain names as identifiers and data is stored in Resource Records (RR) with associated RRTypes. This document defines two new RRTypes, one for HHIT metadata (HHIT, ) and another for UAS Broadcast RID information (BRID, ). The former RRType is particularly important as it contains a URI (as part of the certificate) that points to Private Information resources. DETs, being IPv6 addresses, are to be under ip6.arpa. (nibble reversed per convention) and MUST resolve to an HHIT RRType. Depending on local circumstances or additional use cases other RRTypes MAY be present. For UAS RID the BRID RRType MUST be present to provide the Broadcast Endorsements defined in . DNSSEC is strongly RECOMMENDED. When a DIME decides to use DNSSEC they SHOULD define a framework for cryptographic algorithms and key management . This may be influenced by frequency of updates, size of the zone, and policies. UAS specific information, such as physical characteristics, MAY also be stored in DNS but is out of scope for this document. A DET IPv6 address gets mapped into domain names using the scheme defined in . However DNS lookups of these names query for HHIT and/or BRID resource records rather than the PTR resource records conventionally used in reverse lookups of IP 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 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.arpa.. The HHIT RRType provides the public key for signature verification and URIs via the certificate. The BRID RRType provides static Broadcast RID information such as the Broadcast Endorsements sent following .

Resource Records

HHIT Resource Record The HHIT Resource Record (RR) is a metadata record for various bits of HHIT specific information that isn't available in the pre-existing HIP RRType. The HHIT RRType does not replace the HIP RRType. The primary advantage of the HHIT RRType over the existing RRType is the mandatory inclusion of a certificate containing an entity's public key signed by the registrar, or other trust anchor, to confirm registration. The data MUST be encoded in CBOR bytes. The CDDL of the data is provided in .

Text Representation The data are represented in base64 and may be divided into any number of white-space-separated substrings, down to single base64 digits, which are concatenated to obtain the full object. These substrings can span lines using the standard parenthesis. Note that the data has internal subfields but these do not appear in the master file representation; only a single logical base64 string will appear.

Presentation Representation The data MAY, for display purposes only, be represented using the Extended Diagnostic Notation as defined in Appendix G of .

Field Descriptions

HHIT Wire Format CDDL

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 defined in . It is envisioned that there may be many types of HHITs in use. In some cases, it may be helpful to understand the HHITs role in the ecosystem like described in . This field provides such context. This field MAY provide a signal of additional information and/or different handling of the data beyond what is defined in this document.

HID Abbreviation:

The HID Abbreviation field is a string that provides an abbreviation to the HID structure of a DET for display devices. The convention for such abbreviations is a matter of local policy. Absent of such a policy, this field MUST be filled with the four character hexadecimal representations of the RAA and HDA (in that order) with a separator character such as a space. For example, a DET with an RAA value of 10 and HDA value of 20 would be abbreviated as: 000A 0014.

Canonical Registration Certificate:

The Canonical Registration Certificate field is for a certificate endorsing registration of the DET. It MUST be encoded as X.509 DER . This 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 policy, such as in , and is out of scope for this document.

UAS Broadcast RID Resource Record The UAS Broadcast RID Resource Record type (BRID) is a format to hold public information typically sent of the UAS Broadcast RID that is static. It can act as a data source if information is not received over Broadcast RID or for cross validation. The primary function for DRIP is the inclusion of one or more Broadcast Endorsements as defined in in the auth field. These Endorsements are generated by the registrar upon successful registration and broadcast by the entity. The data MUST be encoded in CBOR bytes. The CDDL of the data is provided in .

Text Representation The data are represented in base64 and may be divided into any number of white-space-separated substrings, down to single base64 digits, which are concatenated to obtain the full object. These substrings can span lines using the standard parenthesis. Note that the data has internal subfields but these do not appear in the master file representation; only a single logical base64 string will appear.

Presentation Representation The data MAY, for display purposes only, be represented using the Extended Diagnostic Notation as defined in Appendix G of . All byte strings longer than a length of 20 SHOULD be displayed as base64 when possible.

Field Descriptions

BRID Wire Format CDDL nibble-field, uas_ids => [+ uas-id-grp], ? auth => [+ auth-grp], ? self_id => self-grp, ? area => area-grp, ? classification => classification-grp, ? operator_id => operator-grp } uas-id-grp = [ id_type: &uas-id-types, uas_id: bstr .size(20) ] auth-grp = [ a_type: &auth-types, a_data: bstr .size(1..362) ] area-grp = [ area_count: 1..255, area_radius: float, # in decameters area_floor: float, # wgs84-hae in meters area_ceiling: float # wgs84-hae in meters ] classification-grp = [ class_type: 0..8, class: nibble-field, category: nibble-field ] self-grp = [ desc_type: 0..255, description: tstr .size(23) ] operator-grp = [ operator_id_type: 0..255, operator_id: bstr .size(20) ] uas-id-types = (none: 0, serial: 1, session_id: 4) auth-types = (none: 0, specific_method: 5) nibble-field = 0..15 uas_type = 0 uas_ids = 1 auth = 2 self_id = 3 area = 4 classification = 5 operator_id = 6 ]]>

The field names and their general typing are borrowed from the ASTM data dictionary (Table 1 and Table 2). See that document for additional context and background information on aviation application-specific interpretation of the field semantics. The explicitly enumerated values included in the CDDL above are relevant to DRIP for its operation. Other values may be valid but are outside the scope of DRIP operation. Application-specific fields, such as UAS Type are transported and authenticated by DRIP but are regarded as opaque user data to DRIP.

IANA Considerations

DET Prefix Delegation This document requests that IANA manage delegations in the 3.0.0.1.0.0.2.ip6.arpa. domain. The IAB is requested to appoint a Designated Expert (DE) to coordinate these delegations and liaise with IANA and CAAs as appropriate. The DE will check delegation requests for DET address space that get submitted to IANA. Since there is no control over who submits these delegation requests or the address space they refer to, a degree of checking is necessary. The DE will liaise with IANA on the outcome of these checks. For delegation requests relating to a country’s DET address space, the DE will liaise with that country’s CAA to verify these requests are genuine. This will ensure delegations don’t go to impostors and the CAA is aware about what’s being done with its National Resources, ie the IPv6 addresses for its DET address space. Parts of the DET address space are allocated for experimental use. The DE is expected to process these delegation requests on a first-come, first-served basis. They would not need engagement with ICAO or CAAs. The DE will have the discretion to perform minimal technical checks on delegations - for instance that there are at least two name servers that answer authoritatively, SPoF avoidance, etc - but not enforce these. The DE will be expected to liaise with IANA to develop a DNSSEC Practice Statement if/when there’s a demand for DNSSEC deployment for DRIP.

IANA DRIP Registry

DRIP RAA Allocations This document requests a new registry for RAA Allocations under the DRIP registry group to be managed by IANA.

RAA Allocations:

a 14-bit value used to represent RAAs. Future additions to this registry are to be made through Expert Review (Section 4.5 of ). The following values/ranges are defined:

RAA Value(s)	Allocation	Reference
0 - 3	Reserved	N/A
4 - 3999	ISO 3166-1 Countries	This RFC
4000 - 15359	Unallocated	N/A
15360 - 16383	Experimental Use	This RFC

To support DNS delegation in ip6.arpa. a single RAA is given 4 delegations by borrowing the upper two bits of HDA space (see for an example). This enables a clean nibble boundary in DNS to delegate from (i.e., the prefix 2001:3x:xxx0::/44). These HDAs (0, 4096, 8192 and 12288) are reserved for the RAA.

Example Bit Borrowing of RAA=16376

The mapping between ISO 3166-1 Numeric Nation Codes and RAAs is specified as a CSV file on GitHub. Each Nation is assigned four 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 delegated to each CAA, which covers all 4 RAAs (and reserved HDAs) assigned to them.

Expert Guidance A request for a value and/or range is judged on the specific application of its use (i.e., like the ISO 3166 range for UAS). Common applications should reuse existing allocated space if possible before allocation of a new value/range. Single point allocations are allowed to individual entities but it is recommended that allocations are made in groupings of 4 to maintain a cleaner nibble boundary.

Registration Form For registration the following template is to be used:

• Allocation Title.
• Contact Information: contact point such as email or person operating allocation.
• Reference: public document reference for allocation, containing required information to register for HDAs under it.

HHIT Entity Type This document requests a new registry for HHIT Entity Type under the DRIP registry group.

HHIT Entity Type:

numeric, field of the HHIT RRType to encode the HHIT Entity Type. This is broken into three ranges and future additions to this registry are as follows:

Range	Registration Mechanism
0 - 4294967295	Expert Review (Section 4.5 of )
4294967296 - 18446744069414584319	First Come First Served (Section 4.4 of )
18446744069414584320 - 18446744073709551615	Experimental Use

The following values are defined by this document:

Value	HHIT Type	Reference
0	Not Defined	This RFC
1	DRIP Identity Management Entity (DIME)	This RFC
2 - 4	Reserved	This RFC
5	Apex	This RFC
6 - 8	Reserved	This RFC
9	Registered Assigning Authority (RAA)	This RFC
10 - 12	Reserved	This RFC
13	HHIT Domain Authority (HDA)	This RFC
14 - 15	Reserved	This RFC
16	Uncrewed Aircraft (UA)	This RFC
17	Ground Control Station (GCS)	This RFC
18	Uncrewed Aircraft System (UAS)	This RFC
19	Remote Identification (RID) Module	This RFC
20	Pilot	This RFC
21	Operator	This RFC
22	Discovery & Synchronization Service (DSS)	This RFC
23	UAS Service Supplier (USS)	This RFC
24	Network RID Service Provider (SP)	This RFC
25	Network RID Display Provider (DP)	This RFC
26	Supplemental Data Service Provider (SDSP)	This RFC

Expert Guidance Justification should be provided if there is an existing allocation that could be used. Future additions to this registry MUST NOT be allowed if they can be covered under an existing registration.

Registration Template For registration the following template is to be used:

• HHIT Type: title (and optional abbreviation) to be used for the requested value.
• Reference: public document allocating the value and any additional information such as semantics. This can be a URL pointing to an Internet-Draft, IETF RFC, or web-page.

For registration in the FCFS range, a point of contact MUST also be provided (if not part of the reference).

Security Considerations

DNS Operational & Registration Considerations The Registrar and Registry are commonly used concepts in the DNS. These components interface the DIME into the DNS hierarchy and thus operation SHOULD follow best common practices, specifically in security (such as running DNSSEC) as appropriate. The following RFC provide suitable guidance: , , , , , , , , . If DNSSEC is used, a DNSSEC Practice Statement SHOULD be developed and published. It SHOULD explain how DNSSEC has been deployed and what security measures are in place. documents a Framework for DNSSEC Policies and DNSSEC Practice Statements. A self-signed entity (i.e. an entity that self-signed it certificate as part of the HHIT RRType) MUST use DNSSEC. The interfaces and protocol specifications for registry-registrar interactions are intentionally not specified in this document. These will depend on nationally defined policy and prevailing local circumstances. It is expected registry-registrar activity will use the Extensible Provisioning Protocol (EPP) . The registry SHOULD provide a lookup service such as WHOIS or RDAP to publish public information about registered domain names. Decisions about DNS or registry best practices and other operational matters that influence security SHOULD be made by the CAA, ideally in consultation with local stakeholders. The guidance above is intended to reduce the likelihood of interoperability problems and minimize security and stability concerns. For instance, validation and authentication of DNS responses depends on DNSSEC. If this is not used, entities using DRIP will be vulnerable to DNS spoofing attacks and could be exposed to bogus data. Some regulatory and legal considerations are expected to be simplified by providing a lookup service for access to public information about registered domain names for DETs. When DNSSEC is not in use, clients MUST "walk" the tree of certificates, locating each certificate by performing DNS lookups of HHIT RRTypes for each DET, which endorse each DETs inclusion into the hierarchy. The collection of these certificates (which provide both signature protection from the parent entity and the public key of the entity) is the only way without DNSSEC to prove valid registration. The data within the BRID RRType has no direct endorsement when not protected by DNSSEC. The contents of the BRID RRType auth key, containing the Endorsements, SHOULD be validated, similiar to the certificates mentioned previously.

DET & Public Key Exposure DETs are built upon asymmetric keys. As such the public key must be revealed to enable clients to perform signature verifications. security considerations cover various attacks on such keys. While unlikely, the forging of a corresponding private key is possible if given enough time (and computational power). When practical, it is RECOMMENDED that no RRTypes under a DET's specific domain name be published unless and until it is required for 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 from being exposed before its needed. The combination of this "just in time" publishing mechanism and DNSSEC is out of scope 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.

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 foundations for the content and processes of this architecture and document.

References Normative References This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses, which makes them trustable identifiers for use in Unmanned Aircraft System Remote Identification (UAS RID) and tracking. Within the context of RID, HHITs will be called DRIP Entity Tags (DETs). HHITs provide claims to the included explicit hierarchy that provides registry (via, for example, DNS, RDAP) discovery for third-party identifier endorsement. This document updates RFCs 7401 and 7343. ASTM International International Standards Organization (ISO) In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References HTT Consulting AX Enterprize, LLC The DRIP Entity Tag (DET) public Key Infrastructure (DKI) is a specific variant of classic Public Key Infrastructures (PKI) where the organization is around the DET, in place of X.520 Distinguished Names. Further, the DKI uses DRIP Endorsements in place of X.509 certificates for establishing trust within the DKI. There are two X.509 profiles for shadow PKI behind the DKI, with many of their X.509 fields mirroring content in the DRIP Endorsements. These PKIs can at times be used where X.509 is expected and non- constrained communication links are available that can handle their larger size. It is recommended that a DRIP deployment implement both of these along side the Endorsement trees. C509 (CBOR) encoding of all X.509 certificates are also provided as an alternative for where there are gains in reduced object size. This document presents a framework to assist writers of DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone with Security Extensions implemented. In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. This document is not an Internet Standards Track specification; it is published for informational purposes. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document defines terminology and requirements for solutions produced by the Drone Remote Identification Protocol (DRIP) Working Group. These solutions will support Unmanned Aircraft System Remote Identification and tracking (UAS RID) for security, safety, and other purposes (e.g., initiation of identity-based network sessions supporting UAS applications). DRIP will facilitate use of existing Internet resources to support RID and to enable enhanced related services, and it will enable online and offline verification that RID information is trustworthy. This document describes an architecture for protocols and services to support Unmanned Aircraft System Remote Identification and tracking (UAS RID), plus UAS-RID-related communications. This architecture adheres to the requirements listed in the Drone Remote Identification Protocol (DRIP) Requirements document (RFC 9153). The Drone Remote Identification Protocol (DRIP), plus trust policies and periodic access to registries, augments Unmanned Aircraft System (UAS) Remote Identification (RID), enabling local real-time assessment of trustworthiness of received RID messages and observed UAS, even by Observers lacking Internet access. This document defines DRIP message types and formats to be sent in Broadcast RID Authentication Messages to verify that attached and recently detached messages were signed by the registered owner of the DRIP Entity Tag (DET) claimed. This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK] This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document obsoletes RFC 4931. [STANDARDS-TRACK] This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. This document obsoletes RFC 4932. [STANDARDS-TRACK] This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 4933. [STANDARDS-TRACK] This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 4934. [STANDARDS-TRACK] This document is one of a collection that together describes the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application. The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from Domain Name and Regional Internet Registries. This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for RDAP. This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP). This document obsoletes RFC 7482. This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483. This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers. This document obsoletes RFC 7484. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK] This document describes a protocol for transaction-level authentication using shared secrets and one-way hashing. It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client or to authenticate responses as coming from an approved name server. No recommendation is made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out-of-band mechanism. This document obsoletes RFCs 2845 and 4635. This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. [STANDARDS-TRACK] This document discusses the selection of secondary servers for DNS zones.The number of servers appropriate for a zone is also discussed, and some general secondary server maintenance issues considered. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. The DNS root name service is a critical part of the Internet architecture. The protocol and deployment requirements for the DNS root name service are defined in this document. Operational requirements are out of scope. This document updates the specification of the WHOIS protocol, thereby obsoleting RFC 954. The update is intended to remove the material from RFC 954 that does not have to do with the on-the-wire protocol, and is no longer applicable in today's Internet. This document does not attempt to change or update the protocol per se, or document other uses of the protocol that have come into existence since the publication of RFC 954. [STANDARDS-TRACK] As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely. Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]

Example Zone Files & RRType Contents 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 future collisions with production deployments an apex of ip6.example.com. is used instead of ip6.arpa.. All hexadecimal strings in the examples are broken into the lengths of a word, for document formatting purposes. The RAA of RAA=16376, HDA=0 and HDA of RAA=16376, HDA=10 were used in the examples.

Example RAA

Authentication HHIT

RAA Auth HHIT RRType Example

7.b.0.a.1.9.e.1.7.5.1.a.0.6.e.5. Decoded HHIT RRType CBOR and Certificate

Delegation of HDA

HDA Delegation Example

Example HDA

Authentication & Issue HHITs

HDA Auth/Issue HHIT RRType Example

0.a.9.0.7.2.4.d.5.4.e.e.5.1.6.6.5.0. Decoded Auth HHIT RRType CBOR and Certificate

8.2.e.6.5.2.b.6.7.3.4.d.e.0.6.2.5.0. Decoded Issue HHIT RRType CBOR and Certificate

Registratant HHIT & BRID

Registrant HHIT/BRID RRType Example

2.b.6.c.b.4.a.9.9.6.4.2.8.0.3.1. Decoded HHIT RRType CBOR and Certificate

2.b.6.c.b.4.a.9.9.6.4.2.8.0.3.1. Decoded BRID RRType CBOR