IP Delegation Explained: Address Space, Prefixes, DNS, and Routing

What is IP delegation?

IP delegation is the controlled handoff of responsibility for an IP address block or prefix from one administrative boundary to another. The receiving party may be allowed to plan subnets, assign addresses, operate reverse DNS, or request routing changes, but the exact authority comes from the parent allocation, registry policy, service agreement, and operating records.

The phrase is ambiguous. It can describe public number-resource administration, an internal IPAM hierarchy, DHCPv6 Prefix Delegation, or reverse-DNS control. These are related layers, not interchangeable proof of ownership, routing, or legal authority.

Which kind of IP delegation do you mean?

IP delegation meanings and their evidence

Layer	What is handed off	Evidence to check	What it does not prove
Internet number resources	Administrative responsibility for public IPv4, IPv6, or AS number resources under a registry or parent network	Current RIR policy, RDAP or registry record, agreement, exact prefix, dates, and permitted use	That the prefix is routed, accepted by an upstream, or transferred to a new holder
Internal address management	A parent prefix is divided among regions, sites, tenants, or teams	Approved IPAM hierarchy, overlap checks, owner, purpose, status, and lifecycle record	Public registry authority or internet reachability
DHCPv6 Prefix Delegation	A server delegates one or more IPv6 prefixes to a requesting client, commonly a customer-edge router	IA_PD state, delegated prefix, preferred and valid lifetimes, renewal, and installed routes	A permanent allocation or control of a public registry record
Reverse DNS	Authority to publish PTR records below an in-addr.arpa or ip6.arpa zone	Parent-zone delegation, name servers, DNSSEC state if used, and tested PTR answers	Address-resource rights, forward DNS, or BGP authorization
Routing authority	Permission and technical data used to announce a prefix from an origin ASN	Contract or LOA, upstream acceptance, IRR objects, ROA state, BGP observations, and prefix filters	Ownership, transfer approval, reachability, or a valid reverse-DNS delegation

How public IP address delegation works

The Internet Numbers Registry System is hierarchical. IANA coordinates the top of the globally unique IPv4, IPv6, and AS number spaces and allocates address pools to the five Regional Internet Registries. RIRs serve Local Internet Registries, internet service providers, organizations, and other eligible customers under the policies developed in each region. A provider or LIR can then assign or sub-allocate resources where the applicable policy and agreement allow it.

1. Start with the parent authority. Identify the RIR, LIR, provider, or organization from which the resource is derived. Use the current RDAP or registry record and the governing agreement rather than a logo, route announcement, or copied WHOIS page.
2. Name the exact resource. Record the CIDR, address family, parent prefix, status, intended network, region, and time boundary. “Some IPs” is not an auditable delegation.
3. Apply the governing terminology. Allocation, assignment, sub-allocation, sub-assignment, and delegation are policy terms whose permitted use varies by registry and provider. Check the current source policy instead of assuming one global definition.
4. Keep registration and routing separate. Registry data records number-resource administration. BGP decides which routes are announced and selected. A correct record does not create a route, and a visible route does not prove registry authority.

For the five service regions and an RDAP lookup path, use the Regional Internet Registry guide.

Delegation, allocation, assignment, and address configuration

These words answer different questions. An allocation commonly supplies a block to an entity that can use it for its own network or make permitted downstream assignments. An assignment commonly supplies space for a specific end network. A delegation emphasizes the responsibility or control passed to a child boundary. Exact definitions and downstream rights come from the applicable policy and contract.

Configuring one address on an interface is a separate data-plane action. DHCP, static configuration, Router Advertisements, and cloud APIs can assign addresses inside an approved pool without changing the public registry hierarchy. An IPAM entry can document that action, but typing a prefix into an IPAM platform does not create authority over it.

How DHCPv6 Prefix Delegation differs

DHCPv6 Prefix Delegation, or DHCPv6-PD, is a protocol mechanism. A server provisioned with available prefixes chooses one for a requesting client. The client can then subnet that delegated prefix and advertise the resulting subnets on downstream links. The delegation carries preferred and valid lifetimes; the client must stop using the prefix when its valid lifetime expires unless it is renewed.

A downstream device may show only its on-link /64. That address does not reveal the larger site prefix delegated to the router. Inspect the router's IA_PD state, current lifetimes, and routes. The IPv6 prefix guide explains how to read those boundaries.

Reverse DNS delegation is another control plane

Reverse DNS maps an address to a PTR name under in-addr.arpa for IPv4 or ip6.arpa for IPv6. The parent network or registry can delegate the corresponding reverse zone, or operate PTR records on the customer's behalf. IPv4 blocks smaller than a /24 can require a classless delegation method rather than a simple octet-boundary zone.

Record who changes PTR data, which name servers are authoritative, the change and rollback process, and what happens when the address delegation ends. A working PTR record does not prove forward DNS, mail acceptance, resource ownership, or routing. See the reverse DNS guide for verification steps.

BGP, IRR, LOAs, and RPKI do different jobs

• BGP distributes routes between autonomous systems. A route observation shows that a prefix was announced and propagated to that vantage point.
• An LOA can document one party's permission for a specific provider or ASN to perform named actions. Its value depends on the issuer's actual authority and the relying party's checks.
• IRR objects can describe routing policy and help build filters. Their presence and authentication model do not by themselves prove registry rights or live reachability.
• A ROA states which origin ASN is authorized for a prefix and the allowed maximum length. Route Origin Validation classifies an observed route as Valid, Invalid, or NotFound relative to available RPKI data; it does not establish legal ownership, contract scope, or end-to-end delivery.

Keep these facts in separate fields and reconcile them during activation, change, renewal, and return. The RPKI and ROA guide and ASN guide cover the routing boundary in more detail.

A worked IP delegation example

Suppose an organization is authorized to plan the documentation prefix 2001:db8:1200::/48. It delegates 2001:db8:1200:0100::/56 to Site A and 2001:db8:1200:0200::/56 to Site B. Each site can create approved /64 subnets inside its /56.

• The parent IPAM record preserves the /48, the source of authority, and the rule that child prefixes cannot overlap.
• Each /56 records the site, owner, purpose, start date, status, and return condition.
• DHCPv6-PD, static routing, or another approved mechanism delivers the prefix; that mechanism is recorded separately from administrative authority.
• Reverse DNS, route policy, firewall rules, monitoring, and RPKI are separate work items with their own owners and evidence.
• When Site B closes, the prefix moves through quarantine and validation before it can be reused; deleting one row immediately would risk stale routes, DNS, logs, and configuration.

The prefix is reserved for documentation and is not a deployable internet resource. The example shows the hierarchy and lifecycle, not a recommendation for every site's prefix size.

What should an IP delegation platform do?

Controls to verify in an IP delegation or IPAM platform

Control	What to verify	Failure the control prevents
Authority source	Parent registry or provider, agreement, exact prefix, policy class, permitted downstream use, and evidence timestamp	Treating a manually entered prefix as authorized inventory
Hierarchy and math	Containment, non-overlap, reserved ranges, address family, canonical CIDR, and available child sizes	Duplicate or out-of-parent assignments
Workflow and access	Request, approval, separation of duties, role and tenant boundaries, expiry, renewal, revoke, quarantine, and return	Unreviewed changes and invisible reuse
Separated control planes	Registry, contract, DHCP/IPAM, DNS, IRR, RPKI, BGP, firewall, abuse, and monitoring facts stored without collapsing them into one status	A green badge falsely claiming complete authority or reachability
Audit and recovery	Stable IDs, actor, before-and-after values, observation time, source, approvals, exports, backups, and rollback	Changes that cannot be attributed or reconstructed
Integrations	Read and write boundaries for DHCP, DNS, cloud, RIR/RDAP, IRR, RPKI, configuration management, and alerting	One integration silently overwriting another system of record

A useful platform exposes uncertainty and conflicts. It should show when a registry record, contract, route, ROA, PTR zone, or local assignment disagrees, and leave the resolution to an authorized operator with the complete evidence.

IP delegation runbook

1. Verify authority. Identify the parent prefix, issuing registry or provider, current policy, agreement, holder, and the person allowed to approve the child delegation.
2. Define the requirement. Record address family, capacity, CIDR, sites or tenants, growth, term, geography, application, and whether the child can create further assignments.
3. Reserve the exact child prefix. Prove containment and non-overlap, record stable IDs, and stop competing allocation workflows from selecting it.
4. Prepare every control plane. Assign owners for delivery, routing, LOA, IRR, RPKI, reverse DNS, firewall, abuse contact, monitoring, and support.
5. Activate with evidence. Confirm the installed prefix, routes, DNS, policy, reachability, logs, and observation time from approved vantage points. Do not mark the delegation complete from a configuration request alone.
6. Operate and reconcile. Monitor expiry, utilization, route and ROA drift, DNS, abuse, contact changes, and child records. Preserve factual history rather than rewriting it into the current state.
7. Renew or return safely. Withdraw routes, revoke credentials and authorizations, remove DNS and child assignments, preserve required records, quarantine the range, and verify that no live dependency remains before reuse.

Common IP delegation mistakes

• Calling every DHCP address assignment a public number-resource delegation.
• Assuming a route announcement, LOA, IRR object, ROA, PTR record, or IPAM row proves ownership.
• Using “allocation” and “assignment” as universal synonyms without checking the current RIR or provider policy.
• Delegating a prefix without an expiry, renewal, return, and stale-configuration plan.
• Letting one platform status hide disagreement among registry, contract, DNS, routing, and operating evidence.
• Reusing returned space before old routes, DNS, allowlists, reputation records, telemetry, and customer configuration are cleared.

Frequently asked questions

What does IP delegation mean?

It means passing defined responsibility for an IP prefix or address pool to another administrative boundary. The delegated rights and duties depend on the parent authority, policy, agreement, technical delivery, and lifecycle records.

What is the difference between an IP allocation and an assignment?

An allocation commonly supports further permitted distribution or the recipient's own use, while an assignment commonly supports a specific end network. Exact definitions and downstream rights vary by RIR, provider, and service, so use the governing policy rather than a universal shortcut.

Is DHCPv6 Prefix Delegation the same as RIR delegation?

No. DHCPv6-PD is a protocol that delivers a prefix with preferred and valid lifetimes from a server to a client. RIR or provider delegation is the administrative authority and policy context from which that prefix originates.

Does RPKI prove who owns an IP block?

No. A ROA authorizes an origin ASN for a prefix and maximum length within the RPKI system. It does not prove legal ownership, contract rights, transfer completion, route propagation, or service reachability.

What is an IP delegation platform?

It is usually an IPAM or network-automation system that records parent and child prefixes, approvals, assignments, lifecycles, and integrations. Evaluate whether it preserves the source of authority, separates control planes, prevents overlap, exposes conflicts, and keeps a reconstructable audit history.

Can leased IPv4 space be delegated to a customer?

Only within the holder's authority, current RIR and provider policy, and the signed service agreement. Define the exact prefix, permitted use, routing and DNS responsibilities, RPKI and IRR changes, abuse process, term, renewal, return, and any downstream-assignment restrictions before activation.

Primary standards and registry sources

• IANA Number Resources
• Number Resource Organization: Regional Internet Registries
• RFC 7020: The Internet Numbers Registry System
• RFC 8415: DHCP for IPv6 and Prefix Delegation
• RFC 3849: IPv6 Address Prefix Reserved for Documentation
• RFC 2317: Classless IN-ADDR.ARPA Delegation
• RFC 6480: An Infrastructure to Support Secure Internet Routing
• RFC 9083: RDAP JSON Responses

When the delegation involves leased public IPv4

A lease can provide a time-bounded right to use an IPv4 prefix without transferring the resource holder's registry position. Before activation, name the holder, customer, exact CIDR, permitted use, origin ASN, upstream, LOA, IRR and RPKI owners, reverse-DNS operator, reputation evidence, abuse contact, renewal window, return steps, and tested replacement path.

i.lease can help coordinate that resource and operating workflow within an agreed scope. Availability, registry treatment, route acceptance, reputation, geolocation, and application access still require current evidence and cannot be guaranteed by a delegation record alone. Review managed IPv4 leasing after the technical and authority boundaries are clear.