As many of you may know, I used to move packets around for a living. I’m not doing that any more, but I’m still administering my own little home network and keeping my hand in. After my old consumer-grade ADSL modem packed it in, I decided that I’d like to do something a bit more interesting and so I busted out the old 1841 router, got a new TP-Link DSL modem in bridge mode and decided to hook up IPv6.
I’m lucky in that my existing home provider is Internode, and Internode seems to have always been at the forefront of IPv6 in Australia. Internode recently became a subsidiary of iinet, so I hope this doesn’t change. (un-Disclaimer: I have not, and do not work for Internode; I’ve never received any payments or goodies from Internode. I have been a customer for quite a few years). In a former incarnation in the early 2000s, I attended an IPv6 Summit which brought together carriers, industry, government and education (I still have the tote bag). Simon Hackett, the founder of Internode spoke about his intention then to make IPv6 available across their network and I was impressed by his enthusiasm and commitment to IPv6 in some stark contrast to other carriers and organisations. As one of the smaller carriers, it was probably easier for Internode to be agile enough to overcome the inertia which seems to be hindering IPv6 globally.
Internode uses prefix delegation, and has handy guides for Cisco devices. As one whose hands on experience with IPv6 is mostly theoretical and tailored to certification test-taking, I thought I might break down prefix delegation and see how it works in practice.
Prefix delegation pretty much does what it says on the tin. Unlike conventional IPv4 subscriber connectivity, your provider sends your site a prefix instead of a single IP address. For example, Internode by default delegates each customer a /56 subnet. For most residential (and heck, most other types of customers) this is an enormous amount of address space – 256 /64s or even more if you want to go to smaller subnets.
Lets fire up trusty old GNS3 and see how we do prefix delegation.
I’ve set spoofed MAC addresses so GNS3 creates unique link-local addresses. As the provider (R1), I have an address block I’m going to use of FDAB:CDEF::/40 and I’m going to delegate /56 prefixes to my clients. On the client side, all configuration will be auto configuration and DHCPv6.
The actual uplink connection is on a separate /64; R1’s IPv6 address on this link is FDAA::1/64. Of course, turn on your IPv6 unicast-routing and CEF.
First, on R1, define your pool for delegation:
ipv6 local pool DELIGv6POOL FDAB:CDEF::/40 56
This command specifies that the name of the pool is “DELIGv6POOL”, the address block is my /40 and I am delegating /56 prefixes.
Next, configure DHCPv6:
ipv6 dhcp pool DHCPv6POOL
prefix-delegation pool DELIGv6POOL lifetime 1800 600
Here we link the pool for prefix delegation to our DHCPv6 pool. Finally for the provider side, we assign the DHCPv6 pool (DHCPv6POOL) to the interface facing our client:
no ip address
ipv6 address FDAA::1/64
ipv6 dhcp server DHCPv6POOL
And that’s it for our provider. Checking our DHCPv6 configuration:
R1#sho ipv6 dhcp pool
DHCPv6 pool: DHCPv6POOL
Prefix pool: DELIGv6POOL
preferred lifetime 600, valid lifetime 1800
and our interface (trimmed for space):
R1#sho ipv6 int f0/0
IPv6 is enabled, link-local address is FE80::200:11FF:FE11:1111
Global unicast address(es):
FDAA::1, subnet is FDAA::/64
Hosts use stateless autoconfig for addresses.
This verifies that our DHCPv6 and prefix delegation pools are active on the interface, and the router facing us will be configured using autoconfig for its address.
On to the client side (R2). First, set up the interface facing the provider.
no ip address
ipv6 address autoconfig default
ipv6 dhcp client pd PREFDEL rapid-commit
The interface’s address is set using autoconfig and the default keyword causes a default route to be added to the routing table. Another way this can be done is to actually set the interface address using the delegated prefix itself (as Internode does), but I’m not doing that here. If you do that, you have to put in a default route manually (or use a protocol). The important bit is the final line. Here, the router obtains the prefix delegation and we assign the name “PREFDEL” as our reference.
Checking the IPv6 DHCP for this interface, we can see the details of the delegated prefix (again, trimmed for brevity).
FastEthernet0/0 is in client mode
Prefix State is OPEN
IA PD: IA ID 0x00040001, T1 300, T2 480
preferred lifetime 600, valid lifetime 1800
expires at May 15 2014 05:27 PM (1788 seconds)
Prefix name: PREFDEL
Next, for my clients, I want to give them their DNS host, so I need to set up DHCPv6 on my client router and serve out one of the Google IPv6 DNS hosts:
ipv6 dhcp pool DHCPv6
Now to use our delegated /56. I have two interfaces, and I wish to use /64s for each. There are 256 /64s in the /56. Our prefix is FDAB:CDEF:0000:00 and the next 8 bits are significant for our /64 subnets, so I am going to choose my subnets as FDAB:CDEF:0:1::/64 and FDAB:CDEF:0:2::/64. For my first subnet on Fa1/1, I configure the interface as follows:
no ip address
ipv6 address PREFDEL ::1:0:0:0:1/64
ipv6 nd other-config-flag
ipv6 dhcp server DHCPv6
OK, so quite a bit going on here. The important part is that our IPv6 address is our delegated prefix (PREFDEL) and we add the significant part for the subnet and the rest of the address. Don’t worry, if you get the subnet part wrong (e.g. overlapping the prefix or overlapping another interface) the router will let you know. Next, we turn on the DHCP server, and then line “ipv6 nd other-config-flag” tells any client (which will get its address via autoconfig) to look to the DHCPv6 server for its other configuration (i.e. the DNS server).
Similarly, for our second interface, simply specify the subnet part with our prefix again:
ipv6 address PREFDEL ::2:0:0:0:1/64
So, checking on our IPv6 addresses (I’ve excluded link-local):
R2#sho ipv6 int brief | exclude FE80
The interface facing the provider is auto configured, and our client subnets are configured. Checking the IPv6 “general-prefix command”:
R2#sho ipv6 general-prefix
IPv6 Prefix PREFDEL, acquired via DHCP PD
FDAB:CDEF::/56 Valid lifetime 1590, preferred lifetime 390
FastEthernet1/0 (Address command)
FastEthernet1/1 (Address command)
We can see our prefix was delegated using DHCP, and has been used on Fa1/0 and Fa1/1 using an “ipv6 address” command.
The VPCS have obtained their IP addresses for their subnets, and can ping each other and the provider IP address.
VPCS> show ipv6 all
NAME IP/MASK ROUTER LINK-LAYER MTU
fdab:cdef:0:1:2050:79ff:fe66:6800/64 00:00:22:22:33:33 1500
fdab:cdef:0:2:2050:79ff:fe66:6801/64 00:00:22:22:11:11 1500
VPCS> ping fdaa::1
fdaa::1 icmp6_seq=1 ttl=63 time=74.082 ms
fdaa::1 icmp6_seq=2 ttl=63 time=31.927 ms
VPCS> ping fdab:cdef:0:2:2050:79ff:fe66:6801
fdab:cdef:0:2:2050:79ff:fe66:6801 icmp6_seq=1 ttl=62 time=32.074 ms
fdab:cdef:0:2:2050:79ff:fe66:6801 icmp6_seq=2 ttl=62 time=21.352 ms
So there you have it. With a bit more configuration, you can provide a fixed delegation or with this, the prefixes are handed out on first-come first served. The client is assigned a potentially dynamic prefix, but they can perform their own subnetting without caring what that delegated prefix is. Now admittedly, most clients (especially home or small business customers) probably don’t care about subnets and maybe even a /64 is overkill, but prefix delegation is easy and flexible and perhaps has use in larger campus or hub-and-spoke type networks.
Well, enough networking for now. Back to measuring magnetic fluxes on F type stars.