Guide for ISPs and upstream providers
This guide is for an ISP, hosting company, cloud provider, or transit provider whose customer wants to route a 44Net IPv4 prefix.
44Net is a community network for amateur radio, experimentation, education, and research that includes globally routable IPv4 address space stewarded by Amateur Radio Digital Communications (ARDC).
ARDC remains responsible for the address space. We authorize eligible users to use particular subnets, but we do not sell or transfer them. The 44Net End User License Agreement contains the formal terms.
In practical terms, your customer has permission from ARDC to use a 44Net subnet, and they want to announce it to the global routing table through your network.
This guide explains how the pieces generally fit together. It is not an agreement between ARDC and the provider. You and your customer can arrange the service according to your normal policies and practices. The customer remains responsible for following ARDC's terms.
ARDC's role
ARDC administers the address space, approves its use, and supplies documentation that an approved user is authorized to announce a prefix.
ARDC is not the customer's ISP. ARDC does not itself provide transit, peering, or BGP sessions, nor does it operate the customer's router, circuit, or hosting environment. All that is done by the customer and its chosen provider.
Common service arrangements
Providers support customer prefixes in several ways. For example:
- Provider-originated route: the provider originates the customer's prefix from the provider's ASN and delivers the traffic to the customer over a circuit, VLAN, tunnel, or hosted environment.
- BGP with the customer: the provider establishes a BGP session with the customer. The customer advertises the prefix using its own public ASN or a private ASN assigned or accepted by the provider.
- Customer-operated multihoming or transit: the customer operates a router under its own public ASN and establishes BGP sessions with one or more transit providers or peers.
ARDC does not require any particular arrangement. Which one works depends on the services you offer and what you and your customer decide to set up.
Information the provider and customer should agree on
Before activation, confirm at least the following where relevant:
General
- The exact IPv4 prefix to be announced
- Whether the provider or customer will originate the route
- The public origin ASN that will appear in the global routing table
- Any private ASNs used only between the customer and provider
BGP session details
- BGP neighbor addresses, address families, authentication, timers, and maximum-prefix limits, where applicable
- Import and export policy, including accepted prefix lengths and AS-path requirements
- Any provider communities the customer may use, including blackhole or traffic-engineering communities
Practical details
- How traffic will be delivered to the customer
- Which party is responsible for the routed interface, VLAN, tunnel, or circuit
- Routing-security and anti-spoofing filters, including acceptance of the 44Net source prefix from the customer
- Any relevant operational contacts, maintenance procedures, monitoring, and the process for withdrawing the route
Documentation and validation ARDC can provide
Letter of Authorization
The customer can download a Letter of Authorization (LOA) from the 44Net Portal. The LOA identifies the approved prefix and authorizes the customer to advertise it using BGP. The customer should give the current LOA to the provider.
The LOA shows the prefix, the approved origin ASN or ASNs, and how long the authorization is valid. It confirms that the customer may advertise the prefix, but it does not transfer the address space or create a service agreement between ARDC and the provider.
The ASN in the LOA should match the public origin ASN you expect to see. If the design changes, ask the customer to update the Portal, generate a new LOA, and send it to you before changing the origin, as this allows ARDC to maintain accurate records and ensure compliance with the EULA.
Assignment validation
ARDC can help a provider confirm that the customer is currently authorized to use the prefix and that the proposed origin ASN matches ARDC's records. The customer's LOA includes a QR code linking to a public 44Net Portal record showing the prefix, authorized user, issue and expiry dates, BGP authorization, and authorized origin ASN or ASNs.
These details should agree with the LOA and applicable IRR route objects. Providers may contact noc@ardc.net, or the administrative or technical contacts published in Whois/RDAP, to confirm an authorization or resolve a discrepancy.
Internet Routing Registry objects
For approved direct announcements, ARDC can currently create route objects in RADB and/or ALTDB.
IRR records should identify the same prefix and public origin ASN that will be visible in BGP. A private ASN used only on the customer-provider session is not normally the public origin recorded in the route object.
Current limitations
No RPKI ROA
ARDC's 44Net ranges are administered by ARIN, which does not offer RPKI for legacy resources. ARDC cannot currently create ARIN-issued Route Origin Authorizations (ROAs). ARDC also does not currently operate a separate RPKI trust anchor for 44Net.
The absence of a ROA means the route is RPKI NotFound, not RPKI Invalid. A provider whose policy requires every customer route to be RPKI Valid may be unable to accept the prefix under that policy. See RPKI and ROAs on 44Net for the current explanation and references.
No customer-specific ARIN Whois or RDAP record
ARDC does not SWIP customer subnets, because the address space is leased to the customer, not transferred. We also cannot currently add customer- or provider-specific text to the parent ARIN Whois or RDAP record.
If your process requires a customer-specific ARIN organization, netblock record, remark, or other registry text, an LOA or third-party IRR object may not be enough. It is worth checking whether you can handle the request as an exception before the customer orders or builds the service. ARDC is generally happy to discuss exceptions further.
Frequently asked questions
Does ARDC provide peering or transit?
No. ARDC authorizes eligible users to use address space. Those users arrange Internet connectivity, transit, and any peering on their own behalf.
Will ARDC establish BGP with us?
No. The BGP relationship is between the customer and provider, or between networks selected by the customer. ARDC is not a party to the BGP session.
Will ARDC announce the customer's prefix?
No. The customer and provider decide which network will originate the prefix and how traffic will reach the customer.
Does the customer use ARDC's ASN?
No. The customer and provider decide which of their own ASNs will appear in the global routing table. ARDC does not operate a BGP session or originate the route.
Does the customer need a public ASN?
That depends on the provider's design. A provider may originate the route from its own ASN, establish BGP using a private ASN on the customer-facing session, or require the customer to use a public ASN. A customer normally needs its own public ASN when it originates the route independently, especially when using more than one upstream.
Can the provider originate the prefix from its own ASN?
Yes. If you will originate the route, your ASN should be recorded as the public origin in the customer's ARDC records, LOA, and applicable IRR route objects. A private ASN used only on the customer-facing session should not be recorded as the public origin if you remove or replace it before announcing the route globally.
Is the customer the owner of the prefix?
No. ARDC remains owner and steward of the address space and authorizes the customer to use the approved prefix subject to ARDC's terms. The LOA documents authority to advertise the prefix; it does not in any way transfer ownership.
Can we accept a route without a ROA?
That is a provider policy decision. There is currently no ROA for the route, so validation should return NotFound. Providers that permit NotFound customer routes may use the LOA, ARDC confirmation, and accepted IRR objects as supporting evidence.
What prefix length should we expect?
Most direct BGP assignments are between /22 and /24. Confirm the exact approved prefix in the customer's current LOA and ARDC's records.
Can the customer announce a more-specific route?
Check that each route is covered by the customer's current ARDC authorization and appears in the LOA. It should also have a corresponding IRR route object if your process requires one. The customer can ask ARDC to authorize a more-specific route. ARDC does not assign or authorize prefixes smaller than /24 for direct announcement, and it does not authorize more-specifics that are not covered by the approved prefix.
How long does the authorization remain valid?
The current LOA includes the validity dates. Ask the customer for a new LOA when the authorization is renewed or when the prefix or public origin ASN changes. If your systems do not track the expiry date, contact noc@ardc.net so we can work out a practical notification process.
Who handles routing incidents or abuse?
The customer and its provider handle operation of the BGP session, route propagation, traffic delivery, and the customer's systems. Contact noc@ardc.net when an incident concerns the validity of a 44Net authorization, an ARDC-maintained routing record, or coordination with ARDC. The customer remains responsible for responding to abuse involving its assigned resources under the applicable ARDC terms.
Contact
For authorization checks, routing-record questions, or coordination concerning an approved 44Net prefix, it is best to contact noc@ardc.net. Sending email to the administrative or technical contacts listed in the ARIN Whois record is also acceptable.
When contacting ARDC, please include:
- The exact prefix
- The proposed public origin ASN
- The customer's name or organization
- The provider's name and network operations contact
- The specific record, document, or policy question that needs to be resolved
Do not send BGP passwords or other credentials by email.