IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6
Extracted elements (28)
An IA_PD differs from an IA in that it does not need to be associated with exactly one interface; one IA_PD can be associated with the requesting router as a whole, a set of interfaces, or exactly one interface. This flexibility accommodates diverse CPE deployment topologies without requiring per-interface bindings.
Delegated prefixes are expected to be long-lived even though the mechanism makes automatic renumbering easier. During renumbering the old and new prefix are expected to co-exist for some time. This design choice reflects that many applications depend on stable addresses.
Prefix delegation with DHCP is deliberately independent of address assignment. A requesting router can use DHCP for just prefix delegation or combine it with address assignment and other configuration. This separation reflects that prefix delegation serves a different administrative function (ISP-to-CPE) than host address configuration.
Recommended values for T1 and T2 are 0.5 and 0.8 times the shortest preferred lifetime of the prefixes in the IA_PD, respectively. This allows the requesting router to extend lifetimes before they expire even if the delegating router is unavailable for a short period. If renewal timing should be left to the requesting router's discretion, the delegating router sets T1 and T2 to 0.
The delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned. The mechanism is designed for cross-administrative-boundary delegation, such as an ISP assigning a prefix to a CPE device, where the ISP need only know the identity of the requesting router.
A requesting router uses the same message exchanges as described in RFC 3315 section 18 (Solicit, Advertise, Request, Reply, Renew, Rebind, Release, Reconfigure) to obtain or update prefixes from a delegating router. The IA_PD Prefix option is used analogously to the IA Address option used for assigned addresses.
If a delegating router communicates with a requesting router through a relay agent, the delegating router may need a protocol or other out-of-band communication to add routing information for delegated prefixes into the provider edge router. No in-band mechanism is defined for this.
The Confirm and Decline message types defined in RFC 3315 are not used with Prefix Delegation. The NoPrefixAvail Status Code is handled in the same manner as the NoAddrsAvail Status Code defined in RFC 3315.
This use of DHCP is not bound to the assignment of IP addresses or other configuration information to hosts, and no mechanism is currently available to communicate delegated prefixes to a DHCP server that serves such a function. Future work may address this gap.
A requesting router discards any prefixes for which the preferred lifetime is greater than the valid lifetime. A delegating router ignores lifetimes set by the requesting router if preferred lifetime exceeds valid lifetime, and ignores T1 and T2 values set by the requesting router if they are greater than the preferred lifetime.
For any given use of an IA_PD by the requesting router, the IAID for that IA_PD MUST be consistent across restarts of the requesting router. The requesting router may maintain consistency by storing the IAID in non-volatile storage or by using an algorithm that consistently produces the same IAID.
If the requesting router assigns a delegated prefix to a link and sends router advertisements for it, the requesting router MUST set the valid lifetime in those advertisements to be no later than the valid lifetime specified in the IA_PD Prefix option. It MAY use the preferred lifetime specified in the option.
If verification of the delegating router binding is needed (e.g., after reboot, link flap, or physical disconnection), the requesting router MUST initiate a Rebind/Reply message exchange, with retransmission parameters set as for the Confirm message per RFC 3315 section 18.1.2.
In a message sent by a delegating router to a requesting router, the requesting router MUST use the values in the T1 and T2 fields for the T1 and T2 parameters. If a requesting router receives an IA_PD with T1 greater than T2, and both are greater than 0, the client discards the IA_PD option and processes the remainder of the message as though the IA_PD option was not included.
Prefixes to be released MUST be included in the IA_PDs of a Release message. The Confirm and Decline message types are not used with Prefix Delegation.
The delegating router MUST include an IA_PD Prefix option or options (in an IA_PD option) in Reply messages sent to a requesting router. For prefixes not found in the requesting router's binding entry, the delegating router returns the prefix with lifetimes of 0.
The requesting router MUST include the IA_PD Prefix option(s) (in an IA_PD option) for prefix(es) delegated by the delegating router in its response to a Reconfigure message from that delegating router.
To guard against attacks through prefix delegation, requesting routers and delegating routers SHOULD use DHCP authentication as described in section 21 of RFC 3315. Alternatively, IPsec may be used for authentication of DHCPv6 messages where routers have assigned IPv6 addresses.
Upon receipt of a valid Reply message, the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router (the upstream/ISP-facing link).
When a requesting router sends a DHCP message, it SHOULD be sent on the interface associated with the upstream router (ISP network). When using unicast after receiving the Server Unicast option, the source address SHOULD be an address from the upstream interface suitable for the delegating router to use in responding.
An Identity Association for Prefix Delegation (IA_PD) is a construct through which a delegating router and a requesting router identify, group, and manage a set of related IPv6 prefixes. Each IA_PD consists of an IAID and associated configuration information, including one or more IPv6 prefixes with T1 and T2 timers. Unlike an IA for addresses, an IA_PD does not need to be associated with exactly one interface.
IANA assigned option code 25 to OPTION_IA_PD and option code 26 to OPTION_IAPREFIX from the DHCPv6 option-code space defined in RFC 3315 section 24.3.
IANA assigned status code 6 to NoPrefixAvail ('Delegating router has no prefixes available to assign to the IAPD(s)') from the DHCPv6 status-code space defined in RFC 3315 section 24.4.
A malicious requesting router may mount a denial of service attack by making repeated requests for delegated prefixes, exhausting the delegating router's available prefix pool.
A rogue delegating router can issue bogus prefixes to a requesting router, potentially causing denial of service due to unreachability of hosts using those prefixes.
Networks configured with delegated prefixes should be configured to preclude intentional or inadvertent inappropriate advertisement of these prefixes, to prevent prefix hijacking or misrouting.
The OPTION_IA_PD option (option-code 25) carries a prefix delegation identity association. Its format is: 2-octet option-code, 2-octet option-length (12 + length of IA_PD-options), 4-octet IAID, 4-octet T1 (seconds), 4-octet T2 (seconds), followed by variable-length IA_PD-options field.
The OPTION_IAPREFIX option (option-code 26) specifies an IPv6 address prefix associated with an IA_PD. Its format includes: 4-octet preferred-lifetime, 4-octet valid-lifetime, 1-octet prefix-length, 16-octet IPv6-prefix, and variable-length IAprefix-options. Option-length is 25 + length of IAprefix-options. A value of 0xFFFFFFFF for lifetimes represents infinity.