DHCPv6 address range command is not available?

[TCAM]

Hi - 

In DHCPv4, Cisco routers/switches have CLI command lines to set an Address range like "Low to High range".  For example: x.x.x.1 to x.x.x.99.

I couldn't find the similar CLI command lines in DHCPv6, does Cisco support it?  If not, what are the options? 

I know Juniper support it as shown below:

set access address-assignment pool my-pool family inet6 prefix 2001:db8:3000:1::/64
set access address-assignment pool my-pool family inet6 range range1 low 2001:db8:3000:1::1/64 high 2001:db8:3000:1::100/64
set access address-assignment pool my-pool family inet6 dhcp-attributes dns-server 2001:db8:3000:1::1
set access address-assignment pool my-pool family inet6 dhcp-attributes grace-period 3600
set access address-assignment pool my-pool family inet6 dhcp-attributes maximum-lease-time 120

Thanks

[Harold Ritter]

Hi @TCAM ,

This is not supported that I know of. What would be the use case for such a command?

Regards,

[TCAM]

Thanks for the reply Harold - The use case is for scanning.  We don't want scanner to scan18.45 quintillion Host Address in /64, so it would be nice if we can set aside a range of v6 address in DHCPv6 pool for scanning.  thanks

[Harold Ritter]

Hi @TCAM ,

I am not sure what you mean by scanning. Can you please explain?

Regards,

[TCAM]

Sorry my bad.  Scanning = Nessus vulnerability scanner, Tenable scanning for vulnerability in a dual stack network environment.  We don't want scanner to scan the entire /64 prefix.

[Harold Ritter]

Hi @TCAM ,

Thanks for the additional information. The fact that your subnet is not easily scannable is normally seen as a plus in terms of security, since a bad actor would have to search an extremely wide range of addresses to scan the subnet and discover vulnerabilities.

Is there not a way to provide a list of workstations to Nessus, so it doesn't have to scan the entire /64?

Regards,

[TCAM]

Yes, that is the point.  We plan to provide a list of workstation to Nessus that means we need to limit how many v6 address in DHCPv6 pool to begin with but the command is not available.  Does it make sense?

[Harold Ritter]

Hi @TCAM ,

You could get the list of ipv6 addresses on specific device and subnet using "show ipv6 dhcp binding" and provide that information to Nessus. A simple script could do that. 

Regards,

[TCAM]

hmmmmm.......DHCPv6 addresses keep changing once workstation is rebooted & reloaded.  Run a script seems ok but this put a heavy burden on Nessus & Network administrator because the leased v6 address changes from time to time.  Why don't Cisco just re-introduce the "Range" command in DHCPv6?

[Harold Ritter]

Hi @TCAM ,

> this put a heavy burden on Nessus & Network administrator because the leased v6 address changes from time to time

In my view, running a script to grab the DHCPv6 binding information every time Nessus needs to scan a given subnet is rather trivial.

> Why don't Cisco just re-introduce the "Range" command in DHCPv6?

I would suggest you discuss this with your Cisco account team. They will be able to put in the feature request for you.

If this option is available on a dedicated DHCPv6 server, the option would be to such a server rather than using the router as a DHCPv6 stateful server. 

Regards,

[TCAM]

Thank you for your input Harold.  2nd thought, What if I configure dhcpv6 pool as /119 or /120 instead of /64?  Will this work?

/119 give 512 addresses, /120 gives 256 addresses.

[TCAM]

Or it has to be /64 for dhcpv6 pool?

[Harold Ritter]

Hi @TCAM ,

In theory, this should work. Some workstation/server OSes might not behave properly if you do not use a /64. You might want to test this thoroughly in your lab before you deploy in production.

The other impact could be on your network. If you start propagating /120s for all of user subnets instead of /64s, this will definitely consume more memory space in your network devices TCAM.

This might also cause some other impacts in the future, as the best practice for the time being is to configure all user subnets as a /64 and therefore there is a strong assumption that all user subnets are configured with a /64.

Regards,