Scope properties
A Scope has a lot of different properties that can be configured. This page explores and explains all of these options in detail.
The web application of DaAPI has a built-in reminder, what the properties mean. It is identified by the question mark next to the property.
Each Scope needs a name. Although the name hasn't to be unique, it is a recommendation. The name is displayed in the overview, in logs, and other views. You need to enter at least three characters.
The description is an optional field that should help to give the Scope further context. It is only displayed in the details.
Each Scope can have one parent. If the property "has parent" is selected, a parent needs to be chosen, too. The address range of the child's Scope needs to fit the range of the parent. It is possible to have the same boundaries as parent and child. The address and other properties like valid and preferred lifetime need to be suitable in the parent range.
Currently, the only way to build the parent and children relation is to set the child's parent property. There is no way to assign children to a Scope the other way around.
Each Scope has a start address. If a parent is selected, it can be the same as the parent. The start address hasn't to be the actual start of a network (without a network mask, there is no way to detect it). It can be any address. The start address, together with the end addresses, marks the range of valid addresses that can be assigned to devices.
Each Scope has an end address. If a parent is selected, it can be the same as the parent. The end address hasn't to be the actual end of a network (without a network mask, there is no way to detect it). It can be any address.
This is not a property that you can choose from in the web application. It is a consequence of having the same address for the start and end of a Scope. This scenario creates exactly one possible address to use.
This feature is useful for circumstances where one device (or client) should always have the same address.
Excluded addresses can be configured to be not chosen within the address selection process of a scope. You can exclude as many addresses as you like. Each address needs to be unique and within the range of end and start.
If the parent Scope excluded addresses in the child scopes' range, these addresses are excluded, too.
If this option is enabled, the Scope will assign a prefix if the client is requesting it. Allowing this option enabling the prefix delegation feature.
In this field, you can enter the entire prefix that should be used for prefix delegation. The prefix needs to be a subnet start address. Any valid IPv6 prefix can be entered.
This property is the subnet mask length of the prefix network.
This is the length of assigned prefixes to clients. The difference between the prefix length and this field is the number of possible prefixes within the Scope.
If you have a /48 network reserved for prefix delegation, you can have one /48 network, or two /49 network, or four /50 networks, and so on. If you want to slice this /48 into /56 networks, you can have 2^ (56-48) = 256 prefixes.
single-prefix Scope
Similar to a single address Scope, it is possible to have only one available prefix per Scope if the prefix length has the same value as the assigned prefix length. This scenario can be used if you want to set the same prefix to the same customer.
Until this time ends, the client can safely use the assigned addresses for any purpose. Has the timer expired, the client should use the address for new connections. See section 5.5.4 of RFC 4862
As long as this timer hasn't expired, the devices can use the assigned prefix. As soon as the timer expired, the device MUST not use the address further. See section 5.5.4 of RFC 4862
After this timer has ended, the DHCPv6 clients going into the RENEWING state and try to contact the same server to extend their lease. This value needs to be smaller than the preferred lifetime.
DaAPI uses a scale instead of a timer. A scale value of 0.5 means that this timer will expire at half of the time of the preferred lifetime.
After this timer has ended, the DHCPv6 clients going into the REBINDING state and try to contact any server to extend their lease. This value needs to be smaller than the preferred lifetime.
DaAPI uses a scale instead of a timer. A scale value of 0.8 means that this timer will expire at 80 percent of the preferred lifetime.
If this option is enabled, the Unicast Option is attached to each response. The global unicast address of the receiving interface is used as the option value. If the client support this option, DHCPv6 messages are not sent via multicast but instead via unicast to the DHCPv6 server directly.
This behavior may bypass relay agents, hence, missing them to insert their options, which could affect the lease extension process.
If this option is enabled, DaAPI accepts DHCPv6 DECLINE messages and banning the specified address from being assigned to other clients for a limited time interval. The client should send a DECLINE message to indicate that the suggested address is already used (DAD). However, DECLINE message can also be used by malicious clients to provoke address exhaustion.
If this option is enabled, the Unicast Option is attached to each response. The global unicast address of the receiving interface is used as the option value. If the client support this option, DHCPv6 messages are not sent via multicast but instead via unicast to the DHCPv6 server directly. This behavior may bypass relay agents, hence, missing them to insert their options.
Rapid Commit is a DHCPv6 option when enabled by the client and activated with this option, forcing the server to respond to a SOLICIT with a REPLY instead of an ADVERTISE message. This option can be safely used if there is only one DHCPv6 server responsible for a single network.
This option influence the behavior of the Scope regarding the extensions of a lease. If this option is enabled and the client sends a RENEW/REBIND message, the lease is extended. If this option is disabled, a new lease will be created and a new address assigned to the client. Moreover, suppose the Resolver has a unique value like Interface Identifier Option. In that case, if this option is enabled, and a different client (different DUID) is sending a SOLICIT/RENEW/REBIND, a new lease is created but using the same address as the previous one.
The client has sent a SOLICIT before. This SOLICIT message created a lease in the corresponding Scope. The client is now sending a RENEW message.
If the Scope hasn't enabled the "reuse of address" property, the current lease will be canceled because it is no longer valid. At the same time, a new lease is generated, and a response with the new address is sent back to the client.
If the "reuse of address" property is enabled, the current lease will be extended. That means that the lease's expected end date will be set to the present time + preferred lifetime. The response containing the same address is sent back to the client.
A client has sent a SOLICIT before. This SOLICIT message created a lease in the corresponding Scope. The Scope has a resolver, like an LDRA agent-specific resolver. That means, in an ISP network, the connected port is known. However, a new client - a different DUID - but with the precisely same unique resolver value is sending a SOLICIT or RENEW message.
The client is unknown because different DUID is used. So, a new lease will be generated. If there is no address left, like in a single-address Scope, an error message in case of a RENEW is sent back.
The Scope found a lease based on the unique resolver identifier value. This lease belongs to a different client. However, because reuse is enabled, the old lease is canceled, and a new lease, but with the same address, is generated. The response containing the same address is sent back to the client.
If a pool or prefix has multiple addresses that are free to use, there are two possibilities on how to assign those. If RANDOM is selected, the address will be randomly assigned. If NEXT is selected, the given address will be the next free possible. RANDOM is the recommended action.
Options are passed into DHCP REPLY (or ADVERTISE) to indicate additional values like DNS or NTP server. Options are inherited by the parent scope but can either be deleted or set to a different value by the child scope.
A resolver needs to be chosen for every Scope. A resolver decides if an incoming packet is a match for a scope. Resolvers are explained at this page.