DART: Domain-Aware Routing Technology Protocol

5.1. Header Structure

The DART packet header is structured as follows:¶

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Version    |     Proto     |    DstLen     |    SrcLen     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                Destination FQDN-ID (variable length)          ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                   Source FQDN-ID (variable length)            ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Version (8 bits)
  Indicates the version of the DART protocol. The current version is 1. Future versions may be used to extend the field structure or introduce new addressing mechanisms.¶

• Proto (8 bits)
  Specifies the upper-layer protocol type, using the same values as the IP protocol field (e.g., 6 for TCP, 17 for UDP, 1 for ICMP). When encapsulating a packet in DART, the Protocol field in the outer IP header should be adjusted accordingly (e.g., set to "UDP", with the UDP destination port set to 0xDA27), and the original protocol number should be copied into this field.¶

• DstLen (8 bits)
  Length of the Destination FQDN-ID, in bytes.¶

• SrcLen (8 bits)
  Length of the Source FQDN-ID, in bytes.¶

• Destination FQDN-ID (variable length)
  The Fully Qualified Domain Name of the destination host, e.g., dart-host.example.com. It serves as the primary routing identifier of the DART packet, and the receiver must be able to correctly parse its semantic structure.¶

• Source FQDN-ID (variable length)
  The Fully Qualified Domain Name of the source host. This field can be used for reverse routing of response paths, policy control, and other purposes.
  If the length of the Source FQDN-ID field is zero, it indicates that the packet is anonymous or unidirectional. In this case, the receiver should not expect a source identifier and should not generate a response to this packet. This design is suitable for unidirectional notifications, broadcast or multicast packets, and privacy-protecting communication scenarios where the sender does not wish to reveal its identity.¶

5.2. Encoding and Alignment

• All fields are encoded in network byte order (big-endian);¶

• FQDN-ID fields are represented in UTF-8 encoding, not null-terminated and not aligned to fixed boundaries;¶

• During decapsulation, the positions of the FQDN fields must be determined precisely based on the values of DstLen and SrcLen.¶

5.3. Header Insertion Position

DART packets are not defined as native IP-layer protocols. Instead, they are encapsulated within the payload of UDP datagrams. A fixed UDP destination port (recommended: 55847 / 0xDA27) is used to distinguish DART packets and facilitate their processing. The encapsulation stack is illustrated as follows:¶

Encapsulation Details:¶

• UDP Source Port: May be dynamically allocated (e.g., for session tracking);¶

• UDP Destination Port: Recommended to be statically set to 55847 (decimal), indicating a DART payload;¶

• UDP Length: Covers both the DART header and upper-layer protocol data;¶

• UDP Checksum: Optional, but recommended for integrity checking.¶

NAT Compatibility:¶

Since DART packets appear as regular UDP traffic on the wire, they inherit the following advantages:¶

• Full compatibility with consumer and enterprise-grade NATs;¶

• No reliance on IP options or Application Layer Gateways (ALGs);¶

• Can be managed by existing firewalls and access control policies based on UDP port;¶

• Enables NAT traversal techniques such as UDP hole punching, keep-alive, and reachability testing (While the¶

DART protocol aims to eliminate the necessity of NAT gateways, it remains compatible with them, though the use of overly complex NAT-related techniques is not encouraged).¶

5.4. Example

Assume that the client client.dart.cn initiates a DART connection to the server server.example.com. The DART header fields are as follows:¶

6.1. FQDN as Address

In the DART protocol, each host uses its Fully Qualified Domain Name (FQDN) as its logical address (FQDN-ID). This address is transmitted in clear text within packets and serves as the primary basis for forwarding decisions. This model offers the following advantages:¶

• The address space is theoretically unlimited, constrained only by the domain name system.¶

• It can intuitively reflect the network's organizational structure and physical topology.¶

• It supports flexible address mapping, making scenarios such as load balancing and host mobility feasible-provided that DART gateways maintain consistent mappings.¶

• Effectively mitigates common problems of address conflicts and identity ambiguity typically encountered in NAT environments.¶

6.2. Inter-Domain Routing Model

The DART network adopts a hierarchical and distributed routing architecture based on domain names, with two core components: the DNS system and the DART Gateway:¶

• The DNS system constitutes the control plane of DART, responsible for domain name allocation, resolution, address mapping, and the dissemination and negotiation of control information. It determines the logical structure of communication paths.¶

• The DART Gateway is responsible for the data plane, handling data encapsulation and decapsulation, routing decisions, and protocol translation at domain boundaries.¶

This design follows the established principle of control plane and data plane separation in modern Internet architecture, enabling DART to achieve high scalability and flexible deployment. Inter-domain communication paths are resolved hierarchically through DNS, while actual packet forwarding is carried out by DART gateways at domain boundaries, thereby constructing a logically autonomous and structurally clear model of inter-domain connectivity.¶

It is worth noting that the host naming mechanism in DART networks is fully compatible with the existing DHCP+DNS infrastructure. In current local network practices, hosts typically submit their hostname during DHCP requests. The DHCP server assigns an IP address and can register the hostname-to-IP mapping in the DNS system using Dynamic DNS (DDNS) [RFC2136].¶

In future scenarios where hosts natively support the DART protocol stack, the DHCP server can centrally assign hostnames that conform to DART naming conventions, and DHCP clients can configure their local hostname accordingly. This ensures consistent and centrally managed naming within the network. Even in transitional phases where end hosts are not yet DART-aware, DHCP servers can enforce uniqueness by rejecting duplicate hostnames or appending disambiguating suffixes. This mechanism provides a practical and incremental deployment path for DART, allowing it to smoothly integrate with existing network environments.¶

              +------------------+
              |   Parent Domain  |
              +------------------+
                       ^
                       |
              [Upstream Interface]
                       |
        +----------------------------+
        |       DART Gateway         | <-- Lateral Link --> Other DART
        +----------------------------+                       Gateway
          ^                        ^
[Downstream Interface]    [Downstream Interface]
          |                        |
  +----------------+       +----------------+
  | Child Domain A |       | Child Domain B |
  +----------------+       +----------------+

6.3. NAT-DART-4 and Address Virtualization

To ensure compatibility with IPv4-only hosts that do not support the DART protocol, DART introduces the NAT-DART-4 translation mechanism. At the core of this mechanism is the concept of a virtual address, sometimes also referred to as a pseudo address.¶

The virtual address serves as an abstraction layer that enables transparent communication between IPv4-only hosts and the DART network, allowing protocol interoperability without requiring changes to legacy systems.¶

6.4. NAT44

For IP packets originating from a subdomain and destined for a public IPv4-only host, the DART gateway may optionally perform NAT44 encapsulation, treating the packet as an exception path for forwarding.¶

Due to the technical constraints of NAT44, the subdomain (i.e., the downstream domain of the DART gateway) is required to use private IPv4 address space for internal address assignment.¶

NAT44 is a mature and widely deployed legacy technology. Although it is not part of the DART protocol specification, it is fully compatible with DART. In practice, enabling NAT44 on DART gateways-especially those located at the network edge-can facilitate access to public IPv4-only destinations and promote a smoother and more incremental transition toward DART deployment.¶

6.5. Routing Autonomy

The DART protocol preserves full end-to-end semantics. The source host can determine whether the destination supports DART by examining the CNAME prefix in the DNS response, without relying on intermediate hops or centralized path computation. Path selection is driven by the DNS control plane and the distributed routing tables maintained by DART gateways, forming a decentralized routing control loop.¶

DART employs a hierarchical domain-based architecture, where each DART domain (i.e., DNS domain) operates as an independent routing autonomy. Within each domain, the DART gateway maintains and updates the routing table autonomously. This structure supports incremental deployment, hierarchical scalability, and high controllability.¶

Although DART does not rely on a centralized controller for routing management, it does not preclude the optional use of centralized components in specific scenarios-for example, to optimize inter-domain paths, distribute policy updates, or provide global visualization capabilities. The design and deployment of such mechanisms are left to implementers and operators and are outside the scope of this document.¶

6.6. Implicit Source Routing Capability

The DART protocol uses fully qualified domain names (FQDNs) with semantic structure as address identifiers, allowing the source host to indirectly guide the forwarding path by selecting different destination domain names without explicitly specifying each hop. This mechanism forms a capability similar to "implicit source routing," granting the endpoint partial control over path selection.¶

Within the DART network, gateways make forwarding decisions based on local inter-domain routing tables and DNS query results. Due to the hierarchical naming nature of DNS, different target FQDNs-even if pointing to the same physical host-may logically belong to different parent domains or path structures, resulting in variations in forwarding paths. Provided these FQDNs and their resolution records are pre-configured in DNS and DART routing policies, the source host can realize logical path guidance by choosing among multiple FQDNs.¶

For example, the same host may be accessed via host1.city-a.example.dart or host1.city-b.example.dart, which respectively steer traffic through different subdomain gateways, enabling path diversity. This design does not rely on explicit routing headers or centralized controllers but establishes a logically guided system with predictable and controllable path behavior through the interplay of DNS and distributed DART gateways.¶

Essentially, this mechanism embodies a semantics-driven path selection model that combines the flexibility of source routing with the autonomy of a distributed architecture, akin to "implicit loose source routing." Path control depends on the naming structure and deployment policies, lacking on-demand dynamic path specification but offering substantial policy flexibility.¶

It is important to note that the DART architecture generally adheres to a "single parent domain principle," where each DART gateway logically belongs to only one parent domain, maintaining a tree-like hierarchical structure. However, in certain practical scenarios, the local DART gateway may need to support multiple parent domain interfaces to enable multi-path access. In such cases, this locally breaks the "single parent domain" rule by allowing the gateway to connect to multiple parent domains simultaneously, thereby providing multiple logical path entries for the end host.¶

While this extension increases gateway topology complexity, it significantly enhances path redundancy and flexibility. Therefore, the DART architecture should accommodate such multi-parent domain access needs while preserving the overall clarity of the hierarchical structure. Relevant details and specification refinements are left for further discussion in future work.¶

Through the above mechanism, DART not only improves path controllability and resilience but also empowers endpoints with richer policy options without requiring protocol extensions, demonstrating the notable advantages of a naming-based network architecture.¶

7.1. NAT Background

Network Address Translation (NAT [RFC4787], [RFC5128]) has been widely deployed in enterprise and home networks to alleviate the IPv4 address exhaustion problem. By modifying packet headers and maintaining connection mappings, NAT allows multiple internal hosts to share a single public IPv4 address.¶

However, NAT breaks the original end-to-end communication model of the Internet, especially introducing additional complexity and protocol incompatibility issues for applications requiring inbound connections or using non-standard protocols. Therefore, NAT is both a technical compromise and an architectural trade-off.¶

7.2. Compatibility Encapsulation: UDP

To facilitate deployment in existing network environments during the transition phase, DART packets are encapsulated within UDP datagrams. This approach allows DART traffic to traverse NAT gateways, firewalls, and other intermediate devices without requiring modifications to existing network equipment.¶

DART currently uses UDP destination port 0xDA27 (decimal 55847) for encapsulated communication.¶

Encapsulation over UDP provides the following compatibility advantages:¶

• Supports outbound NAT traversal: most NAT gateways permit internal devices to initiate outbound UDP connections and dynamically establish return paths;¶

• Compatible with firewall policies: UDP traffic is generally allowed in the outbound direction;¶

• Avoids interference from intermediate devices: DART packets are treated as ordinary UDP traffic, reducing the risk of filtering due to unknown protocols.¶

7.3. Compatibility with Existing Infrastructure

Because DART packets are encapsulated within standard UDP datagrams, from the perspective of NAT gateways, firewalls, and routers, their behavior is indistinguishable from ordinary UDP traffic. Therefore, DART can operate over the current IPv4 network without requiring modifications to existing devices or network architectures, even when the network includes multiple layers of nested NAT.¶

• Naturally, under this mode, DART hosts remain subject to NAT behavior limitations. For example, hosts can only initiate connections actively; to accept incoming connections, IP and port mappings must still be configured on NAT gateways.¶

• This characteristic allows DART devices to be deployed relatively freely within existing networks. Even if upstream devices have not yet adopted the DART protocol, underlying hosts can connect first, thus enabling a "transparent, incremental" evolutionary deployment path.¶

7.4. Design Position on NAT Traversal Techniques

Traditional UDP applications often use NAT traversal techniques such as UDP hole punching, STUN, and TURN to establish peer-to-peer connections. However, these approaches are not aligned with the design goals of the DART protocol.¶

The core objective of DART is to localize the scope of IP addresses, enabling virtually unlimited address space reuse and thus providing an abundant supply of addresses. This reduces the necessity and relevance of traditional NAT gateways.¶

Therefore, implementers of the DART protocol should not incorporate NAT traversal techniques (e.g., UDP hole punching) within the protocol. Although such techniques remain practical in conventional networks, they are considered outdated within the DART architecture. The focus of research and implementation should be on promoting native DART network deployment and minimizing dependency on NAT, rather than continuing to provide compatibility adaptations for NAT.¶

By reducing intermediate-layer processing and simplifying the protocol stack, DART implementers can more easily achieve efficient and controllable end-to-end communication, truly restoring the original Internet principle of direct connectivity.¶

8.1. Technical Requirements and Deployment Prerequisites

The DART protocol leverages the DNS system as its control plane. Addressing, domain name resolution, and host registration within DART rely heavily on DNS coordination. Therefore, before deploying DART gateways and DART-ready hosts, the following technical requirements must be met:¶

DNS System Capabilities¶

• Authoritative Domain Delegation: Each DART subdomain must be registered with the DNS system through authoritative delegation. Upon deploying a DART gateway, operators need to delegate the corresponding subdomain in the parent DNS servers to map domain names to the DART gateway.¶

• Bidirectional FQDN-to-Address Mapping: The DNS system must support correct mapping from host FQDNs to DART addresses (A records or virtual addresses), as well as support reverse PTR queries to enhance manageability.¶

• Dynamic Registration and Automation: To facilitate dynamic scaling and elastic deployment of the DART network, DNS systems should provide interfaces for automatic registration (e.g., DNS UPDATE, API, or protocol extensions) allowing hosts and gateways to register their domain information upon connection.¶

DART Gateway Requirements¶

• DNS Control Plane Integration: DART gateways should actively register their subdomains, maintain virtual address mapping tables, and periodically synchronize resolution states with DNS.¶

• Independent Management: Gateways must independently manage their subdomain address and naming spaces.¶

• Full DART Encapsulation/Decapsulation: Gateways shall implement complete DART encapsulation and decapsulation logic, including support for NAT-DART-4 (optional) and DART packet forwarding.¶

• Parent Domain Uplink: Network interfaces must be properly configured with parent domain information to ensure correct inter-domain routing.¶

DART-Ready Host Requirements¶

• DART Packet Support: Hosts must be capable of generating and parsing DART packets, either through protocol stack upgrades, user-space daemons, or APIs.¶

• DNS Query Capability: Hosts should be able to actively query DNS for DART address information and establish connections accordingly.¶

• FQDN Registration: To receive incoming connections, hosts must be able to register their FQDNs within their respective DART subdomain DNS.¶

Subsequent sections will describe typical deployment models for national-level DART gateways, ISP internal DART gateways, edge gateways (home and enterprise), and hosts. Prior to device deployment, ensure DNS system capabilities meet these requirements and establish unified domain and address management coordination within the organization.¶

8.2. Deployment of DART-Ready Hosts

www.example.com.            CNAME    dart-host.www.example.com.
dart-host.www.example.com.  A        A.B.C.D

8.3. Deployment of DART Gateways

Each deployment of a DART gateway that establishes a new subdomain is allocated a complete IPv4 address space (i.e., 2^32 addresses) within that domain. Therefore, only a limited number of DART gateways are required to effectively mitigate the problem of IPv4 address exhaustion.¶

8.4. Incremental Deployment and Backward Compatibility

The DART protocol is designed to support compatibility and progressive evolution, with the following characteristics [RFC5555]:¶

• It can automatically detect whether the remote peer is a DART-capable device without requiring additional signaling negotiation;¶

• All DART-capable nodes inherently support dual-stack operation and are fully compatible with traditional IP;¶

• Through the NAT-DART-4 mechanism, IPv4-only hosts can be proxied by a local DART gateway and appear externally as DART-capable nodes, enabling full bidirectional communication within the DART network;¶

• Edge DART gateways can coexist with traditional NAT44 setups, allowing IPv4-only hosts in the local network to access legacy servers on the public Internet without modification;¶

• Crucially, IPv4-only devices under an edge DART gateway can remain unmodified indefinitely while still maintaining full communication capabilities over the DART network. This ensures long-term compatibility for non-upgradable endpoints.¶

From a deployment strategy perspective, the DART network prefers that public servers are upgraded first to DART-ready hosts and CPEs are upgraded to DART-ready gateways (each proceeding independently, without mutual dependency). Based on this, the upgrade sequence for other network infrastructure and end devices can be flexibly determined by users or operators, without strict dependency constraints. DART does not require full-scale upgrades of end devices; instead, it leverages the capabilities of edge gateways to allow legacy devices to continue operating, ensuring a smooth transition for users.¶

Thanks to these features, DART supports incremental, on-demand deployment. Even partial upgrades do not break existing connectivity or disrupt Internet services. The upgrade process is therefore inherently smooth, allowing both users and operators to adopt DART at their own pace and without requiring a wholesale migration of their network environment.¶

8.5. Long-Term Evolution Path

From a long-term perspective, the DART protocol offers the following potential directions for evolution and technical advancement:¶

• Progressive replacement of public IPv4 dependency
  DART establishes a name-centric addressing architecture, enabling end-to-end communication without the need for globally assigned public IP addresses or centralized address allocation.¶

• Full compatibility with IPv6
  DART can coexist and interoperate with IPv6-only networks, supporting dual-stack deployment and integrated forwarding in multi-protocol environments.¶

• Support for global unified addressing
  DART provides a consistent abstraction layer that facilitates seamless communication between IPv4 and IPv6 networks, paving the way for a globally unified, name-based interconnection model.¶

• Significant potential for global routing optimization¶

  • Theoretically unbounded DART address space eliminates the fragmentation and inefficiencies caused by IPv4 scarcity and micro-prefix allocations.¶

  • Within each DNS domain, address resources are abundant, allowing for highly aggregated allocations without the need for hierarchical compression.¶

  • In typical deployment scenarios, based on current DNS domain granularity and expected density, both global DART routing tables and intra-domain IP routing tables can be maintained at a manageable scale-expected to stay under 10^3 entries.¶

• Transformative changes in network architecture
  DART inherently promotes the creation of new autonomous subdomains, leading to a distributed and hierarchical address management structure.¶

• Gradual phasing out of traditional NAT
  Conventional NAT gateways will be replaced by DART gateways, which provide address translation and domain isolation in a more flexible and efficient manner.¶

• Enhanced network security capabilities
  By leveraging FQDN-based identity and access control, DART enables stronger communication authentication and fine-grained policy enforcement.¶

• Balance between authentication and privacy
  DART has the potential to offer user privacy protection through dynamic naming, proxy-based forwarding, and encryption mechanisms-while maintaining reliable identity validation.¶

• Support for innovative applications and service models
  The flexible name mapping and dynamic routing of DART could drive the development of novel use cases such as name-based content delivery, collaborative edge computing, trusted IoT communication frameworks, and intelligent network management with QoS guarantees and routing optimization.¶

This evolution path provides a practical and forward-compatible roadmap for DART to gradually replace traditional IP architecture and support the foundation of the next-generation Internet infrastructure.¶

8.6. Native FQDN-Based Policy Enforcement

9.1. UDP Port Assignment

The DART protocol relies on UDP as its transport encapsulation format. Therefore, an officially assigned UDP port number is required to identify DART packets [RFC8126].¶

• Name: DART¶

• Transport Protocol: UDP¶

• Suggested Port Number: 0xDA27 (decimal 55847)¶

• Usage Description: DART packets are encapsulated in UDP to support NAT traversal and compatibility with existing IP networks. All DART-capable gateways and hosts listen on this port.¶

Note: UDP port 55847 is currently used for experimental purposes. Once the protocol proceeds through the IETF standardization process, an official Well-Known Port (WKP) under 1024 will be formally requested from IANA.¶

9.2. DNS CNAME Prefix Conventions (Non-IANA)

To indicate whether a host supports the DART protocol, special CNAME prefixes in DNS responses are used. This draft proposes the following naming conventions:¶

• dart-host.: Indicates that the target host is DART-capable and can receive DART-encapsulated packets directly.¶

• dart-gateway.: Indicates that the target host resides in another DART subdomain; packets should be forwarded to the local DART gateway. The associated A record provides the gateway's IP address.¶

These prefixes do not require formal IANA reservation but are recommended for documentation and community consensus to avoid conflicts with other protocols.¶

9.3. IP Protocol Number (Optional/Future Use)

Currently, DART packets are encapsulated within UDP and do not require a new IP protocol number. However, if in the future the community seeks to transport DART directly at the IP layer (e.g., as a new L3 protocol), a new IP protocol number may be requested from IANA.¶

• Current Status: No new IP protocol number requested.¶

• Future Extensibility: Reserved as an option for future community-defined extensions.¶

10.1. Risks Related to DNS

DART relies on DNS responses (particularly CNAME and A records) for address resolution and capability indication. This dependency exposes it to DNS-based attacks:¶

• DNS spoofing / cache poisoning: An attacker may forge or manipulate DNS responses, tricking clients into sending DART messages to malicious gateways or hosts.¶

Mitigations:¶

• Strongly recommend the use of DNSSEC to validate DNS response integrity [RFC4033][RFC4034][RFC4035].¶

• DART clients should cache DNS results with appropriate TTLs to reduce exposure.¶

• DART gateways may maintain ACLs or whitelists to restrict valid destination domains.¶

10.2. Spoofing or Abuse of Virtual Addresses

DART assigns virtual IP addresses to IPv4-only hosts to enable DART-based communication. Attackers might attempt to spoof or predict these mappings, potentially causing [RFC2827]:¶

• Virtual address collisions,¶

• Misrouting of traffic to unintended hosts,¶

• DoS attacks leveraging forged virtual addresses.¶

Mitigations:¶

• DART gateways must dynamically assign and manage virtual addresses, ensuring mappings are host-specific and not globally visible.¶

• Virtual addresses should be drawn from a private, controlled range (e.g., 198.18.0.0/15) to avoid conflicts with real-world addresses.¶

• Randomized address assignment can help reduce predictability.¶

Note: Since virtual address mapping is DNS-based, successful spoofing attempts would require DNS manipulation or MitM capabilities-equivalent to classic DNS attacks. Thus, deploying DNSSEC or encrypted DNS (e.g., DoT/DoH) is strongly recommended.¶

10.3. Injection of Forged DART Packets

Attackers may forge DART-encapsulated UDP packets with false headers in an attempt to manipulate gateway behavior or inject invalid traffic.¶

Mitigations:¶

• DART gateways should validate source addresses and maintain ingress filtering.¶

• If deployed in untrusted environments, consider encapsulating DART traffic using IPsec [RFC4301], QUIC, or similar secure transport layers.¶

• Gateways may apply basic rate-limiting and session-based admission control to mitigate abuse.¶

10.4. Inter-Domain Route Spoofing

Because DART relies on domain-based interconnection paths, adversaries may register deceptive subdomains or craft malicious DNS entries to redirect traffic.¶

Mitigations:¶

• Parent domain administrators should audit subdomain configurations.¶

• DNS zone administration must follow traditional best practices with access controls.¶

• DART deployments may benefit from introducing domain registration policies or a trust framework to validate subdomain authenticity.¶

10.5. Privacy Exposure of Private Network Hosts

In some environments, private network hosts using DART may include identifiable information (e.g., FQDNs) in outbound messages, potentially exposing user identities in sensitive contexts.¶

Mitigations:¶

• DART gateways may be configured to obfuscate or replace source identity fields, acting as privacy-preserving proxies.¶

• Encrypted DNS (DoT/DoH) and encrypted transports (e.g., TLS, QUIC) are encouraged for protecting name resolution and message confidentiality.¶

• Gateways may implement firewalls or access controls based on domain, port, and identity attributes.¶

• Future work may explore anonymization or pseudonymization of DART headers to reduce traceability.¶

Design Philosophy Note:¶

DART aims to enable global end-to-end reachability, which inherently requires addressability and identity visibility. Unlike traditional NAT models that rely on obscurity for "implicit security," DART adopts a transparent model with structured namespaces and policy-driven access control.¶

To be reachable is to be observable; to be connected is to be identifiable.¶

Security in DART is achieved through encryption, domain-level boundaries, and controllable access-not through concealment. The protocol encourages a shift from "unreachability as security" to "policy-enforced security" as a forward-looking paradigm.¶

11.1. Normative References

[RFC1034]

Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/rfc/rfc1034>.

[RFC1035]

Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC2136]

Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <https://www.rfc-editor.org/rfc/rfc2136>.

[RFC2181]

Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <https://www.rfc-editor.org/rfc/rfc2181>.

[RFC2328]

Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/rfc/rfc2328>.

[RFC2663]

Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, <https://www.rfc-editor.org/rfc/rfc2663>.

[RFC2827]

Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <https://www.rfc-editor.org/rfc/rfc2827>.

[RFC3022]

Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <https://www.rfc-editor.org/rfc/rfc3022>.

[RFC4034]

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/rfc/rfc4034>.

[RFC4035]

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <https://www.rfc-editor.org/rfc/rfc4035>.

[RFC4271]

Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/rfc/rfc4271>.

[RFC4301]

Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/rfc/rfc4301>.

[RFC4787]

Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, <https://www.rfc-editor.org/rfc/rfc4787>.

[RFC5555]

Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, DOI 10.17487/RFC5555, June 2009, <https://www.rfc-editor.org/rfc/rfc5555>.

[RFC768]

Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/rfc/rfc768>.

[RFC791]

Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/rfc/rfc791>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8200]

Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/rfc/rfc8200>.

11.2. Informative References

[RFC4033]

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/rfc/rfc4033>.

[RFC4864]

Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, DOI 10.17487/RFC4864, May 2007, <https://www.rfc-editor.org/rfc/rfc4864>.

[RFC5128]

Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March 2008, <https://www.rfc-editor.org/rfc/rfc5128>.

[RFC8504]

Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, <https://www.rfc-editor.org/rfc/rfc8504>.

A.1. Network Architecture

Assume the following network environment:¶

• Top-level domain:
  dart.example, serving as the parent domain of two DART gateways. The parent domain interface IPs of gw1 and gw2 are 10.0.0.1 and 10.0.0.2, respectively.¶

• Subdomains:¶

  • sub1.dart.example (Subdomain 1), connected to DART gateway gw1. The interface IP of gw1 in this subdomain is 10.1.0.1.¶

  • sub2.dart.example (Subdomain 2), connected to DART gateway gw2. The interface IP of gw2 in this subdomain is 10.2.0.1.¶

The connection topology is as follows:¶

            +-------------------------------------+
            |            dart.example             |
            |         (Parent DNS & Backbone)     |
            +-------------------------------------+
                    |                     |
              +-----v-----+         +-----v------+
              |    gw1    |         |    gw2     |
              | (DART GW) |         | (DART GW)  |
              +-----------+         +------------+
                    |                     |
        +-----------v-------+   +---------v----------+
        | sub1.dart.example |   | sub2.dart.example  |
        |  - A: IPv4-only   |   |  - C: DART Ready   |
        |  - B: DART Ready  |   |  - D: IPv4-only    |
        +-------------------+   +--------------------+

• A: 10.1.0.11, IPv4-only¶

• B: 10.1.0.12, DART Ready¶

• C: 10.2.0.11, DART Ready¶

• D: 10.2.0.12, IPv4-only¶

Note: Since DART logically isolates IP address scopes across domains, the three domains above (one parent and two subdomains) may reuse the same IP subnets without collision. Different subnets are used here solely to avoid reader confusion.¶

In this deployment, gw1 and gw2 each integrate a DHCP server and a DNS server. These services must tightly integrate with the forwarding plane. If implemented as standalone servers, effective information sharing with the DART gateway is essential.¶

A.2. Procedures

Initialization (DHCP Phase)¶

• Hosts A/B/C/D obtain IP addresses from their local DART gateway via DHCP.¶

• DART-ready hosts (B and C) include a special DHCP Option to indicate DART capability.¶

• DART-ready hosts also use the domain name provided by the DHCP server to construct their own FQDNs.¶

• IPv4-only hosts (A and D) are unaware of DART and join the network using legacy DHCP processes.¶

• During this phase, the DHCP server:¶

  • Allocates IPs, default gateways, and DNS servers;¶

  • Records whether the host supports DART;¶

  • Constructs FQDNs for IPv4-only hosts using their hostnames.¶

DNS Resolution¶

Each gateway has an embedded DNS server with the following behavior:¶

• For queries received via the parent domain interface:¶

  • Always respond with the gateway's parent domain IP, regardless of the actual destination. This forces the sender to route packets via the gateway.¶

• For queries received via the subdomain interface:¶

  • If querying an in-domain host: respond with the actual IP of the target.¶

  • If querying a host in another domain:¶

    • If the querier is DART-ready: respond with the gateway's subdomain interface IP, so the DART packet is sent via the local interface.¶

    • If the querier is IPv4-only: allocate a virtual IP, bind it to the queried FQDN, and respond with this virtual IP. The IPv4-only host will send the packet to the virtual address, which routes to the gateway.¶

Forwarding¶

• For DART packets arriving at the parent domain interface:¶

  • If the destination is a DART-ready host (B/C), forward via the corresponding subdomain interface.¶

• For DART packets arriving at the subdomain interface (e.g., sent by B or C):¶

  • Forward via the parent domain interface.¶

• In both cases:¶

  • DART header remains unchanged;¶

  • IP header source and destination are rewritten appropriately.¶

NAT-DART-4 Encapsulation (Sender Side)¶

Example: Host A (IPv4-only) sending to a host in sub2 (C or D):¶

1. A queries C.sub2.dart.example from its configured DNS server (10.1.0.1).¶

2. The DNS server determines that C is external to the subdomain and:¶

   • Allocates virtual address 198.18.1.34 and binds it to C.sub2.dart.example;¶

   • Returns:
     C.sub2.dart.example. CNAME dart-gateway.sub1.dart.example. dart-gateway.sub1.dart.example. A 198.18.1.34¶

   Although A is IPv4-only and ignores the CNAME, this prefix signals to operators that this is a DART-based mapping and 198.18.. is a virtual IP.¶

3. A constructs an IP packet with destination 198.18.1.34 and sends it.¶

4. The packet is routed to its default gateway gw1 (as the destination is non-local).¶

5. At gw1, the following actions occur:¶

   • Detects virtual IP as destination;¶

   • Inserts DART header and UDP encapsulation;¶

   • Fills in destination FQDN (C.sub2.dart.example) from DNS mapping;¶

   • Determines source FQDN (A.sub1.dart.example) from DHCP records;¶

   • Resolves C.sub2.dart.example via parent domain DNS to obtain 10.2.0.1;¶

   • Sets source IP as 10.0.0.1 (gw1's parent interface);¶

   • Sends encapsulated packet from parent interface.¶

6. The packet is routed via IP backbone and arrives at gw2's parent interface.¶

7. gw2:¶

   • Recognizes C as a DART-ready host;¶

   • Rewrites the IP header (destination: 10.2.0.11, source: 10.2.0.1);¶

   • Forwards the DART packet via its subdomain interface to C.¶

NAT-DART-4 Decapsulation (Receiver Side)¶

Example: Host D (IPv4-only) receives a DART packet via gw2:¶

1. gw2 receives a DART packet from parent interface, destined for D.sub2.dart.example.¶

2. Determines D is an IPv4-only host:¶

   • Allocates a virtual source address;¶

   • Maps sender's FQDN to this virtual IP;¶

   • Strips DART and UDP headers;¶

   • Constructs a native IP packet:¶

     • Destination: D's IP 10.2.0.12¶

     • Source: virtual address¶

   • Sends via subdomain interface.¶

3. D receives the packet and replies to the virtual source IP.¶

4. gw2 re-encapsulates the reply using the same virtual-IP-to-FQDN mapping.¶

5. The response is routed back to the original sender through the DART infrastructure.¶

A.3. Case Walkthrough

Let host A (A.sub1.dart.example, 10.1.0.11, IPv4-only) send a message to host C (C.sub2.dart.example, 10.2.0.11, DART Ready):¶

1. A queries C.sub2.dart.example via DNS.¶

2. DNS server returns:¶

   C.sub2.dart.example. CNAME dart-gateway.sub1.dart.example. dart-gateway.sub1.dart.example. A 198.18.1.34¶

3. A sends packet to 198.18.1.34, which is routed to gw1.¶

4. gw1 detects virtual destination:¶

   • Builds DART header with source FQDN A.sub1.dart.example and destination FQDN C.sub2.dart.example;¶

   • Looks up IP 10.2.0.1 for destination;¶

   • Sends encapsulated DART packet from 10.0.0.1.¶

5. Packet is delivered to gw2.¶

6. gw2 finds that destination C is DART-ready:¶

   • Forwards DART packet to 10.2.0.11 from 10.2.0.1.¶

A.4. Summary

This example illustrates a multi-subdomain, mixed-host environment and highlights:¶

• DNS-driven forwarding behavior;¶

• Role of virtual addresses in enabling IPv4-only interoperability;¶

• Encapsulation and decapsulation by DART gateways;¶

• Cross-domain communication between legacy and DART-ready nodes.¶