Reservation of IPv6 Address Block 44::/16 for Amateur Radio Digital Communications (44Net)

Rationale for an Amateur Radio IPv6 Allocation

Historical Significance and Community Needs The amateur radio community has a demonstrated need for dedicated IP resources to conduct its activities. The success of IPv4 44/8 over four decades of use shows that having a unified address space greatly facilitates amateur radio networking on a global scale. Tens of thousands of amateur operators and clubs worldwide have used 44Net addresses to link radio-based networks, develop and test networking protocols, and interconnect with academic or public networks for research. This experimentation under real public Internet conditions has been possible because 44Net addresses are globally unique and routable, allowing ham-run networks to exchange traffic with the broader Internet when appropriate. Reserving 44::/16 ensures that the next generation of amateur radio networking can transition to IPv6 without losing this global connectivity. Critically, an amateur radio allocation in IPv6 prevents fragmentation of address space and routing. If no common prefix were available, each amateur radio group or individual might approach different RIRs for IPv6 subnets. At best, large national- level amateur radio organizations could qualify for IPv6 allocations from RIRs, but this would result in many disparate prefixes (one per RIR or per country/region). That approach is undesirable for the global routing system, since one goal of IPv6 design was to reduce BGP table fragmentation via hierarchical addressing. A single /16 prefix for all amateur radio use can be aggregated (or at least kept within a narrow range) in routing announcements, maintaining a cleaner global routing table than dozens of separate amateur prefixes would. The alternative of using IPv6 ULAs (Unique Local Addresses) was considered by amateurs, but was rejected because ULA space (fc00::/7) is not globally routable. Amateur radio networks must be able to reach the global Internet, and vice versa, to be useful. ULAs would confine ham networks to isolated pockets, undermining one of 44Net’s key benefits interoperability with public networks through gateways and collaboration in open research. It is important to note that individual amateurs cannot realistically obtain IPv6 space under current RIR policies in many cases. RIR qualification rules for IPv6 allocations (e.g., needing to be an ISP or have a plan for thousands of addresses in use) are burdensome for hobbyist experimenters. As one analysis noted, despite the vast IPv6 address supply, "there doesn’t seem to be a way for an individual to obtain a dedicated block of IPv6 addresses" under normal RIR processes. By contrast, ARDC’s stewardship of 44/8 has enabled any licensed ham to get a small block of public IPs for free, without needing to be an ISP or corporate entity. An IPv6 44Net block would likewise be managed by ARDC (or its successors) to provide IPv6 addresses to operators who could never get them otherwise, empowering individuals to innovate at the network edge. This lowers the barrier to entry for digital experimentation, much as 44/8 did in the IPv4 realm.

Technical and Social Distinction from Commercial Internet Use The proposed 44::/16 would be governed by the same usage policies and norms that have guided 44/8. These policies ensure the address space is used in the service of amateur radio’s mission, which is technical experimentation, education, and public service, not profit or private gain. For example, ARDC’s Terms of Service for 44Net explicitly state that addresses "are not permitted to be used for commercial purposes, nor in a manner detrimental to the AMPRNet or to Amateur Radio." Addresses are licensed to individuals (not sold or permanently transferred) and remain ARDC’s property to ensure they aren’t monetized or misused. This governance model will carry into IPv6: the 44::/16 space would be reserved specifically for amateur radio use under amateur radio regulations. This means only holders of an amateur radio license (in any country) and organizations supporting amateur radio would be eligible to obtain sub-allocations, and they must adhere to applicable laws (for instance, identifying their transmissions with call signs, and observing content restrictions such as no obscene or encrypted communications, per national rules). These constraints differentiate 44Net services from the general Internet, providing a self-regulated "community network" flavor within the larger Internet. Much like amateur radio spectrum allocations come with eligibility and usage rules, the IP network allocation is a parallel construct in the Internet number space. The social contract yields benefits: 44Net users have a shared understanding and purpose, and often coordinate to avoid interference or abuse. The network carries traffic that is, by rule, related to amateur radio activities (e.g., remote station control, radio telemetry, VoIP links between repeaters, digipeaters and gateways, etc.), as opposed to general public Internet traffic. Nonetheless, it is crucial to stress that we are not creating a dark-net or a closed garden, 44Net in IPv6 will be fully capable of exchanging traffic with any other Internet hosts, subject to the discretionary interconnection agreements of network operators. In practice, many 44Net sites connect to the Internet at large, and services like radio-to-Internet email gateways (Winlink), ham radio mesh chat portals, and propagation data streams rely on bi-directional connectivity. The global public service enabled by 44Net is a strong motivator for keeping the network interoperable with the broader Internet. Amateur radio networks frequently provide backup and emergency communications when conventional systems fail or are overloaded. For example, regional high-speed ham networks have been used to support emergency operations during wildfires and disasters in the United States, carrying email, voice-over-IP, and even live video for incident response when normal infrastructure was down. Mesh networks like the Bay Area Mesh (BAM) in California use amateur IPv4 addresses to deliver communications to served agencies during disasters, emergencies, and large community events. Similarly, the Rocky Mountain Ham Radio network spans multiple states with microwave links and has provided backup communications during wildfires and public-service events. In all these cases, the ability to interface with the Internet (for example, to deliver an email to a recipient on the public Internet, or to pull weather data from an online API) is essential. Reserving 44::/16 ensures that amateur radio’s emergency and public- service digital networks have a stable, well-known address range in IPv6, facilitating rapid integration with municipal and Internet-connected resources in times of need. Network operators will be aware that traffic from 44::/16 may be originating from volunteer-operated emergency networks, and thus can be handled appropriately (e.g., not mistakenly filtered as illegitimate). Finally, from a research and development perspective, a dedicated IPv6 block for amateur radio opens opportunities for globally coordinated experimentation. Amateur networks have pioneered or incubated ideas that later influenced mainstream networking, for instance, early TCP/IP over radio links, packet radio protocols like AX.25, and wireless mesh routing techniques. Having a common address space where experimental services can be deployed by volunteers worldwide, under real-world conditions but with less risk to commercial operations, is a boon to Internet research. Projects can deploy across the 44::/16 range knowing that the IPs are globally reachable and uniquely tied to the ham community. This sandbox-like environment (with full Internet connectivity) can foster innovation in areas like delay-tolerant networking for telemetry, novel routing schemes, or even embedding call sign information into addresses. The technical distinction of 44Net is that it is an Internet microcosm run by hobbyists and volunteers, which encourages creative solutions, reserving an IPv6 block continues this tradition into the foreseeable future.

Technical Considerations for 44::/16 Usage

Routing and Connectivity The IPv6 prefix 44::/16 will be designated as global unicast address space, intended to be routed on the public Internet. Network operators and Internet Exchange Points should accept and propagate routes for sub-prefixes of 44::/16 in the same manner as any other provider-assigned IPv6 space. (In particular, operators should update any prefix filters that assume all valid global unicast space is under 2000::/3. The 44::/16 block lies outside 2000::/3 and, once reserved by IANA, must be treated as legitimate globally-routed space, analogous to how 2002::/16 was reserved for 6to4 traffic in IPv6.) Entities announcing 44::/16 space will be subject to normal Internet routing policies, they will need to adhere to BGP best practices and obtain an ASN, etc., just as with 44/8 in IPv4 where many amateurs negotiate with their ISP to announce a 44Net subnet via BGP. It is expected that ARDC (or a designated successor operator for 44Net) will coordinate the assignment of sub-prefixes within 44::/16 to amateur radio operators, clubs, and networks. Likely, this will involve a hierarchical delegation (for example, ARDC may allocate /48s or /56s to individual stations or regional groups, and possibly larger blocks like /32 to national-level networks or large organizations). The exact allocation plan is outside the scope of this document, but the key point is that all such assignments will be made under the umbrella of amateur radio usage and through a centralized registry (much as ARDC’s portal manages IPv4 44Net allocations today). This central management will help ensure that no two amateurs inadvertently use the same address space, and that each allocation is backed by a valid amateur radio callsign or organization. In terms of routing architecture, there are a few possible models, all enabled by reserving this single large prefix: Distributed Announcements: Individual amateurs or radio clubs, who have obtained a 44::/L (some length) assignment, may convince their local Internet service provider to route that prefix via BGP to them (for connectivity to their home or club network). This mirrors the current IPv4 practice where hams either use a worldwide IP-in-IP tunnel mesh (historically via amprgw.ucsd.edu) or arrange for direct BGP announcements of their 44/8 subnets. With IPv6, direct routing is more feasible since IPv6 is readily available on many residential connections. We anticipate numerous small BGP announcements globally for 44::/L sub-prefixes (e.g. a /48 per ham who negotiates it). The impact on the global table should be acceptable if those are aggregatable to some degree (for example, possibly one per country or region if coordinated). Network operators should not automatically filter out longer prefixes under 44::/16, as legitimate announcements (even as long as /48) may originate from this space. Regional or Distributed Announcements: Unlike the historical IPv4 model, ARDC will SHALL NOT originate or announce the entire 44::/16 prefix globally. Instead, only the organizations or licensed amateur operators who have received specific sub-prefixes (e.g., /32, /40, or /48 allocations) SHOULD announce their own routes directly or through their local Internet service providers. This decentralized model aligns with current Internet routing best practices and ensures scalability. ARDC or regional coordinators MAY announce limited aggregate prefixes on behalf of groups of clubs, regional networks, or emergency-service consortia to improve reachability where practical, but there will be no single, global 44::/16 announcement from a central gateway. The large size of the IPv6 space makes it feasible for each club or regional grouping to manage its own aggregate without fragmenting the global routing table, while maintaining routing autonomy for individual amateur networks. Internal Ham Mesh Routing: Within the 44Net community, there may be overlay routing (VPNs or mesh networks over RF) interconnecting sites. These can continue to use protocols like RIP44 or new mechanisms to exchange reachability of 44::/16 subnets among participants, analogous to how the IPv4 AMPRNet uses an encapsulated mesh today. The existence of an IPv6 allocation does not mandate how the traffic is carried; it simply gives a consistent addressing scheme. Hams may tunnel IPv6 over existing IPv4 links, or vice versa, during the transition. A crucial consideration is that 44::/16 remains fully open for traffic exchange with any other Internet host. No special handling (like 6to4 relay processing or NAT) is required, packets to/from 44::/16 will be native IPv6 packets routed normally. Network administrators should be aware that although 44Net hosts adhere to amateur radio rules at the application level, they are standard Internet hosts at the network level. Thus, security or policy devices (firewalls, intrusion detection, etc.) should treat 44::/16 traffic similarly to traffic from any other ISP, aside from perhaps recognizing its source as an amateur radio network for traffic engineering or quality-of-service purposes if desired. We discourage any blanket filtering of 44::/16 simply because it is a "special" allocation, unlike IPv6 link-local or ULA addresses, this prefix is intended to carry real, globally-addressable traffic. Some network operators may initially filter 44::/16 as "bogon" (unallocated) space until it appears in the official IANA IPv6 Special-Purpose Address Registry. This behavior is expected during the early transition period. Once IANA formally reserves and publishes the block, those filters will need to be updated to permit routing of 44::/16 and its sub-prefixes. Community outreach and best-current-practice (BCP) updates-similar to those that followed the introduction of 100.64.0.0/10 for Carrier-Grade NAT (CGN) will be required to ensure rapid propagation of the new allocation and prevent inadvertent reachability issues. To assist this process, network operators, IXPs, and transit providers SHOULD proactively whitelist 44::/16 once the IANA registry entry is published, treating it as standard global unicast space. Distributed Announcements and Registry Role: ARDC will function solely as the registrar and coordinator of address assignments within 44::/16 and SHOULD NOT operate as a network provider or originate global BGP announcements for the prefix. Each licensed amateur, club, or affiliated organization receiving an allocation (for example, /32, /40, or /48) MAY announce their own sub-prefix through their local Internet service provider or upstream network as appropriate. Regional or national amateur organizations MAY choose to advertise aggregated sub-prefixes covering multiple local allocations to improve reachability, but there will be no single worldwide advertisement of 44::/16. This model keeps ARDC in its proper administrative role maintaining the allocation registry and ensuring uniqueness while leaving routing control entirely with the independent operators who use the space.

Reverse DNS and Naming IANA should delegate the reverse DNS zone corresponding to 44::/16 to the ARDC or its designated DNS operators. In IPv6, reverse lookups are under the .ip6.arpa domain. For a /16, the delegation will be somewhat unusual because it is on a nibble boundary. The 44::/16 prefix in hex is 0x0044::/16, i.e., addresses start with the 16-bit value 0x0044. The reverse DNS zone could be considered as 4.4.ip6.arpa (representing all addresses with the first two hex digits "44") and be delegated to ARDC name servers. ARDC already manages forward DNS for the ampr.org domain and the in-addr.arpa for 44/8 (delegated through ARIN’s legacy processes). For IPv6, ARDC can similarly manage PTR records for any assigned addresses within 44::/16. This will allow reverse DNS resolution of amateur radio hosts. Typically, 44Net hostnames are under the ampr.org domain (often incorporating call signs or location identifiers), and we expect the same practice to continue. Proper reverse DNS is not only a convenience; it also prevents misconfigured reverse lookups that some services use for security checks.

Addressing Plan and Prefix Utilization While the detailed addressing plan will be developed by the amateur community, we note some technical guidelines and possibilities: Size of End-User Assignments: It is anticipated that end-user networks (e.g., a ham’s home station or a club’s network) will receive at least a /64 (as that is the IPv6 subnet size required for SLAAC autoconfiguration). However, more likely a /48 per user may be standard, as is common in IPv6 for giving ample subnet space. A /48 allows 65,536 subnets for the user, effectively unlimited for any foreseeable amateur radio station’s needs. Even if every individual assignment were a /48, the 44::/16 block can accommodate approximately 4.3 billion /48s, far exceeding the number of amateur radio operators on the planet. In other words, 44::/16 is extremely generous in size, which is appropriate to ensure no shortage and to mirror the "large swath" philosophy of the original 44/8. Hierarchical Structure: The high-order bits within 44::/16 could be subdivided geographically or by administrative region if desired. For example, the amateur community could decide that 44:0000::/24 goes to Region 1 (Europe/Africa), 44:0100::/24 to Region 2 (Americas), 44:0200::/24 to Region 3 (Asia/Pacific), etc., aligning with IARU or ITU regions. Under each region, country-based sub-allocations could be made (similar to country coordinators who handled IPv4 44Net allocations in the past). Alternatively, ARDC may manage it as a flat space and allocate sequentially as requests come. These decisions will be made by the amateur community governance. The IETF’s concern is only that such structuring is possible and facilitated by having a large contiguous block. Interoperability with IPv4 44Net: During transition, many amateur systems will run dual-stack on both 44.x.x.x addresses and 44:: addresses. Gateways will likely be set up to bridge IPv4-only radio nodes to IPv6-only nodes via protocol translation or tunn translation or tunneling. One foreseeable mechanism is to use NAT64 or SIIT translators on the border between IPv6 44Net and legacy IPv4 44Net, allowing, for example, an old packet BBS on 44.1.2.3 to communicate with an IPv6-only station at 44:abcd::1. Because the addressing shares the "44" prefix conceptually, operators can implement simple rules (perhaps mapping the IPv4 44/8 space into a subset of 44::/16 for translation). While not strictly required for IANA to reserve the block, the alignment of numbering (44 in both families) is mentally convenient and can ease documentation and tooling.

Operational Security and Abuse Prevention Although primarily a policy matter, it is worth noting technically that ARDC and the amateur community will likely maintain filters to ensure that only authorized (licensed) users announce or use 44::/16 addresses. Currently, for IPv4, there is an "encapsulation gateway" and registration system; a similar approach could be taken where unregistered use of 44::/16 is deterred. From the perspective of the wider Internet, however, the security considerations are straightforward: treat 44::/16 like any other customer IP range. If a network sees traffic from an apparent 44::/16 address that is not also properly announced in BGP by an authorized ASN, that traffic could be spoofed (as with any prefix). Network operators should apply BCP38 (ingress filtering) at their edges, and if an ISP is providing transit for an amateur station announcing 44::/L, they should ensure the announcement is authorized (perhaps ARDC will publish routing objects or an RPKI ROA for the allocations to assist in validation).

Security Considerations Reservation of 44::/16 does not introduce new vulnerabilities to Internet protocols; it simply earmarks an address range for a specific community. The addresses in this range should be considered as normal global IPv6 addresses from a security standpoint. That said, some characteristics of their use are notable: Open Access vs. Authorized Use: Only licensed amateur operators will be authorized to use 44::/16 addresses, but there is no technical enforcement of this at the IP level. In theory, a malicious party could spoof or squat on 44:: addresses. This is no different from misuse of any unallocated or special-purpose prefix. Best common practices like filtering non-routed prefixes and source-address validation mitigate this risk. Once IANA allocates 44::/16 to ARDC, any route originating from that space should be from ARDC or its designees; others can be viewed as rogue. Amateur Traffic Content: Due to amateur radio regulations, much of the traffic on 44Net may be in the clear (unencrypted) or contain identifying information like call signs. Attackers on the Internet could potentially eavesdrop on or target ham radio nodes knowing they might have less hardened services (since many are run by volunteers). The community should remain mindful of general cybersecurity practices (firewalls, patches) even while operating in the spirit of open experimentation. The reservation itself does not exacerbate these issues-rather, having a known prefix might even allow network defenders to more easily recognize and monitor 44Net traffic patterns if needed. Emergency Communications: During emergency use of ham networks, confidentiality of certain traffic might be a concern (e.g., personal information in an email over Winlink). Amateur rules typically forbid encryption, so sensitive data is sometimes sent in plaintext out of necessity. Users should be cautious about what data they transmit. Again, this is a general caution and not created by the IPv6 allocation; the allocation simply extends the environment where these longstanding amateur radio practices apply. Overall, the security posture of 44::/16 will depend on the operational security of those who use it. By keeping the space identifiable and managed (via ARDC), it may actually aid incident response, for example, abuse complaints about a 44:: address can be forwarded to a well-known team in the amateur community. The cooperative nature of that community is such that security issues (intrusions, misuse) are likely to be resolved quickly through out-of-band coordination (mailing lists, etc.).