IPv6 PD addressing with a downstream PD client

I’ve been reading blogs, documentation and trying things for a while, and I think ROS just can’t do what I’m asking it to but would like someone to sense-check this.

My ISP provides a /56 prefix via DHCP, I can set this up in ROS with no issues:

/ipv6 dhcp-client
add interface=Aquiss pool-name=Aquiss prefix-hint=::/56 request=prefix use-peer-dns=no

This retrieves a prefix:

# INTERFACE  STATUS  REQUEST  PREFIX                             
0 Aquiss     bound   prefix   ****:****:****:f800::/56, 4w1d23h44m1s

If use this prefix to address an interface, it works as expected:

/ipv6 address
add address=::3:0:0:0:1 from-pool=Aquiss interface=lo
 #    ADDRESS                       FROM-POOL  INTERFACE        VRF   ADVERTISE  VALID         PREFERRED 
11  G ****:****:****:f803::1/64        Aquiss     lo               main  yes        4w1d23h18m2s  6d23h18m2s

I can also pick the /64 that is used:

/ipv6 address
add address=::da:0:0:0:1 from-pool=Aquiss interface=lo
 #    ADDRESS                       FROM-POOL  INTERFACE        VRF   ADVERTISE  VALID          PREFERRED                    
11  G ****:****:****:f8da::1/64        Aquiss     lo               main  yes        4w1d22h56m31s  6d22h56m31s

I would like to delegate /60 of my allocation downstream to another router. My understanding of ROS is that if I wanted to do this I would need to change pool-prefix-length in the DHCPv6 client to /60. If I change this value I can’t address an interface with a /64.

Is there a way to delegate /60 to a client while using /64s from the prefix on other interfaces, or does specifying the prefix size in the pool set it for everything using that pool?

The only way I can think of getting the outcome I want is to not bother pulling the IPv6 prefix by DHCP and setting all the addressing as static - the prefix I am getting from the ISP is static, it’s just delivered by DHCP. Then I can configure the /60 I want to delegate and drop it onto a DHCPv6 server on the interface that the downstream router connects to - or give up and statically assign routes and addressing on the downstream router. I’ve not looked to see if ROS adds a route to a delegated prefix automatically when a downstream router pulls the prefix down.

You can set the pool-prefix-size to 60 in the DHCP client. Then a downstream router can request a /60 from there.

Unfortunately it means a /60 will also be wasted on every interface. But it may be enough for you.

I think in the newest versions there is a facility for nested pools where you could have a new pool that requests /60 from the ISP pool and assigns /64 from that to interfaces. I have not yet studied it.

1 Like

Actually that’s not a bad idea, I don’t need enough prefixes that burning /60s everywhere would cause issues.

Do you know if routes to delegated prefixes are added automatically when a downstream router requests them? The docs are a bit thin on detail around prefix delegation as a server rather than client.

Yes, they are. You will get a dynamic route in the table.

1 Like

Sounds like this is in the release notes for 7.22:

*) ippool6 - allow creating sub-pool by specifying "from-pool";

I’m running 7.21.2 at the moment so this might even be ready by the time I want to deploy it, assuming that a sub-pool will be allowed to have a shorter prefix length than what’s configured in pool-prefix-length.

Yes, creating sub-pool works fine in 7.22. In your DHCPv6 client set pool-prefix-length=60, then add another pool with

/ipv6 pool
add from-pool=Aquiss name=Aquiss-SLAAC prefix=0:0:0:20::/60 prefix-length=64 

Notice how you can also pin the subnet-id, 2 in this case, of the sub-pool. You can then use the pool Aquiss for the DHCPv6 Server PD and Aquiss-SLAAC to assign and advertise on your interfaces.

2 Likes

Picking this back up now that 7.22 is released, the documentation hasn’t been updated with this new setting yet and it could do with an example usage.

Currently my IPv6 prefix that I am offered is ****:****:****:f800::/56, the prefix length is detected as /64 in the DHCPv6 pools, pool-prefix-length is not set to a value. If I then create a sub-pool with the prefix set to 0:0:0:f0::/64 and prefix-length set to 64 this is accepted by ROS but a prefix of /64 is not very useful to delegate downstream. If I change the prefix to 0:0:0:f0::/60 and leave the prefix length at 64 then I get the error “preferred prefix length doesn't match parent prefix” which should possibly say “preferred prefix doesn’t match parent prefix length” as that’s what it looks to be upset by.

My understanding of what I’m trying to do here is to create a /60 out of some of my /56 to delegate, but ROS doesn’t seem to like that configuration, presumably because /60 doesn’t match the prefix length on the parent pool. From your config above it reads like the prefix size is determined when you create the initial pool (in this case by configuring DHCP-PD) and that impacts every sub-pool, so in this situation I’d need to set my pool prefix length to /60, delegate a /60 out with one sub-pool and then create a second sub-pool with /64 prefix length if I wanted to get a /64 on a local interface to address clients.

It already says above. You have to set the prefix length to 60 in your DHCPv6 pool, and then create a new pool with that as parent, but prefix length 64. That you can use for the local interfaces. The /60 pool is used for the DHCPv6 server.

Thanks, I have this all working now. I am taking a /56 prefix via PD from my ISP, configuring this pool with a prefix length of /60 and then making a sub-pool with a prefix of /60 and a prefix length of /64. Then from this sub-pool I am making another sub-pool with a prefix of /64 and a prefix-length of /64 to assign to the interface.

I assume there’s a ROS reason why sub-pools have to have the prefix length of their parent pool but it feels reasonably arbitrary, though at least you can nest sub-pools to get what you want.

This step is not needed. Use the 2nd pool on your interfaces for SLAAC (the one with /60 and prefix length 64, that I named Aquiss-SLAAC in my reply above).

Ok, thanks. I’ll simplify it the next time we’re in a maintenance window.