Using DHCPv6 IA_NA with DHCPv6 Prefix Delegation Overview
You can use DHCPv6 IA_NA to assign a global IPv6 address to the CPE WAN link and DHCPv6 prefix delegation to provide prefixes for use on the subscriber LAN. DHCPv6 IA_NA and DHCPv6 prefix delegation are done in a single DHCPv6 session. If the CPE sends both the IA_NA and IA_PD options in the same DHCPv6 Solicit message, the BNG returns both a single IPv6/128 address and an IPv6 prefix.
When at least one address is successfully allocated, the router creates a subscriber entry and binds the entry to the assigned address. If both addresses are successfully allocated, the router creates a single subscriber entry and binds both addresses to that entry.
Lease Times and Session Timeouts for DHCPv6 IA_NA and DHCPv6 Prefix Delegation
When you use DHCPv6 IA_NA together with DHCPv6 prefix delegation, note the following about session timeouts and lease times:
A session timeout from AAA has the highest precedence and overrides local pool lease times.
For DHCPv6 local server, the minimum lease time associated with an address pool takes precedence over pools with longer lease times. For example, if a CPE obtains an IA_NA address from a pool with a lease time of 3600, and a prefix from a pool with a lease time of 7200, the lease time returned in the Reply message from the BNG is 3600.
If AAA does not return a session timeout and the address pool does not have a configured lease time, the default setting of 86,400 (one day) is used.
Behavior When CPE Sends Separate Renew Requests for IA_NA and IA_PD Address Types
In some networks, the DHCPv6 client CPE device does both of the following:
Initiates negotiation for both the IA_NA and IA_PD address types in a single solicit message.
Sends separate lease renew requests for the IA_NA and the IA_PD and the renew requests are received back-to-back.
Starting in Junos OS Release 17.2R3, 17.4R2, 18.1R3, and 18.3R1, the jdhcpd process extends the lease for both address types in this situation.
When the reply is received for the first renew request, if a renew request is pending for the second address type, the client stays in the renewing state, the lease is extended for the first IA, and the client entry is updated.
When the reply is received for the second renew request, the lease is extended for the second IA and the client entry is updated again.
In earlier releases, the behavior is different for this situation:
The client transitions to the bound state instead of staying in the renewing state. The lease is extended for the first IA and the client entry is updated.
When the reply is received for the second renew request, the lease is not renewed for the second address type and the reply is forwarded to the client. Consequently, when that lease ages out, the binding for that address type is cleared, the access route is removed, and subsequent traffic is dropped for that address or address prefix.