Prefix Delegation Threats
Service providers need to connect numerous customers to the IPv6 Internet. Most ISPs will connect larger customers with dedicated interfaces. These could either be T1s, Metro Ethernet, fiber, SONET, wireless, or any of a variety of media types. These directly connected customers will receive address assignments from the allocations that the service provider received from the regional registry. These assignments are performed manually and require coordination between the customer and the service provider. This method of allocating addresses is possible but does require the customer to be savvy at configuring his CPE.
For service providers that must connect millions of IPv6 Internet subscribers, there is no feasible way to coordinate direct assignments to that many customers manually. There needs to be an automated way of allocating IPv6 prefixes to customers and reclaiming those assignments if the customer disconnects. Current IPv4 broadband providers give customers a single IPv4 address and let the customer's device perform NAT. IPv6 will allow customers to acquire much more public address space. Broadband customers could be allocated a /48, /56, or /64 network prefix depending on the provider's policies, and then their CPE would allow the customers' hosts to perform Stateless Address Auto-configuration (SLAAC).
The following sections describe the use of SLAAC and indicate why some service providers prefer to use DHCPv6 instead.
SLAAC
Provisioning of new customer connections must be automated in some way to have a scalable system for the broadband service providers to maintain. One technique is to leverage SLAAC to allow the CPE device or hosts to acquire public IPv6 addresses. SLAAC can be used to uniquely allocate the addresses, and the Neighbor Discovery Protocol (NDP) function Duplicate Address Detection (DAD) can be used to avoid addressing conflicts. SLAAC might not be the best option for allocating IPv6 addresses to customers because there are no security features within the NDP. Furthermore, SLAAC can be a simple way to have nodes determine their address, but it does not provide them with other necessary information for communications, such as a DNS server for the node to use.
DHCPv6
Because SLAAC does not do everything that a service provider wants, the provider can elect to use DHCP version 6 (DHCPv6). The service provider's Layer 3 edge router can send a router advertisement (RA) message to inform customers that DHCPv6 is in use. The RA sends the A/M/O bits to tell the node that DHCPv6 is available. There can still be concern that the RA messages could be spoofed by an attacker. Because of the security issue of spoofed RA messages, service providers might want to make use of DHCPv6 instead of SLAAC. That way, they can know exactly who is turning up on the network.
Service providers might want some type of authentication to take place to verify a customer's legitimacy before allowing the customer on the network. If the subscriber has not paid his bill, he will not be allowed on the Internet. To gain more control over the subscriber, a service provider might want to use DHCPv6 rather than SLAAC. There can also be a concern that attackers could spoof DHCPv6 servers or DHCPv6 relays. Rogue DHCPv6 servers could give out false information. Therefore, the security of DHCPv6 is a serious concern.
There are some solutions to the security vulnerabilities within DHCPv6. Hackers could also try to see whether DHCPv6 servers are allocating sequential lease addresses. That would lead to much easier network reconnaissance. Cisco Network Registrar gives out pseudorandom leases, so this would prevent easy guessing of the client assigned addresses.
Another risk is that a single system could consume DHCPv6 resources similar to the way that the hacker utility Gobbler can eat up all the available IPv4 DHCP addresses. One possible solution to the resource consumption attack is to rate limit messages sent to FF02::1:2 (All DHCPv6 Relay Agents and Servers) and FF05::1:3 (All DHCPv6 Servers).
If attackers can observe the information between the client and the server, many problems would result. DHCPv6 offers a mechanism to secure communication from the client and the DHCPv6 server with the use of authentication algorithms. This authentication mechanism does not provide confidentially but merely helps prevent theft of service. Within the DHCPv6 protocol itself, there is no current way to secure communications between the DHCPv6 relay agent and server. Separate IPsec configurations could be used to secure these communications.
DHCPv6 can provide a prefix to a device in addition to providing individual IPv6 addresses to hosts on a LAN. This is an extension to the DHCPv6 specification called DHCPv6 Prefix Delegation (DHCPv6-PD). The client device acts as a DHCPv6 client, and the DHCPv6 delegating router acts like the DHCPv6 server. It is relatively simple to have one router be a DHCP server for other access routers. The delegating router can be preconfigured with a pool of addresses that prefixes will be allocated from. The client router configuration is equally simple.
Example 3-10 shows what a delegating router configuration might look like. The DHCPv6 configuration on the router is tied to a specific interface. A pool is created that defines the block of addresses to allocate from and the prefix length to give to the client. In this case, /48 blocks are delegated to the clients out of a /40 pool. A DHCPv6 pool is created and assigned to an interface.
Example 3-10. Delegating Router Configuration
hostname R1 ! ipv6 unicast-routing ipv6 dhcp pool CUSTPOOL prefix-delegation pool PREFIX dns-server 2001:DB8:1::1 ! interface FastEthernet1/0 description Link to customers for DHCP prefix delegation no ip address ipv6 address 2001:DB8::1/64 ipv6 dhcp server CUSTPOOL ! ipv6 local pool PREFIX 2001:DB8:FF00::/40 48
The configuration of the DHCPv6 client is simple. Example 3-11 shows that DHCPv6-PD is tied to an interface and the allocated prefix is assigned to a general prefix variable. Router R2 is connected to R1 with interface Fast Ethernet 1/0. This general prefix variable can be used on other downstream interfaces.
Example 3-11. Client Router Configuration
hostname R2 ! interface FastEthernet1/0 description Link to ISP for DHCP prefix delegation no ip address ipv6 address autoconfig default ipv6 enable ipv6 dhcp client pd PREFIX ! interface FastEthernet1/1 description LAN Link that will inherit prefix no ip address ipv6 address PREFIX ::1:0:0:0:1/64 no keepalive
After these routers are configured and the Fast Ethernet 1/0 interface comes up, the delegating router can see the DHCPv6 requests and allocate the block. Example 3-12 shows the status of the delegating router. You can see the /48 block allocated to the client and the identity of the client device.
Example 3-12. Delegating Router Status
R1# show ipv6 local pool PREFIX
Prefix is 2001:DB8:FF00::/40 assign /48 prefix
1 entries in use, 255 available, 0 rejected
0 entries cached, 1000 maximum
User Prefix Interface
00030001CA0117DC000000050001
2001:DB8:FF00::/48
R1# show ipv6 dhcp bind
Client: FE80::C801:17FF:FEDC:1C
DUID: 00030001CA0117DC0000
Interface : FastEthernet1/0
IA PD: IA ID 0x00050001, T1 302400, T2 483840
Prefix: 2001:DB8:FF00::/48
preferred lifetime 604800, valid lifetime 2592000
expires at Sep 12 2008 08:09 AM (2590587 seconds)
R1# show ipv6 dhcp interface
FastEthernet1/0 is in server mode
Using pool: CUSTPOOL
Preference value: 0
Hint from client: ignored
Rapid-Commit: disabled
R1# show ipv6 dhcp pool
DHCPv6 pool: CUSTPOOL
Prefix pool: PREFIX
preferred lifetime 604800, valid lifetime 2592000
DNS server: 2001:DB8:1::1
Active clients: 1
R1#
The client router now has the allocated address assigned to its interfaces. Example 3-13 shows the status of the client router after the DHCPv6-PD allocation has been made. The show ipv6 dhcp command shows the client's DHCP Unique Identifier (DUID). The DUID can be unique to the client device, and DUIDs are assigned by the client router automatically and are based on the lowest MAC address on the device.
Example 3-13. Client Router Status
R2# show ipv6 dhcp
This device's DHCPv6 unique identifier(DUID): 00030001CA0117DC0000
R2# show ipv6 dhcp interface FastEthernet 1/0
FastEthernet1/0 is in client mode
State is OPEN
Renew will be sent in 3d11h
List of known servers:
Reachable via address: FE80::C800:17FF:FEDC:1C
DUID: 00030001CA0017DC0000
Preference: 0
Configuration parameters:
IA PD: IA ID 0x00050001, T1 302400, T2 483840
Prefix: 2001:DB8:FF00::/48
preferred lifetime 604800, valid lifetime 2592000
expires at Sep 12 2008 08:09 AM (2590412 seconds)
DNS server: 2001:DB8:1::1
Information refresh time: 0
Prefix name: PREFIX
Rapid-Commit: disabled
R2#
The DUID can be used to provide some minor form of security for the DHCPv6-PD communications. DUIDs can be assigned statically, and the DUID could be assigned by the service provider. This might be slightly more secure, but it would eliminate any efficiency gained by using an automated address assignment method. If the DUID needs to be configured manually on the CPE, DHCP-PD might not be of much benefit compared to manually assigning a block to a customer.
Example 3-14 shows how the DUID can be statically configured on the delegating router R1. In this example, the prefix is granted only to the client router R2 with the preconfigured DUID.
Example 3-14. Delegating Router with Static DUID
ipv6 dhcp pool CUSTPOOL prefix-delegation 2001:DB8:1234::/48 00030001CA0117DC0000 dns-server 2001:DB8:1::1
When this change is made on R1 and R2 reconnects to the service provider network, R2 receives a unique delegation based on its DUID. Example 3-15 shows the new address that R2 has been given. Because R2 is using a general prefix, it is passing along the use of that prefix to its Fast Ethernet 1/1 interface address.
Example 3-15. Client Router with Static DUID
R2# show ipv6 dhcp interface FastEthernet 1/0
FastEthernet1/0 is in client mode
State is OPEN
Renew will be sent in 00:00:46
List of known servers:
Reachable via address: FE80::C800:17FF:FEDC:1C
DUID: 00030001CA0017DC0000
Preference: 0
Configuration parameters:
IA PD: IA ID 0x00050001, T1 60, T2 120
Prefix: 2001:DB8:1234::/48
preferred lifetime 604800, valid lifetime 2592000
expires at Sep 12 2008 08:38 AM (2591987 seconds)
DNS server: 2001:DB8:1::1
Information refresh time: 0
Prefix name: PREFIX
Rapid-Commit: disabled
R2# show ipv6 interface brief
FastEthernet1/0 [up/up]
FE80::C801:17FF:FEDC:1C
2001:DB8::C801:17FF:FEDC:1C
FastEthernet1/1 [up/up]
FE80::C801:17FF:FEDC:1D
2001:DB8:1234:1::1
R2#
Even with statically defined DUIDs, there can still be risks to DHCP-PD that could make this type of addressing problematic. An attacker could spoof a DUID or somehow try to impersonate another customer connection. This could either cause a misdirection of traffic or cause a DoS situation for the legitimate user. The same threats against traditional DHCP are the same as the threats against DHCPv6-PD.
If you wanted to make your address allocation system more secure, you could use a RADIUS server to authenticate the prefix delegation. You could create other ways to secure the DHCPv6 messages, but that would require more preconfiguration on the customer's equipment. The purpose of DHCPv6-PD is to make addressing simpler. If more coordination and expectations are placed on the skill of the broadband subscriber, the efficiency benefits will be lost.