Trying out IPv6 Prefix Delegation
In this post i will show how and why to use a feature called IPv6 Prefix Delegation (PD).
IPv6 prefix delegation is a feature that provides the capability to delegate or hand out IPv6 prefixes to other routers without the need to hardcode these prefixes into the routers.
Why would you want to do this? – Well, for one is the administration overhead associated with manual configuration. If the end-customer only cares about the amount of prefixes he or she receives, then it might as well be handed out automatically from a preconfigure pool. Just like DHCP works today on end-user systems.
On top of that, by configuring a redistribution into BGP just once, you will automatically have reachability to the prefixes that has been handed out, from the rest of your SP network.
So how do you go about configuring this? – Well, lets take a look at the topology we’ll be using to demonstrate IPv6 Prefix Delegation.
First off, we have the SP core network which consists of R1, R2 and R3. They are running in AS 64512 with R1 being a BGP route-reflector for the IPv6 unicast address-family. As an IGP we are running OSPFv3 to provide reachability within the core. No IPv4 is configured on any device.
The SP has been allocated a /32 IPv6 prefix which is 2001:1111::/32, from which it will “carve” out IPv6 prefixes to both its internal network as well as customer networks.
We are using /125 for the links between the core routers, just to make it simple when looking at the routing tables and the topology.
R2 is really where all the magic is taking place. R2 is a PE for two customers, Customer A and Customer B. Customer A is being reached through Gigabit2 and Customer B through Gigabit3. The customer’s respective CE routers are R4 and R7.
There is a link-net between R2 and R4 as well as R2 and R7. These are respectively 2001:1111:101::/64 and 2001:1111:102::/64.
So Lab-ISP has decided to use a /48 network from which to hand out prefixes to its customers. This /48 is 2001:1111:2222::/48. Lab-ISP also decided to hand out /56 addresses which will give the customers 8 bits (from 56 to 64) to use for subnetting. This is a typical deployment.
Also, since we are using a /48 as the block to “carve” out from, this gives us 8 bits (from 48 to 56) of assignable subnets, which ofcourse equals to 256 /56 prefixes we can hand out.
All of this can be a bit confusing, so lets look at it from a different perspective.
We start out with 2001:1111:2222::/48. We then want to look at how the first /56 looks like:
The 2001:1111:2222:0000::/56 is
2001:1111:2222:0000::
until
2001:1111:2222:00FF::
That last byte (remember this is all in hex) is what gives the customer 256 subnets to play around with.
The next /56 is:
2001:1111:2222:0100::/56
2001:1111:2222:0100::
until
2001:1111:2222:01FF::
We can do this all in all 256 times as mentioned earlier.
So in summary, with two customers, each receiving a /56 prefix, we would expect to see the bindings show up on R2 as:
2001:1111:2222::/56
2001:1111:2222:100::/56
So with all this theory in place, lets take a look at the configuration that makes all this work out.
First off we start out with creating a local IPv6 pool on R2:
ipv6 local pool IPv6-Local-Pool 2001:1111:2222::/48 56
This is in accordance to the requirements we have stated earlier.
Next up, we tie this local pool into a global IPv6 pool used specifically for Prefix Delegation:
ipv6 dhcp pool PD-DHCP-POOL prefix-delegation pool IPv6-Local-Pool
Finally we attach the IPv6 DHCP pool to the interfaces of Customer A and Customer B:
R2#sh run int g2 Building configuration... Current configuration : 132 bytes ! interface GigabitEthernet2 no ip address negotiation auto ipv6 address 2001:1111:101::2/64 ipv6 dhcp server PD-DHCP-POOL end R2#sh run int g3 Building configuration... Current configuration : 132 bytes ! interface GigabitEthernet3 no ip address negotiation auto ipv6 address 2001:1111:102::2/64 ipv6 dhcp server PD-DHCP-POOL end
Thats pretty much all thats required from the SP point of view in order to hand out the prefixes.
Now, lets take a look at whats required on the CE routers.
Starting off with R4’s interface to the SP:
R4#sh run int g2 Building configuration... Current configuration : 156 bytes ! interface GigabitEthernet2 no ip address negotiation auto ipv6 address 2001:1111:101::3/64 ipv6 address autoconfig ipv6 dhcp client pd LOCAL-CE end
Note that the “LOCAL-CE” is a local label we will use for the next step. It can be anything you desire.
Only when the “inside” interfaces requests an IPv6 address will a request be sent to the SP for them to hand something out. This is done on R4’s g1.405 and g1.406 interfaces:
R4#sh run int g1.405 Building configuration... Current configuration : 126 bytes ! interface GigabitEthernet1.405 encapsulation dot1Q 405 ipv6 address LOCAL-CE ::1:0:0:0:1/64 ipv6 address autoconfig end R4#sh run int g1.406 Building configuration... Current configuration : 126 bytes ! interface GigabitEthernet1.406 encapsulation dot1Q 406 ipv6 address LOCAL-CE ::2:0:0:0:1/64 ipv6 address autoconfig end
Here we reference the previous local label “LOCAL-CE”. Most interesting is the fact that we are now subnetting the /56 prefix we have received by doing the “::1:0:0:0:1/64” and “::2:0:0:0:1/64” respectively.
What this does is that it appends the address to whats being given out. To repeat, for Customer A, this is 2001:1111:2222::/56 which will then be a final address of: 2001:1111:2222:1:0:0:0:1/64 for interface g1.405 and 2001:1111:2222:2:0:0:0:1/64 for g1.406.
Lets turn our attention to Customer B on R7.
Same thing has been configured, just using a different “label” for the assigned pool to show that its arbitrary:
R7#sh run int g3 Building configuration... Current configuration : 155 bytes ! interface GigabitEthernet3 no ip address negotiation auto ipv6 address 2001:1111:102::7/64 ipv6 address autoconfig ipv6 dhcp client pd CE-POOL end
And the inside interface g1.100:
R7#sh run int g1.100 Building configuration... Current configuration : 100 bytes ! interface GigabitEthernet1.100 encapsulation dot1Q 100 ipv6 address CE-POOL ::1:0:0:0:7/64 end
Again, we are subnetting the received /56 into a /64 and applying it on the inside interface.
Going back to the SP point of view, lets verify that we are handing out some prefixes:
R2#sh ipv6 local pool Pool Prefix Free In use IPv6-Local-Pool 2001:1111:2222::/48 254 2
We can see that our local pool has handed out 2 prefixes and if we dig further down into the bindings:
R2#sh ipv6 dhcp binding
Client: FE80::250:56FF:FEBE:93CC
DUID: 00030001001EF6767600
Username : unassigned
VRF : default
Interface : GigabitEthernet3
IA PD: IA ID 0x00080001, T1 302400, T2 483840
Prefix: 2001:1111:2222:100::/56
preferred lifetime 604800, valid lifetime 2592000
expires at Oct 16 2014 03:11 PM (2416581 seconds)
Client: FE80::250:56FF:FEBE:4754
DUID: 00030001001EE5DF8700
Username : unassigned
VRF : default
Interface : GigabitEthernet2
IA PD: IA ID 0x00070001, T1 302400, T2 483840
Prefix: 2001:1111:2222::/56
preferred lifetime 604800, valid lifetime 2592000
expires at Oct 16 2014 03:11 PM (2416575 seconds)
We see that we do indeed have some bindings taking place. Whats of more interest though, is the fact that static routes have been created:
R2#sh ipv6 route static | beg a - Ap
a - Application
S 2001:1111:2222::/56 [1/0]
via FE80::250:56FF:FEBE:4754, GigabitEthernet2
S 2001:1111:2222:100::/56 [1/0]
via FE80::250:56FF:FEBE:93CC, GigabitEthernet3
So two static routes that points to the CE routers. This makes it extremely simple to propagate further into the SP core:
R2#sh run | sec router bgp router bgp 64512 bgp router-id 2.2.2.2 bgp log-neighbor-changes no bgp default ipv4-unicast neighbor 2001:1111::12:1 remote-as 64512 ! address-family ipv4 exit-address-family ! address-family ipv6 redistribute static neighbor 2001:1111::12:1 activate exit-address-family
Ofcourse some sort of filtering should be used instead of just redistributing every static route on the PE, but you get the point. So lets check it out on R3 for example:
R3#sh bgp ipv6 uni | beg Network
Network Next Hop Metric LocPrf Weight Path
*>i 2001:1111:2222::/56
2001:1111::12:2 0 100 0 ?
*>i 2001:1111:2222:100::/56
2001:1111::12:2 0 100 0 ?
We do indeed have the two routes installed.
So how could the customer setup their routers to learn these prefixes automatically and use them actively?
Well, one solution would be stateless autoconfiguration, which i have opted to use here along with setting the default route doing this, on R5:
R5#sh run int g1.405
Building configuration...
Current configuration : 96 bytes
!
interface GigabitEthernet1.405
encapsulation dot1Q 405
ipv6 address autoconfig default
end
R5#sh ipv6 route | beg a - Ap
a - Application
ND ::/0 [2/0]
via FE80::250:56FF:FEBE:49F3, GigabitEthernet1.405
NDp 2001:1111:2222:1::/64 [2/0]
via GigabitEthernet1.405, directly connected
L 2001:1111:2222:1:250:56FF:FEBE:3DFB/128 [0/0]
via GigabitEthernet1.405, receive
L FF00::/8 [0/0]
via Null0, receive
and R6:
R6#sh run int g1.406
Building configuration...
Current configuration : 96 bytes
!
interface GigabitEthernet1.406
encapsulation dot1Q 406
ipv6 address autoconfig default
end
R6#sh ipv6 route | beg a - App
a - Application
ND ::/0 [2/0]
via FE80::250:56FF:FEBE:49F3, GigabitEthernet1.406
NDp 2001:1111:2222:2::/64 [2/0]
via GigabitEthernet1.406, directly connected
L 2001:1111:2222:2:250:56FF:FEBE:D054/128 [0/0]
via GigabitEthernet1.406, receive
L FF00::/8 [0/0]
via Null0, receive
So now we have the SP core in place, we have the internal customer in place. All thats really required now is for some sort of routing to take place on the CE routers toward the SP. I have chosen the simplest solution, a static default route:
R4#sh run | incl ipv6 route ipv6 route ::/0 2001:1111:101::2
and on R7:
R7#sh run | incl ipv6 route ipv6 route ::/0 2001:1111:102::2
Finally its time to test all this stuff out in the data plane.
Lets ping from R3 to R5 and R6:
R3#ping 2001:1111:2222:1:250:56FF:FEBE:3DFB Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:1111:2222:1:250:56FF:FEBE:3DFB, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/12/20 ms R3#ping 2001:1111:2222:2:250:56FF:FEBE:D054 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:1111:2222:2:250:56FF:FEBE:D054, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/7/17 ms
And also to R7:
R3#ping 2001:1111:2222:101::7 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:1111:2222:101::7, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/8/18 ms
Excellent. Everything works.
Lets summarize what we have done.
1) We created a local IPv6 pool on the PE router.
2) We created a DHCPv6 server utilizing this local pool as a prefix delegation.
3) We enabled the DHCPv6 server on the customer facing interfaces.
4) We enabled the DHCPv6 PD on the CE routers (R4 and R7) and used a local label as an identifier.
5) We enabled IPv6 addresses using PD on the local interfaces toward R5, R6 on Customer A and on R7 on Customer B.
6) We used stateless autoconfiguration internal to the customers to further propagate the IPv6 prefixes.
7) We created static routing on the CE routers toward the SP.
8) We redistributed statics into BGP on the PE router.
9) We verified that IPv6 prefixes were being delegated through DHCPv6.
10) And finally we verified that everything was working in the data plane.
I hope this has covered a pretty niche topic of IPv6 and it has been useful to you.
Take care!