Hubbry Logo
Prefix delegationPrefix delegationMain
Open search
Prefix delegation
Community hub
Prefix delegation
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Prefix delegation
Prefix delegation
Prefix delegation
View on Wikipedia
from Wikipedia

IP networks are divided logically into subnetworks. Computers in the same subnetwork have the same address prefix. For example, in a typical home network with legacy Internet Protocol version 4, the network prefix would be something like 192.168.1.0/24, as expressed in CIDR notation.

With IPv4, commonly home networks use private addresses (defined in RFC 1918) that are non-routable on the public Internet and use address translation to convert to routable addresses when connecting to hosts outside the local network. Business networks typically had manually provisioned subnetwork prefixes. In IPv6 global addresses are used end-to-end, so even home networks may need to distribute public, routable IP addresses to hosts.

Since it would not be practical to manually provision networks at scale, in IPv6 networking, DHCPv6 prefix delegation (RFC 3633; RFC 8415 § 6.3) is used to assign a network address prefix and automate configuration and provisioning of the public routable addresses for the network. In the typical case of a home network, for example, the home router uses DHCPv6 to request a network prefix from the ISP's DHCPv6 server. Once assigned, the ISP routes this network to the customer's home router and the home router starts advertising the new address space to hosts on the network, either via SLAAC or using DHCPv6.

DHCPv6 Prefix Delegation is supported by most ISPs who provide native IPv6 for consumers on fixed networks.

Prefix delegation is generally not supported on cellular networks, for example LTE or 5G. Most cellular networks route a fixed /64 prefix to the subscriber. Personal hotspots may still provide IPv6 access to hosts on the network by using a different technique called Proxy Neighbor Discovery or using the technique described in RFC 7278. One of the reasons why cellular networks may not yet support prefix delegation is that the operators want to use prefixes they can aggregate to a single route. To solve this, RFC 6603 defines an optional mechanism and the related DHCPv6 option to allow exclusion of one specific prefix from a delegated prefix set.

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Prefix delegation

View on Grokipedia
from Grokipedia
Prefix delegation is a mechanism defined in the for () that enables a delegating router, such as a provider , to automatically assign one or more prefixes to a requesting router, typically (CPE), for use in configuring downstream networks. This process supports the delegation of prefixes across administrative boundaries without requiring detailed knowledge of the requesting router's , facilitating scalable management in environments like residential or enterprise connections. The delegation operates through a series of message exchanges: the requesting router initiates with a Solicit message containing an Identity Association for Prefix Delegation (IA_PD) option, to which the delegating router responds with an Advertise message; the requesting router then sends a Request message, and the delegating router replies with a Reply message including the assigned prefixes via IA_PD Prefix options, complete with preferred and valid lifetimes. Prefixes are managed with renewal timers (T1 and T2) to ensure timely reconfiguration before expiration, and the mechanism supports both static, long-lived assignments and dynamic, short-lived ones based on policy. considerations, including authentication via or DHCPv6-specific methods, are recommended to prevent unauthorized delegations. In operational practice, prefix delegation is essential for at end-user sites, allowing ISPs to allocate blocks such as /48 (supporting up to /64 subnets) or /56 (supporting 256 /64 subnets) to CPE routers, which can then subnet these for local area networks, reducing renumbering needs and enabling services like stable DNS resolution. This approach promotes persistent prefix assignments for reliability during events like power outages and is adaptable across link technologies, with CPE devices able to request preferred prefix lengths. Typical use cases include broadband access networks where the CPE uses the delegated prefix for LAN-side interfaces, distinct from WAN addressing, to ensure unique addressing and simplify troubleshooting.

Overview

Definition and Purpose

Prefix delegation (PD) is a mechanism within the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) that enables a requesting router, typically customer premises equipment (CPE), to obtain one or more IPv6 prefixes from a delegating router, such as an ISP's provider edge router. These prefixes, often in the range of /48 to /64 in length, allow the requesting router to automatically configure and assign subnets to downstream interfaces or links without manual intervention. Unlike traditional DHCP, which primarily assigns individual host addresses, PD focuses on delegating routable prefix blocks to support hierarchical addressing in IPv6 networks. The primary purpose of prefix delegation is to provide scalable, dynamic assignment of prefixes across administrative boundaries, addressing the need for automated network configuration in large-scale deployments. It fulfills 's hierarchical addressing model by allowing ISPs to delegate prefixes to customer sites, enabling those sites to and route traffic internally while maintaining global reachability. This contrasts with IPv4 practices, where address scarcity often necessitated (NAT); in , PD leverages the vast address space to support direct, routable assignments. Key benefits of PD include reduced administrative overhead for service providers through automated prefix management and reclamation, as well as simplified renumbering when sites change providers. It promotes end-to-end connectivity by providing globally unique prefixes, eliminating the need for NAT in most scenarios and facilitating seamless communication between devices. Additionally, PD supports the abundance of IPv6 addresses by typically delegating /56 prefixes to residential users, allowing subdivision into multiple /64 subnets for various local area networks (LANs). For instance, a home router might request a /56 prefix and divide it into 256 /64 subnets—one for the main LAN, another for guest networks, and others for IoT devices—ensuring efficient use without address exhaustion.

Relation to IPv6 Addressing

IPv6 addresses are 128-bit identifiers, structured to support hierarchical and large-scale deployment. The address format divides the 128 bits into three main parts: a global prefix (typically 48 bits for end-site assignments), a ID (16 bits), and an interface identifier (64 bits). This structure enables efficient aggregation of routes in the global , where the global prefix identifies the network allocation from a provider or registry, the ID allows for up to 65,536 local subnets within a site, and the interface ID uniquely identifies devices on a . The addressing model employs a hierarchical approach to manage address distribution, distinguishing between provider-independent (PI) prefixes, which are globally routable and portable across providers, and provider-allocated (PA) prefixes, which are assigned by an (ISP) from their own allocation and aggregated under the provider's announcements. Prefix delegation primarily operates with PA prefixes, allowing ISPs to dynamically assign blocks of addresses to sites while maintaining route aggregation to minimize global growth. This PA model supports scalability in provider networks, as prefixes can be reclaimed and reassigned upon changes, unlike PI prefixes which require separate advertisements. Stateless Address Autoconfiguration (SLAAC) enables hosts to generate their own addresses using Router Advertisements (RAs) from a local router, combining the advertised prefix with an interface identifier derived from the host's or a privacy extension. However, SLAAC is limited to single-link configurations and does not support the delegation of prefixes to downstream routers for creating multiple internal subnets, as it relies on a fixed prefix per link without mechanisms for subdividing or propagating larger blocks. This necessitates prefix delegation for scenarios where customer edge devices require dynamic provisioning of to support internal . serves as the transport mechanism for such delegation. IPv6's vast , with 2^128 possible addresses overall and 2^64 unique identifiers per /64 , fundamentally avoids the issues of IPv4 by enabling generous without fragmentation or exhaustion concerns. Prefix delegation leverages this abundance by allowing providers to assign /56 or /48 blocks to sites, each supporting thousands of /64 subnets, ensuring long-term scalability for end-user networks while preserving global routing efficiency.

Protocol Mechanics

DHCPv6 Prefix Delegation Options

DHCPv6 prefix delegation relies on specific options defined in the protocol that enable requesting routers, such as , to obtain prefixes from delegating routers for management and sub-delegation. The core mechanism is provided by the Identity Association for Prefix Delegation (IA_PD) option, which encapsulates the association between a client and the delegated prefixes. This option, with code 25, includes a 4-octet IAID to uniquely identify the prefix delegation instance, followed by 4-octet T1 and T2 timers that determine renewal intervals—the T1 value signals when the requesting router should renew the prefixes with the original delegating router, while T2 indicates when to seek renewal from any available delegating router. The IA_PD option also contains sub-options for the actual prefixes, with recommended T1 and T2 values set to 50% and 80% of the shortest preferred lifetime among the delegated prefixes, respectively. Clients typically set T1 and T2 to zero in requests, allowing servers to assign appropriate values based on policy. Encapsulated within the IA_PD option is the IA_PD Prefix option (code 26), which specifies the details of each delegated IPv6 prefix. This option's structure comprises a 4-octet preferred lifetime (indicating the time until the prefix becomes deprecated), a 4-octet valid lifetime (the total usability period), a 1-octet prefix length (in bits, commonly /56 or /60 for residential delegations to allow sub-delegation), and a 16-octet IPv6 prefix field. Additional sub-options follow for further configuration, such as any associated flags or extensions, though the base format does not include explicit flags like on-link determination, which is handled at the router advertisement level post-delegation. Both lifetimes are expressed in seconds, with 0xFFFFFFFF representing infinity, and clients set them to zero in requests while servers assign finite values aligned with delegation policies. The option length is 25 octets plus the length of any sub-options. Supporting options enhance the flexibility of prefix delegation. For instance, clients can provide a prefix delegation hint by including an IA_PD Prefix option within the IA_PD option in Solicit messages, setting the prefix to ::/ and lifetimes to zero. Servers may use this as a hint for the preferred prefix or but are not obligated to honor it. Further guidance on hint issues is provided in RFC 8168. Additionally, the Rapid Commit option (code 14), with zero and no data, enables a two-message exchange (Solicit/Reply) for faster delegation, bypassing the Advertise/Request steps when both client and server support it, thus reducing latency in prefix acquisition. These options collectively form the technical foundation for dynamic prefix management in , originally specified in RFC 3633 and updated in the DHCPv6 framework of RFC 8415.

Prefix Delegation Process

The prefix delegation process in DHCPv6 enables a requesting router to obtain prefixes from a delegating router for sub-delegation to attached networks, following a standardized message exchange defined in the protocol. This process typically occurs in scenarios such as (CPE) connecting to a broadband network gateway (BNG), where the requesting router acts as a client and the delegating router as a server managing prefix pools. The exchange ensures dynamic assignment of prefixes while supporting lifetime management to maintain network stability. The process begins with the requesting router sending a Solicit message to discover available delegating routers, including an Identity Association for Prefix Delegation (IA_PD) option to indicate interest in prefix delegation. The delegating router responds with an Advertise message, offering potential prefixes within the IA_PD option if available. Upon selecting an offer, the requesting router sends a Request message specifying the desired IA_PD to accept the delegation. The delegating router then confirms the assignment via a Reply message, which includes the delegated prefixes, their lengths, and valid lifetimes (T1 for renewal and T2 for rebinding timers). This four-message sequence (Solicit-Advertise-Request-Reply) constitutes the core exchange, though a two-message variant using the Rapid Commit option is possible for faster delegation. To manage prefix lifetimes, the requesting router may initiate optional renewal procedures. At the T1 timer expiration, it sends a Renew message to the original delegating router seeking extended lifetimes; if unsuccessful, at T2 it broadcasts a Rebind message to any available server. The delegating router responds to these with a Reply containing updated parameters or status indications. These mechanisms allow prefixes to remain active without full re-delegation, with lifetimes typically set by the server as a fraction of the preferred lifetime (e.g., T1 at 50% and T2 at 80%). In terms of entity roles, the requesting router—often a CPE—initiates the process by multicasting Solicit messages and manages sub-delegation of received prefixes to downstream interfaces. The delegating router, such as a BNG, maintains pools of available prefixes, authenticates requests based on client identity or hints, and tracks bindings to prevent overlaps. Relay agents may forward messages across network boundaries, preserving context like interface identifiers. Prefix selection occurs on the delegating router side, drawing from configured pools based on factors like client-provided hints (e.g., preferred prefix length), availability, and administrative policies such as subscriber entitlements. The server may assign a single prefix or multiple via separate IA_PD instances, ensuring the delegated prefix supports sub-delegation (e.g., a /56 from a /48 pool). Client hints are advisory and can be ignored if incompatible. Error handling integrates status codes within Advertise or Reply messages to address issues during the exchange. For instance, a NoPrefixAvail status code signals that no suitable prefixes are available, prompting the requesting router to retry or select another server. A NoBinding code in a Reply indicates no valid delegation exists for the client's IA_PD, requiring the client to release any assumed prefixes by setting lifetimes to zero. Invalid requests may trigger a negative acknowledgment (NAK) via Reply with an appropriate status, ensuring the process fails gracefully without resource leaks.

Implementation and Deployment

In Customer Premises Equipment

In (CPE), such as home or small office routers, prefix delegation functions as a client process to obtain an prefix from the upstream provider edge device via the (WAN) interface. The CPE requests a prefix using the Identity Association for Prefix Delegation (IA_PD) option, typically a /56 or /48 block, which it then subdivides into smaller /64 subnets for (LAN) interfaces using internal protocols or static configuration. This delegation enables the CPE to act as a delegating router for downstream devices without relying on . Configuration of prefix delegation on CPE involves enabling the client mode specifically for PD on the WAN interface, often through (CLI) commands tailored to the vendor. For devices, administrators use the ipv6 dhcp client pd prefix-name command on the relevant interface, such as interface GigabitEthernet0/0/0, to initiate requests, optionally including a hint for the desired prefix . On , configuration includes setting up address assignment pools with set access address-assignment pool pool-name family inet6 prefix delegated-prefix/56 and associating them via DHCP overrides. Prefix lifetimes are managed through renewal and rebind mechanisms; the CPE sends RENEW messages at 50% of the preferred lifetime and RELEASE messages upon expiration or disconnection, ensuring prefixes are returned to the pool if valid lifetimes elapse, with configurable defaults like 1800 seconds valid and 600 seconds preferred on platforms. Integration with LAN address assignment features allows the CPE to distribute sub-prefixes efficiently. The delegated prefix can be combined with Stateless Address Autoconfiguration (SLAAC) by advertising router advertisements (RAs) containing the /64 sub-prefixes, enabling hosts to self-configure , or with stateful for more controlled assignment from a local server pool. Prefix stability is maintained during reconnections through persistent bindings tied to the DHCP (DUID) and Interface ID, with storage in to avoid changes across reboots, though reconnections may trigger re-delegation if the upstream server enforces dynamic policies. Common challenges in CPE implementations include prefix changes that trigger renumbering events, potentially disrupting downstream connectivity as hosts retain deprecated addresses until lifetimes expire. Vendor-specific behaviors exacerbate this; for instance, Cisco devices derive the DUID from the lowest interface MAC address and require specific licensing for PD client functionality, while some implementations like those in Linux-based CPE (e.g., systemd-networkd) may fail to propagate updates promptly on renewal failures. Handling multiple PDs, such as for separate services, demands sufficient prefix sizes like /48 to allow subnetting without overlap, but inconsistent support across vendors can lead to configuration errors or inefficient allocation.

In Service Provider Networks

In service provider networks, the delegating router, often implemented as a Broadband Network Gateway (BNG) or a dedicated server, serves as the central component for prefix delegation. This entity maintains pools of prefixes, typically receiving larger allocations such as /32 blocks from upstream providers or Regional Registries (RIRs), and delegates smaller subsets—commonly /56 for residential subscribers or /48 for ones—to (CPE). The BNG processes requests from CPE devices, assigning prefixes dynamically to enable end-to-end connectivity while ensuring hierarchical addressing aligns with provider infrastructure. Pool management in these networks involves dynamic allocation of prefixes from RIR-assigned blocks, with comprehensive tracking of usage through dedicated databases to monitor utilization and prevent exhaustion. Providers implement policies that tailor prefix sizes to subscriber types, such as assigning /56 prefixes to residential users to support multiple /64 subnets while reserving /48 for enterprises requiring broader sub-delegation. This approach facilitates efficient resource distribution, with prefixes returned to the pool upon session termination to maintain availability for new assignments. To support scalability in large-scale deployments, service providers deploy high-availability servers with redundancy mechanisms, such as clustering, to ensure uninterrupted prefix delegation during failures. Integration with , , and (AAA) protocols like is standard, allowing the BNG to authenticate subscribers and retrieve prefix details from external servers before delegation. Upon session end, automated release processes reclaim prefixes, minimizing administrative overhead and supporting thousands of concurrent sessions. Vendor-specific implementations enhance these capabilities; for instance, ' subscriber management platforms configure prefix pools under access address-assignment hierarchies, enabling dynamic delegation and high-availability features like prefix preservation across subscriber logins. In systems, prefix delegation on BNG routers integrates with (BGP) to propagate routes for delegated prefixes, ensuring global reachability by advertising customer-specific routes to upstream peers.

Applications and Use Cases

Residential and Broadband Scenarios

In residential broadband environments, Internet Service Providers (ISPs) commonly delegate a /56 IPv6 prefix to customer premises equipment (CPE) such as home routers or modems, allowing the device to subdivide it into multiple /64 subnets for local networks. This enables unique global addressing for Wi-Fi networks, Internet of Things (IoT) devices, and other connected endpoints without address conflicts, supporting up to 256 distinct /64 LAN segments per household. For instance, a home router can assign one /64 to the primary LAN, another to a guest network, and additional subnets to isolated IoT zones, all derived from the delegated prefix via Stateless Address Autoconfiguration (SLAAC) or DHCPv6. Prefix delegation is widely deployed in broadband access technologies, including cable (via 3.1), DSL, and fiber-to-the-home (FTTH) networks, where it facilitates end-to-end global addressing for consumer services. In cable systems, for example, the CPE requests a prefix from the ISP's Network Gateway (BNG) using Prefix Delegation (PD), enabling seamless connectivity for applications like (VoIP) and online gaming that benefit from direct peer-to-peer communication. This approach aligns with Broadband Forum specifications for -enabled residential gateways, ensuring compatibility across diverse access methods without relying on transitional mechanisms like 6rd. A key benefit of prefix delegation in residential settings is the elimination of (NAT) double-translation—avoiding both ISP-side and home-side NAT—which simplifies connectivity and enhances performance for applications. This results in improved latency and reliability for services such as video conferencing and , as devices can use globally routable addresses directly. In multi-tenant scenarios like apartments, ISPs may delegate a /56 prefix to the building's gateway router, permitting sub-delegation of /64 subnets to individual units or sub-tenants while maintaining hierarchical addressing. Adoption of prefix delegation in residential has accelerated since the 2010s, propelled by the World Launch in 2012, which encouraged permanent enablement by major ISPs and equipment vendors. By enabling scalable addressing for growing numbers of home devices, it has become a standard practice, with many providers achieving widespread rollout in fixed-line networks post-2012. As of November 2025, global adoption has reached about 45%, with prefix delegation enabling continued deployment in fixed networks.

Enterprise and Mobile Networks

In enterprise networks, prefix delegation enables branch offices to request prefixes from a central server, facilitating site-local addressing for efficient internal routing and management. This approach supports scalable deployments where remote sites, such as distributed offices, dynamically obtain prefixes like /56 or /60, allowing routers to sub-delegate addresses to local subnets without manual configuration. Integration with virtual private networks (VPNs) further enhances this by enabling secure sub-delegation, where the delegated prefix is tunneled over or similar protocols to ensure isolated addressing for branch-to-headquarters connectivity. In mobile networks based on architectures, the Packet Data Network Gateway (PGW) or Session Management Function (SMF) delegates prefixes to (UE) routers via , supporting always-on connectivity for nomadic users. This mechanism assigns an initial /64 prefix for the UE's interface, with subsequent delegation of shorter prefixes (e.g., /56) for downstream devices, as specified in 3GPP TS 23.316. Advanced applications of prefix delegation in these environments include hierarchical delegation, where a site receives a /48 prefix from the provider and sub-delegates /56 blocks to departments or VLANs for granular control and renumbering flexibility. In (SDN) setups, controllers automate dynamic provisioning of prefixes via , responding to policy changes or traffic demands to allocate resources on-demand in enterprise or mobile core networks. A notable case study is the deployment in data centers for container orchestration platforms like , where Amazon EKS uses prefix delegation to assign /80 prefixes per node, enabling dual-stack pod networking and scaling to thousands of containers without address exhaustion. This approach leverages DHCPv6-PD to dynamically provision unique prefixes for elastic workloads, improving efficiency in cloud-native enterprise environments.

Security and Best Practices

Potential Vulnerabilities

Prefix delegation in is susceptible to rogue delegation attacks, where unauthorized or malicious servers respond to prefix requests with bogus prefixes, potentially leading to address hijacking or man-in-the-middle (MITM) attacks that redirect traffic through attacker-controlled networks. Such rogue servers exploit the lack of default authentication in exchanges, allowing them to impersonate legitimate delegating routers and issue invalid prefixes that cause unreachability for delegated subnets or enable traffic interception. In multi-access networks, this vulnerability is amplified as clients may accept the first valid-appearing response without verifying the server's identity. Another significant risk is prefix exhaustion attacks, in which a malicious requesting router floods the delegating server with repeated prefix delegation requests, depleting the available prefix pool and causing denial-of-service (DoS) for legitimate clients seeking addresses. This form of resource exhaustion can also arise from the Rapid Commit option, where multiple servers respond to a client's solicit , leading to allocation of unused prefixes and rapid depletion of server resources. Attackers can exacerbate this by crafting high volumes of solicit messages, overwhelming server processing capacity without necessarily consuming all resources immediately. DHCPv6 prefix delegation exchanges are vulnerable to and spoofing due to their unencrypted nature, allowing attackers on the same link to intercept messages and extract sensitive configuration details such as requested prefixes or client identifiers. In multi-access links, spoofing becomes particularly feasible, as adversaries can forge messages—like Advertise or Reply packets—to impersonate servers or clients, injecting false prefixes that disrupt network connectivity or enable unauthorized access. Without built-in or , these intercepted or spoofed messages can be replayed or modified to manipulate ongoing delegation processes. Renumbering risks in prefix delegation stem from malicious manipulation of prefix lifetimes, where an attacker spoofs Reconfigure messages to set preferred or valid lifetimes to zero, forcing clients to abandon their current prefixes and triggering unplanned network-wide address changes that disrupt services. Such attacks exploit the Reconfigure mechanism, which notifies clients of prefix updates but relies on optional authentication, allowing forged messages to induce premature deprecation of delegated prefixes and potential connectivity loss across downstream networks. In delegated environments, this can cascade to multiple sub-prefixes, amplifying the impact on larger topologies.

Mitigation Strategies

To secure prefix delegation (PD) in DHCPv6 deployments, authentication mechanisms are essential to verify the legitimacy of clients and servers, preventing unauthorized requests or responses. The DHCPv6 protocol supports authentication options as defined in RFC 8415, which enable the use of shared keys or to authenticate messages and ensure integrity. For enhanced protection, can be applied to DHCPv6 communications, providing confidentiality, integrity, and replay protection through Authentication Header (AH) or Encapsulating Security Payload (ESP) protocols, particularly in relay agent scenarios where messages traverse untrusted networks. In subscriber environments, such as broadband access networks, integration with the (EAP) allows for robust end-user authentication, often via servers, before PD assignment, ensuring only authorized devices receive prefixes. Server validation techniques further mitigate risks from rogue DHCPv6 servers that could spoof PD offers. DHCPv6 snooping, implemented on Layer 2 switches, inspects and filters DHCPv6 messages, building a binding database of legitimate client-server interactions and blocking unauthorized replies on untrusted ports. Complementing this, IPv6 Router Advertisement (RA) Guard prevents prefix injection attacks by dropping illegitimate RA messages containing prefix information options that could mislead clients into using rogue prefixes, as specified in RFC 7113. These features are typically configured on access switches to enforce trust boundaries, allowing only verified servers to delegate prefixes. Effective network design plays a critical role in containing PD traffic and preventing broader propagation of security issues. By isolating PD exchanges within trusted domains—such as dedicated VLANs or (VRF) instances—administrators limit exposure to external threats, ensuring that delegated prefixes remain confined to authorized segments. Additionally, in edge routers, applying prefix filters in (BGP) configurations restricts the advertisement of delegated prefixes, mitigating route leaks where customer prefixes could inadvertently enter the global ; this involves inbound and outbound prefix-lists to match only expected PD allocations. Ongoing monitoring and auditing are vital for detecting and responding to potential PD anomalies. Implementing comprehensive logging of DHCPv6 PD events, including request/response timestamps, client identities, and delegated prefixes, enables real-time visibility into assignment activities. Anomaly detection systems can flag unusual patterns, such as excessive PD requests from a single client or rapid prefix churn, using tools integrated with platforms. Regular audits of prefix usage, cross-referenced against allocation policies, help identify misconfigurations or abuse, ensuring sustained security in dynamic environments.

References

  1. https://www.rfc-editor.org/rfc/rfc3633.html
  2. https://www.ripe.net/publications/docs/ripe-690/
  3. https://datatracker.ietf.org/doc/html/rfc3769
  4. https://www.rfc-editor.org/rfc/rfc8415
  5. https://www.rfc-editor.org/rfc/rfc6177
  6. https://datatracker.ietf.org/doc/html/rfc4291
  7. https://datatracker.ietf.org/doc/html/rfc5375
  8. https://datatracker.ietf.org/doc/html/rfc6177
  9. https://datatracker.ietf.org/doc/html/rfc4862
  10. https://datatracker.ietf.org/doc/html/rfc3633#section-9
  11. https://datatracker.ietf.org/doc/html/rfc8415#section-21.21
  12. https://datatracker.ietf.org/doc/html/rfc3633#section-10
  13. https://datatracker.ietf.org/doc/html/rfc8415#section-21.22
  14. https://datatracker.ietf.org/doc/html/rfc8415#section-18.3.9
  15. https://datatracker.ietf.org/doc/html/rfc8415#section-21.14
  16. https://www.rfc-editor.org/rfc/rfc8415.html
  17. https://datatracker.ietf.org/doc/rfc9818/
  18. https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ip-addressing/b-ip-addressing/m_ip6-dhcp-prefix-xe.html
  19. https://www.juniper.net/documentation/us/en/software/junos/subscriber-mgmt-sessions/topics/topic-map/dhcpv6-prefix-delegation-lan-addressing.html
  20. https://datatracker.ietf.org/doc/rfc8987/
  21. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dhcp/configuration/15-mt/dhcp-15-mt-book/ip6-dhcp-pre-aaa.pdf
  22. https://blogs.infoblox.com/ipv6-coe/high-availability-dhcpv6/
  23. https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/710x/bng/configuration/guide/b-bng-cg-asr9000-710x/bng-use-cases-and-sample-configurations.html
  24. https://www.broadband-forum.org/pdfs/mr-244-1-0-0.pdf
  25. https://blog.lacnic.net/en/introducing-dhcpv6-prefix-delegation/
  26. https://blog.apnic.net/2022/08/25/the-state-of-ipv6-ten-years-after-world-ipv6-launch/
  27. https://www.google.com/intl/en/ipv6/
  28. https://datatracker.ietf.org/doc/html/rfc4057
  29. https://www.etsi.org/deliver/etsi_ts/129500_129599/129561/17.07.00_60/ts_129561v170700p.pdf
  30. https://aws.amazon.com/blogs/containers/amazon-eks-launches-ipv6-support/
  31. https://datatracker.ietf.org/doc/html/rfc3633#section-15
  32. https://datatracker.ietf.org/doc/html/rfc8415#section-22
  33. https://datatracker.ietf.org/doc/html/rfc8415#section-20.1
  34. https://datatracker.ietf.org/doc/html/rfc8415#section-18.3
  35. https://datatracker.ietf.org/doc/html/rfc3633
  36. https://datatracker.ietf.org/doc/html/rfc8415
  37. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/configuration/15-2s/ipv6-15-2s-book/ip6-ipsec.html
  38. https://www.ietf.org/archive/id/draft-pruss-dhcp-auth-dsl-07.html
  39. https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst_pon/software/configuration_guide/olt_ntw/b-gpon-config-olt-network/m-gpon-olt-nw-dhcpv6-snooping.pdf
  40. https://www.cisco.com/c/en/us/support/docs/ip/ip-version-6-ipv6/113141-DHCPv6-00.html
  41. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-3e/irg-iproute-bgp-xe-3e-book/irg-prefix-filter.html
  42. https://docs.commscope.com/bundle/fastiron-08095-dhcpguide/page/GUID-FD6E26A4-ABC3-4CAA-B1A2-AD6019BFC359.html
Add your contribution
Related Hubs
User Avatar
No comments yet.