Summary

  • ARIN's current Number Resource Policy Manual, section 4.2.3.6, says a downstream need to multihome alone justifies a /24 under its reassignment rule. The customer must give the supplying ISP contact information for every upstream and use a border routing protocol with it. Only one upstream may provide a /24 on that justification without more evidence.
  • Section 2.7 defines multihoming as full-time connectivity from more than one ISP with at least one prefix announced by at least two upstreams. Section 4.2.3.3 separately recommends that a customer leaving an ISP return its addresses and renumber into the new provider's space; the original ISP should allow sufficient time.
  • ARIN's adopted 2001 policy archive explains the bargain's origin: multihoming need could justify a /24 regardless of host counts. The current manual governs now. Neither source identifies a real customer whose provider change incurred a measured renumbering cost.

Two upstreams solve a path problem. An address block solves a naming problem that outlives a single path. ARIN's policy recognizes the first problem explicitly. Its definition of multihomed calls for full-time connectivity from more than one ISP and at least one routing prefix announced by at least two upstreams. Buying a backup circuit is a start; the routing relationship is part of the definition.

The reward for meeting that need appears in section 4.2.3.6. A downstream customer can use the need for multihoming itself as justification for a /24. The clause sits inside ARIN's rules on ISPs reassigning and reallocating space to customers. It does not describe ARIN handing a new provider-independent block straight to the end user. The ISP supplying the /24 must receive contact information for all of the customer's upstreams, and the customer must use a border routing protocol with that ISP.

Then comes the line that turns two connectivity suppliers into one address supplier. A customer may receive a /24 from only one upstream under this policy without additional justification. The second ISP can carry traffic for the customer and announce the prefix, but the bare multihoming argument cannot be used a second time to demand another /24 from that ISP. The rule is a shortcut for one block, not a two-for-one address coupon.

ARIN also tells the ISP how to prove the assignment. It may give ARIN the customer information collected under the clause or identify the customer's Autonomous System Number. Those records matter if ARIN reviews the ISP's address use when it seeks more space. Section 4.2.3.7 expects ISPs to show efficient use with assignment histories, and section 4.2.3.7.1 requires registration of IPv4 reassignments at /29 or larger. A /24 taken through the multihoming shortcut becomes a traceable part of the provider's resource ledger.

The arrangement has history. Policy 2001-2 was adopted and implemented in 2002. Its archived text says multihoming need could justify a /24 reassignment regardless of host requirements. It already required contact details for every upstream and allowed the shortcut from only one of them. The old problem was how to give a customer enough address space for its routing arrangement without making the address count alone decide. The old answer carried a provider tie from the start.

That tie becomes visible when the customer changes suppliers. Section 4.2.3.3 of the current manual discourages fragmenting an ISP's contiguous address blocks and encourages ISPs to require customers to return addresses when they change providers. It recommends that a departing customer return the old network addresses and renumber into the new provider's space. The original ISP should allow sufficient time for that process. The policy gives no universal number of days. It asks operators to absorb a real migration task while protecting the provider's aggregate.

This is the bargain a procurement team can miss. The customer may have two live carriers and one advertised prefix. That can help the network survive a path failure. It does not make the provider-supplied address block travel freely with the customer when the supplier relationship ends. The policy's provider-return recommendation puts the future exit question beside today's multihoming design. How long will renumbering take for DNS records, firewall rules, allowlists, peering filters and customer endpoints tied to the block? Those are engineering questions to answer before the provider change, not after a contract dispute.

The rule does not tell us that any particular route was accepted everywhere, that a named operator had to surrender a block, or what a migration cost. A dated reassignment and provider-change record would measure one case. The published policy already draws a clean boundary: two providers may carry the path, while one provider is the source of the easy /24.