So although that example works well, its missing one more component to test both your example and my need… You need a router “beyond” the ISP router to insure you can reach the hosts from an extended “ISP” network.
I’ve been trying to do the same thing in your example, however with a “remote” KEA DHCP server (v1.5.0) server from ISC. Issuing the PD is not an issue. What I’ve been having problems with is that the router that is issuing the PD for whatever reason (labeled ISP in your example) is not putting the route in its local routing table (for redistribution into OSPFv3, etc) so I cannot reach the prefixes that were issued to the client.
Specifically, the configuration I’m using on the PE router to the customer is:
service dhcp ipv6 unicast-routing ! interface GigabitEthernet0/1.101 encapsulation dot1Q 101 ipv6 address FE80::101:1 link-local ipv6 address 2600:2100:122:1::1/64 ipv6 enable ipv6 nd prefix 2600:2100:122:1::/64 no-advertise ipv6 nd managed-config-flag ipv6 nd router-preference High ipv6 dhcp relay destination 2600:2100::FEED:1 ospfv3 10 ipv6 area 0
Where 2600:2100::FEED:1 is my kea-dhpc6 server (can issue both stateful information as well as PDs). The kea server currently issues /60 and /56 blocks as requested.
Note: The prefix no-advertise combined with the nd managed-config-flag forces the client to get a DHCP issued address and that using SLAAC will not work for them (since manage-config-flag is only a suggestion, we pull the prefix to force the issue).
So although the client picks up the PD, and correctly uses it itself, the PE router that the route was issued through doesn’t seem to pick up on the fact that a PD was issued (contrary to all the cisco documentation I’ve been reading). Specifically, its supposed to insert into its local routing table a static route to the PD via the IPv6 address that made the PD request. From there, I could then redistribute that into my OSPF tables as an E2 route. I’m currently using IOS 15.2(4) on the PE device.