Scope hierarchy
To understand the motivation behind scope hierarchy, let's explore a scenario.
In this entire scenario, we use IPv6 addresses from the 3000:: address range. Even these addresses aren't assigned yet; we use them to safely avoid conflicts with the fictional examples and addresses used around the globe.
DaAPI doesn't check the Scope of IPv6 addresses. So, you can use this example for testing.
A registar assigned a company, called »ISP A,« the 3000:1100::/24 block. Simplified, ISP A has a core network with three facilities and a couple of smaller network segments connected to each core facility. Also, we assume that there are two types of customers in each network segment: private customers and businesses—each of these customer types, using a separate VLAN.
This example can be applied to companies as well. Instead of a customer, you may refer to a device, a server, or a client. Private customers can be general-purpose devices, and business customers can be seen as servers or printers.
For the sake of simplicity, we are just looking at the network segments connected to »core facility 2«. We can see that five different VLANs are linked to this site. Let's assume the purple ones (VLAN 2, 20, and 200) are private customers and the orange ones (VLAN 3 and 30) are business customers.
In a first step, the IPS A breaks the 3000:1100::/24 network down into 4 /26 networks. The first is "reserved" for further usage. The other three are used for the three core facilities.
| IPv6 network | Usage |
|---|---|
| 3000:1100::/26 | reserved |
| 3000:1140::/26 | core facility 1 |
| 3000:1180::/26 | core facility 2 |
| 3000:11C0::/26 | core facility 3 |
As mentioned before, we are focusing on the second core facility. The second core facility administrator decides to split the address block into /36 networks.
| IPv6 network | Usage |
|---|---|
| 3000:1180::/36 | devices networks |
| 3000:1181::/36 | first network |
| 3000:1182::/36 | second network |
| ... | |
| 3000:11BF::/36 | 64th network |
The usage of the first block is labeled with "device networks." This address space is used to communicate with the customer's CPE devices. It is split into /64 networks, and the first five are used for the different VLANs.
| IPv6 network | Usage |
|---|---|
| 3000:1180:0:2::/64 | device network for VLAN 2 |
| 3000:1180:0:3::/64 | device network for VLAN 3 |
| 3000:1180:0:20::/64 | device network for VLAN 20 |
| 3000:1180:0:30::/64 | device network for VLAN 30 |
The second /36 block is split into /56 networks assigned to customers in VLAN 2. The third block is divided into/48 networks for business customers in VLAN 3. So, we could end up as displayed in the picture below.
Why customers don't only get an address but also a network is explained in the article about prefix delegation.
The scenario highlights that we used a network address tree to split a network into smaller parts. Hence, the image below represents the same information as the address table before.
This network address tree is the inspiration for the Scope hierarchy because it models the same approach: Splitting a network into subnets, where each subnet has a parent network. So, we can swap the address range in the image above with actual names. The result is the next image.
Each Scope in DaAPI needs an address range and can have a parent Scope. When a parent is selected, the scope address range needs to be in the parent's range. Enforcing this rule, we can be sure that we mirror the address tree.
In addition to the address tree, the Scope hierarchy has a mechanism for inheritance. All options (DNS server) or behavioral properties are used from parent values, as long as the child Scope configuration hasn't set values explicitly. The next image shows the create/edit page of the Scope »network segment A VLAN 2« and the Scope detail page of the same Scope.
As the example shown, this approach is very flexible. More general properties like DNS server can be set by Scopes, which are higher in the hierarchy. Properties like T1 can be placed on a more detailed level. The same is true if properties need to be changed. Instead of modifying the DNS server of hundreds of Scopes, there is only one Scope, that needs to be changed.
Once a child's Scope has overridden any parent property, the parent property changes are no longer reflected. The inheritance is broken. Yet, it can be quickly restored by enabling it explicitly again.
DaAPI uses Resolvers to decided what Scope is a match for an incoming packet. The process of determining the right Scope starts with all Scopes at the root level. If a match occurs, all child Scopes are tested. If a child is a match, its children are tested, and so on.
DaAPI is looking for the best Scope match by counting the tree depth. The higher the number, the more nested the Scope is, the more likely to be chosen.
Even if it is possible to have two different scopes with the same depth, this is considered a design error. However, DaAPI will choose the Scope first added into the tree to process the packet.
To explore this mechanism in more detail, we assume we have three different incoming packets. We look at the characteristics: relay agent address and DUID.
| Packet | Relay Agent | DUID |
|---|---|---|
| A | 3000:1180:0000:002::1 | UUID: 7c10c5bf-41f7-4105-b406-586627527f66 |
| B | 3000:1180:0000:030::1 | L2: 80-59-7A-D2-97-EA |
| C | 3000:1180:0000:030::1 | L2: 4A-F3-C8-A5-E9-4A |
The scope tree with resolvers is displayed in the next picture.
The pseudo resolver is always a match, but unlike others, it doesn't increase the depth counter. The pseudo resolver can be used to create this type of hierarchy.
This configuration has only one Scope at the root level, named "main." Main uses the pseudo resolver. Hence, it is always a match for each incoming packet, but the depth counter is still zero.
Although the depth counter is not increased, the root scope matches the next level to be tested. At the second level, we find the scopes "core facility 1", "core facility 2", and "core facility 3". Again, because the pseudo resolver is used, all of them will be a match.
"core facility 1" has no child scopes. The depth counter is still 0. "core facility 2" is tested. It is a match, but the depth counter is still zero. But this Scope has children that are now evaluated.
Packet A, because of its relay agent address, is a match for the Scope "VLAN 2 devices". The depth counter is now 1. This Scope has no children, so nothing more to explore in the depth of the tree. The other scopes on the same level or no match either, so the depth counter stays at 1. "VLAN 30 devices" have children, but the Scope itself is not a match.
"core facility 3" is a match, but the depth counter is not increased. Nor are children registered.
The process chooses "VLAN 2 devices" with a depth counter of 1 as the matching Scope.
Packet B, because of its relay agent address, won't be a match for the Scope "VLAN 2 devices", "VLAN 3 devices," and "VLAN 20 devices" but for "VLAN 30 devices". The depth counter is now 1. This Scope has children. However, both child scope demands a different DUID as specified in the packet. So no matches occurred, the counter is still 1.
"core facility 3" is a match, but the depth counter is not increased. Nor are children registered.
The process chooses "VLAN 30 devices" with a depth counter of 1 as the matching Scope.
Packet C, because of its relay agent address, won't be a match for the Scope "VLAN 2 devices", "VLAN 3 devices," and "VLAN 20 devices" but for "VLAN 30 devices". The depth counter is now 1. This Scope has children. The first child, the name "VLAN 30 special customer 1," is a match. The counter is increased by one and has a value of 2 now. The second child is not a match. So, the counter is still 2.
"core facility 3" is a match, but the depth counter is not increased. Nor are children registered.
The process chooses "VLAN 30 special customer 1" with a depth counter of 2 as the matching Scope.
