Hash-Based IPv6 Address Derivation for Deterministic Name Resolution

Internet Engineering Task Force (IETF) K. Weller Request for Comments: XXXX Category: Experimental October 27, 2025 ISSN: 2070-1721

              Hash-Based IPv6 Address Derivation for
                    Deterministic Name Resolution

Abstract

This document proposes a deterministic method for deriving IPv6 addresses from human-readable domain names using cryptographic hashing. By combining an ISP-allocated IPv6 prefix with a hash-derived interface identifier, clients can resolve names to addresses locally without traditional DNS servers. This approach enhances reliability, privacy, and efficiency for Internet-wide use, leveraging IPv6's vast address space. It addresses DNS challenges while enabling seamless adaptation of services like web hosting and email. Inspired by RFC 4291 (IPv6 Addressing Architecture) and RFC 6762 (Multicast DNS), this experimental protocol simplifies name resolution for users, administrators, and the Internet community.

Status of This Memo

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

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/rfcXXXX.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Table of Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
Challenges with Traditional DNS and How HID Addresses Them . . 4
System Design: A Simple Breakdown . . . . . . . . . . . . . . 5 4.1. Prefix Allocation and Discovery . . . . . . . . . . . . 6 4.2. The Derivation Process Step by Step . . . . . . . . . . 7 4.3. Adapting Services and DNS Record Types . . . . . . . . 8
Working Examples . . . . . . . . . . . . . . . . . . . . . . 10
Implementation Guidelines . . . . . . . . . . . . . . . . . . 11 6.1. Pseudocode . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Python Implementation . . . . . . . . . . . . . . . . . 12 6.3. Go Implementation . . . . . . . . . . . . . . . . . . . 13
Benefits for Users, Administrators, and the Internet . . . . 14
Use Cases: Adapting Common Services . . . . . . . . . . . . . 15
Security Considerations . . . . . . . . . . . . . . . . . . . 16
IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
References . . . . . . . . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Introduction

The Domain Name System (DNS), defined in RFC 1034 and RFC 1035, is the Internet's cornerstone for name resolution but relies on a hierarchical infrastructure that introduces reliability, privacy, and performance challenges. With IPv6's vast address space (RFC 8200), we propose a simpler alternative: Hash-Based IPv6 Address Derivation (HID). HID allows clients—such as browsers, email clients, or network devices—to compute IPv6 addresses directly from domain names like "example.com" using a standard hash function. This eliminates external DNS queries, mirroring the simplicity of RFC 6762 (Multicast DNS) for local networks and the addressing clarity of RFC 4291 (IPv6 Addressing Architecture).

HID enables users to choose familiar domain names, derive unique IPv6 addresses within ISP-allocated prefixes, and configure services with minimal changes. It supports common DNS record types through subdomain conventions, ensuring compatibility with web, email, and other services. Designed for the broader Internet, HID enhances user experience, simplifies administration, and aligns with IPv6 adoption trends, as seen in RFC 8200's global rollout. This experimental RFC invites implementation in mainstream tools to evaluate its potential.

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Domain Name: A human-readable string, e.g., "example.com".
IPv6 Prefix: An ISP-allocated block, typically /48, per RFC 6177.
Interface Identifier (IID): The 64-bit suffix of an IPv6 address.
Hash Function: SHA-256, as defined in FIPS 180-4.
Registry: A public database mapping domains to prefixes, built on existing RIR infrastructure.

Challenges with Traditional DNS and How HID Addresses Them

Traditional DNS, while robust, faces issues that HID mitigates:

Reliability: Centralized servers are prone to outages or attacks (e.g., DDoS incidents on root servers). HID resolves names locally via computation, akin to RFC 6762's serverless multicast approach, ensuring access even during disruptions.
Privacy: Queries expose user activity to ISPs or third parties. HID eliminates queries, offering privacy benefits beyond RFC 8484 (DNS over HTTPS) by avoiding network traffic entirely.
Performance: Recursive lookups add latency, especially for global users. HID's instant hash computation mirrors the efficiency of RFC 4291's streamlined IPv6 addressing.
Administrative Overhead: Managing DNS records requires server updates. HID uses subdomain hashing, reducing complexity like RFC 4193 (Unique Local Addresses) simplified private networking.
IPv6 Transition: DNS dual-stack operations complicate deployments. HID leverages IPv6 exclusively, encouraging adoption per RFC 8200.

HID aims to complement or replace DNS for core Internet functions, appealing to users seeking simplicity and administrators managing large-scale networks.

System Design: A Simple Breakdown

HID is designed for accessibility and integration:

Choose a Domain: Users select a name like "example.com", similar to current DNS practices.
Obtain ISP Prefix: ISPs provide a /48 prefix, standard per RFC 6177.
Register Mapping: Record the domain-prefix pair in a public RIR database for discovery.
Derive Address: Hash the domain to generate the IID, combine with the prefix.
Configure Services: Set servers to use the derived IPv6 address.
Client Resolution: Devices compute the address locally using the same hash.

This mirrors the straightforward design of RFC 6762, which enabled zero-configuration networking.

4.1. Prefix Allocation and Discovery

ISPs allocate /48 prefixes as standard practice (RFC 6177). To associate domains with prefixes:

Public Registry: Extend Regional Internet Registry (RIR) databases (e.g., ARIN, RIPE NCC) to include domain-prefix mappings, verified by ownership proofs (e.g., signed by the organization's key). This builds on existing RIR APIs, as in RFC 9872 for prefix discovery.
Local Caching: Clients periodically download a JSON snapshot of mappings (e.g., from whois.arin.net/hid-mappings) for offline use, similar to certificate transparency logs in RFC 6962.
Fallback: If a prefix is missing, clients can query the RIR directly with user consent, ensuring privacy.

This leverages trusted, widely adopted RIR infrastructure.

4.2. The Derivation Process Step by Step

Normalize the domain to lowercase (e.g., "Example.com" → "example.com").
Compute SHA-256 hash of the domain (UTF-8 encoded).
Extract the first 64 bits (16 hex characters) as the IID.
Format IID into four colon-separated groups.
Combine with prefix and a fixed subnet (e.g., :0000::).
For subdomains (e.g., "mx.example.com"), hash the full string.

The process is deterministic and collision-resistant due to SHA-256's properties and IPv6's address space.

4.3. Adapting Services and DNS Record Types

HID replaces traditional DNS records with subdomain-based hashing, requiring minimal service changes:

Host Addresses (AAAA): Hash the main domain for the server IP. Configure web servers (e.g., Nginx: Listen [2001:db8:1234:0000::a379:a6f6:eeaf:b9a5]:80).
Mail Exchangers (MX): Hash "mx.domain.com" for the mail server IP. Use "mx10.domain.com" for priority 10. Update email servers (e.g., Postfix: bind to derived IP).
Aliases (CNAME): Hash the alias subdomain; clients compute and redirect to the target IP.
Text Records (TXT): Append text data before hashing (e.g., "_txt.spf=policy.domain.com"). Clients extract text post-hash.
Service Records (SRV): Hash "_srv._protocol.domain.com" with port/weight embedded. Configure services (e.g., SIP) to listen on derived IP/port.
Delegation (NS) and Reverse (PTR): Use registry for NS mappings; reverse via hashed arpa-style names.

Services adapt by updating network configurations, similar to IPv6 adoption processes, enabling full DNS replacement with coexistence.

Working Examples

Using prefix "2001:db8:1234" for "example.com" from the registry:

example.com: Derives to 2001:db8:1234:0000::a379:a6f6:eeaf:b9a5 (web server).
www.example.com: Derives to 2001:db8:1234:0000::80fc:0fb9:266d:b7b8 (alias).
mx.example.com: Derives to 2001:db8:1234:0000::809a:f507:0320:a817 (email server).

Clients fetch the prefix from a local cache, hash the domain, and connect directly.

Implementation Guidelines

Implement HID in resolvers, browsers, or libraries. Use local prefix caches updated from RIR feeds.

6.1. Pseudocode

function deriveIPv6(domain, prefix):
    // Normalize
    domain = lowercase(domain)
    
    // Hash
    hash = SHA256(domain as UTF-8)
    hashHex = convertToHex(hash)  // 64 chars
    
    // Extract IID
    iidHex = hashHex[0 to 15]
    
    // Format
    iidFormatted = iidHex[0-3] + ":" + iidHex[4-7] + ":" + iidHex[8-11] + ":" + iidHex[12-15]
    
    // Build IPv6
    fullIPv6 = prefix + ":0000::" + iidFormatted
    
    return fullIPv6

6.2. Python Implementation

import hashlib
import json

def load_prefix(domain, local_registry='rir_mappings.json'):
    with open(local_registry, 'r') as f:
        mappings = json.load(f)
    return mappings.get(domain.lower(), None)

def derive_ipv6(domain, prefix=None):
    if prefix is None:
        prefix = load_prefix(domain)
        if prefix is None:
            raise ValueError("Prefix not found in local cache")
    domain = domain.lower()
    hash_obj = hashlib.sha256(domain.encode('utf-8'))
    hash_hex = hash_obj.hexdigest()
    iid_hex = hash_hex[:16]
    iid_formatted = ':'.join(iid_hex[i:i+4] for i in range(0, 16, 4))
    return f"{prefix}:0000::{iid_formatted}"

# Example outputs
print(derive_ipv6('example.com', '2001:db8:1234'))  # 2001:db8:1234:0000::a379:a6f6:eeaf:b9a5
print(derive_ipv6('www.example.com', '2001:db8:1234'))  # 2001:db8:1234:0000::80fc:0fb9:266d:b7b8

6.3. Go Implementation

package main
import (
    "crypto/sha256"
    "encoding/hex"
    "fmt"
    "strings"
)

func deriveIPv6(domain string, prefix string) string {
    domain = strings.ToLower(domain)
    h := sha256.New()
    h.Write([]byte(domain))
    hashBytes := h.Sum(nil)
    hashHex := hex.EncodeToString(hashBytes)
    iidHex := hashHex[:16]
    var iidFormatted strings.Builder
    for i := 0; i < 16; i += 4 {
        if i > 0 {
            iidFormatted.WriteString(":")
        }
        iidFormatted.WriteString(iidHex[i : i+4])
    }
    return fmt.Sprintf("%s:0000::%s", prefix, iidFormatted.String())
}

func main() {
    fmt.Println(deriveIPv6("example.com", "2001:db8:1234"))  // 2001:db8:1234:0000::a379:a6f6:eeaf:b9a5
}

Benefits for Users, Administrators, and the Internet

Users: Experience faster, more private browsing and app access with no resolution delays or tracking, extending RFC 8484's privacy gains.
Administrators: Simplify network management by eliminating DNS server maintenance, akin to RFC 4193's ease for private addresses.
Internet Community: Enhances resilience against outages, reduces infrastructure costs, and accelerates IPv6 adoption, building on RFC 8200's foundation for scalable addressing.

These benefits appeal to ISPs, enterprises, and end users seeking a robust Internet.

Use Cases: Adapting Common Services

Web Hosting: Derive IP for "example.com"; configure servers (e.g., Apache) to bind to it. Users access sites without DNS delays.
Email Systems: Hash "mx.example.com" for SMTP; update Postfix configs. Ensures reliable email routing, as RFC 5321 intended.
Enterprise Networks: Derive internal domain IPs; simplify intranet setups like RFC 6762 for local networks.
Content Delivery Networks: Use subdomains for regional IPs, adapting load balancers with minimal reconfiguration.

These use cases show HID's broad applicability for standard Internet services.

Security Considerations

Hash Collisions: SHA-256's 2^128 resistance ensures negligible risk; verify with full hash if needed.
Domain Ownership: RIR-based proofs (e.g., signed entries) prevent squatting, similar to DNSSEC (RFC 4033).
Privacy: No query leaks; subdomain patterns mitigated with optional salts.
Integrity: Use TLS (RFC 8446) over derived IPs for security.
Registry Trust: RIR verification ensures integrity, as in existing allocation processes.

IANA Considerations

Request allocation of a special-use domain (e.g., ".hid") per RFC 6761 for HID-compatible names. No new address allocations required; use existing RIR frameworks.

Acknowledgments

This proposal draws inspiration from IETF DNSOP and 6MAN Working Groups, particularly RFC 4291 and RFC 6762, and contributions from the Internet community on IPv6 and naming innovations.

References

12.1. Normative References

[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/info/rfc2119.

[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/info/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/info/rfc8200.

12.2. Informative References

[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, https://www.rfc-editor.org/info/rfc1034.

[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, https://www.rfc-editor.org/info/rfc1035.

[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, https://www.rfc-editor.org/info/rfc4193.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, https://www.rfc-editor.org/info/rfc4291.

[RFC6177] Narten, T., et al., "IPv6 Address Assignment to End Sites", BCP 157, RFC 6177, DOI 10.17487/RFC6177, March 2011, https://www.rfc-editor.org/info/rfc6177.

[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, https://www.rfc-editor.org/info/rfc6762.

[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, https://www.rfc-editor.org/info/rfc8484.

Authors' Addresses

Kyle Weller Email: [email protected]

ion-storm/IDN_DNS.md

Select an option

No results found

Select an option

No results found