Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC TR 29181-2: Future Networks — Part 2: Naming and Addressing
A Technical Report of the ISO/IEC Future Network Framework (29181 Series)
Overview of Naming and Addressing in Future Networks
ISO/IEC TR 29181-2 addresses one of the most fundamental challenges in future network architecture: how to name and locate resources in a highly dynamic, heterogeneous environment. The global Internet currently relies on IP addresses that serve dual roles as both identifiers and locators, creating well-known problems for mobility, multihoming, and renumbering. Future networks require a clean separation between identifiers (who the entity is) and locators (where it is attached). This technical report, part of the Future Network framework, explores naming schemes that support mobility, multihoming, and massive-scale IoT deployments. Key concepts include identifier/locator split architectures, flat naming versus hierarchical naming trade-offs, and resolution frameworks that scale efficiently to billions of nodes.
Identifier/Locator separation is a cornerstone of future network design. It enables seamless mobility because a device’s identifier remains constant even as its network attachment point changes — eliminating the need for triangular routing or mobility anchors.
| Aspect | Current Internet (IPv4/IPv6) | Future Network (TR 29181-2) |
|---|---|---|
| Identifier vs Locator | Bound together (IP addr serves both) | Cleanly separated (ID + locator) |
| Naming scheme | Hierarchical (DNS tree) | Flat + DHT-based resolution |
| Mobility support | Difficult (re-addressing needed) | Native (ID follows device) |
| Scalability concern | Routing table bloat (900k+ routes) | Scalable resolution layers |
| Security binding | Weak (IP spoofing is trivial) | Cryptographic self-certifying IDs |
Identifier/Locator Split Architecture in Depth
The report details several proposed architectures for splitting identifiers from locators. The Locator/ID Separation Protocol (LISP), developed in the IETF, is one prominent example — it uses mapping systems like LISP+ALT or LISP-DDT to resolve endpoint identifiers (EIDs) to routing locators (RLOCs). However, TR 29181-2 goes further by examining generalized mapping systems beyond LISP, including Distributed Hash Table (DHT)-based resolution, hierarchical mapping with geographic aggregation, and blockchain-anchored name registries. The resolution infrastructure must support dynamic registration (devices joining and leaving frequently), fast lookup (sub-millisecond for local names), and trust verification of mapping updates. A critical design insight is that naming authorities should be decentralized to avoid single points of failure, while maintaining global uniqueness guarantees. Cryptographic identifiers — where the identifier is derived from a public key — provide inherent security benefits, enabling source authentication without requiring a PKI for every transaction. The report evaluates trade-offs between identifier lengths (64-bit vs 128-bit vs variable), encoding formats (binary vs human-readable), and resolution latency budgets.
Flat naming spaces scale well algorithmically but introduce challenges in human readability, debugging, and reverse lookups. A hybrid approach — combining flat machine-readable names for internal network operations with human-friendly labels for management interfaces — is recommended for production deployments.
The TR also analyzes mapping system performance under stress. Simulation results show that DHT-based resolution can sustain 10 million queries per second with a median latency under 5 ms when caching is properly configured at edge nodes. Cache hit ratios of 85-95% are achievable for popular names, reducing load on authoritative resolution infrastructure. The report recommends TTL values between 60 seconds (for mobile endpoints) and 24 hours (for stable infrastructure names), with immediate invalidation channels for critical updates.
Engineering Implications, Governance, and Deployment Roadmap
For network engineers, adopting a split naming architecture means rethinking DNS, routing policies, security models, and operational tooling. The TR emphasizes pragmatic transition mechanisms that must coexist with IPv4/IPv6 during a migration period expected to last 10-15 years. Key engineering takeaways include: (1) resolution latency must stay under 10 ms for real-time applications, which places strict requirements on cache placement and network topology; (2) caching strategies at edge nodes (CPE routers, 5G UPFs) dramatically reduce lookup overhead — a three-tier cache with L1 at the device, L2 at the access gateway, and L3 at the regional resolver can cover 99% of lookups locally; (3) cryptographic name binding adds 5-15% CPU overhead per resolution but eliminates entire attack classes including DNS spoofing and cache poisoning. The report also discusses governance models for naming registries, recommending a tiered structure modeled on the existing RIR system (AfriNIC, APNIC, ARIN, LACNIC, RIPE NCC) but extended with a root authority for future-network names, regional registries for sub-allocation, and local registries for enterprise and IoT domains.
In large-scale ISP deployments, implementing identifier/locator separation has been shown to reduce routing table sizes by 30-40% (by aggregating RLOC prefixes) while simultaneously improving mobility handoff performance from 200 ms to under 20 ms. These gains directly translate to better user experience for real-time applications.
Without robust security in the resolution system, attackers can hijack name-to-locator bindings through man-in-the-middle attacks or compromised registries. The TR mandates authenticated mapping updates using digital signatures and recommends DNSSEC-equivalent validation chains for all future network name resolution. Operators must implement rate limiting and anomaly detection on mapping update requests.
Frequently Asked Questions
What is the main difference between naming and addressing in future networks?
Naming identifies a resource by what it is (a service, a device, a piece of content), while addressing specifies where it is located topologically. Future networks separate these concepts to improve mobility, multihoming efficiency, security, and overall scalability. This is in contrast to the current Internet where IP addresses conflate both roles.
Naming identifies a resource by what it is (a service, a device, a piece of content), while addressing specifies where it is located topologically. Future networks separate these concepts to improve mobility, multihoming efficiency, security, and overall scalability. This is in contrast to the current Internet where IP addresses conflate both roles.
How does ISO/IEC TR 29181-2 relate to SDN and NFV?
The TR is complementary — SDN and NFV provide the programmable infrastructure and network function virtualization, while 29181-2 provides the naming framework that runs on top of this infrastructure. Together they enable fully dynamic network orchestration where resources can be named, discovered, and connected programmatically. SDN controllers can use the naming resolution system as a northbound service discovery mechanism.
The TR is complementary — SDN and NFV provide the programmable infrastructure and network function virtualization, while 29181-2 provides the naming framework that runs on top of this infrastructure. Together they enable fully dynamic network orchestration where resources can be named, discovered, and connected programmatically. SDN controllers can use the naming resolution system as a northbound service discovery mechanism.
Is there backward compatibility with the existing DNS system?
Yes. The TR describes interworking functions and gateways that map future network names to DNS records and vice versa. This ensures a gradual migration path where organizations can deploy future-network naming incrementally without breaking existing DNS-dependent services. The interworking layer handles format conversion, security translation, and caching across both naming systems.
Yes. The TR describes interworking functions and gateways that map future network names to DNS records and vice versa. This ensures a gradual migration path where organizations can deploy future-network naming incrementally without breaking existing DNS-dependent services. The interworking layer handles format conversion, security translation, and caching across both naming systems.
What are the implications for IoT device manufacturers?
IoT devices benefit significantly from identifier/locator separation. A sensor can have a stable identifier throughout its lifetime regardless of network attachment changes. The TR recommends that IoT devices be pre-provisioned with cryptographic identifiers at manufacturing time, using the device’s public key as the basis for its network identifier. This simplifies secure bootstrapping and eliminates the need for per-network credential provisioning.
IoT devices benefit significantly from identifier/locator separation. A sensor can have a stable identifier throughout its lifetime regardless of network attachment changes. The TR recommends that IoT devices be pre-provisioned with cryptographic identifiers at manufacturing time, using the device’s public key as the basis for its network identifier. This simplifies secure bootstrapping and eliminates the need for per-network credential provisioning.
