IPv6 Address Management and Security Questions

[bjackson.3]

I'm trying to draft an IPv6-based version of our location's current routing configuration in anticipation of when our ISP will finally roll it out, and address management has been giving me the biggest headache - ironic, considering IPv6 was supposed to simplify address allocation.

My first config draft was made assuming that I would be getting a static /56 or /60 prefix from the ISP, and I was just going to insert the prefix into my DHCP pools and there would be no issues. That was before reading around and discovering that some ISPs are considering prefix delegation (PD) for both residential and business accounts instead of static blocks. Now I have questions about how to stick as close to the current IPv4 configuration as possible.

For the PD scenario, what I am looking at now are two addresses ranges for each network - a ULA /120 space that I want to control using stateful DHCPv6, and the global space which can be /64 and auto-configured. That way there will be a "private" address space for internal routing in the event of a prefix change or an extended outage. But I'm not sure how the config should look for such a scenario. What I have drafted so far is this:

ipv6 dhcp pool DHCP6_INTERNAL
 address prefix FDAB::1:0/120
 domain-name whatever.net
 dns-server FDAB::1:1
!
ipv6 dhcp pool DHCP6_DMZ-WIFI
 address prefix FDAB::2:0/120
 domain-name guest.whatever.net
 dns-server FDAB::2:1
!

interface GigabitEthernet0
 description WAN-LINK
 ipv6 enable
 ipv6 address dhcp
 no ipv6 unreachables
 no ipv6 redirects
 ipv6 flow ingress
 ipv6 flow egress
 ipv6 virtual-reassembly in
 ipv6 nd autoconfig default-route
 ipv6 dhcp client pd hint ::/56
 ipv6 dhcp client pd ISP-PREFIX
 zone-member security OUTSIDE
 speed auto
 duplex auto
 no cdp enable

!
interface FastEthernet8.1
 description VLAN_1-INTERNAL
 encapsulation dot1Q 1 native
 ipv6 enable
 ipv6 address FDAB::1:1/120
 ipv6 address ISP-PREFIX ::1:0:0:0:1/64
 ipv6 flow ingress
 ipv6 flow egress
 ipv6 virtual-reassembly in
 zone-member security INSIDE
 ip tcp adjust-mss 1300
 ipv6 dhcp server DHCP6_INTERNAL
 ipv6 nd managed-config-flag
 ipv6 nd other-config-flag
!
interface FastEthernet8.2
 description VLAN_2-DMZ-WIFI
 encapsulation dot1Q 2
 ipv6 enable
 ipv6 address FDAB::2:1/120
 ipv6 address ISP-PREFIX ::2:0:0:0:1/64
 ipv6 flow ingress
 ipv6 flow egress
 ipv6 virtual-reassembly in
 zone-member security DMZ
 ip tcp adjust-mss 1300
 ipv6 dhcp server DHCP6_DMZ-WIFI
 ipv6 nd managed-config-flag
 ipv6 nd other-config-flag
!

Will this config work? By which I mean: will the DHCPv6 servers provide ULA addresses, and will SLAAC work for global address allocation? If not, what needs to be changed?

Also, another question. I found a few references to a prefix name (the "ISP-PREFIX") which can be used as part of a static IPv6 address on an interface, which is a good idea in case the prefix changes. But that brings up another concern - if the prefix changes, that will invalidate ACLs referencing the global addresses using the previous prefix. Is there anything similar to the prefix name string that can be used in ACLs to keep this from occurring?

[Marc Luethi]

DHCPv6-PD is not necessarily dynamic the same way as DHCP was with the public IPv4 addresses in the IPv4 world.

While the outside network (PPPoE, DHCPv6, anything) might be truly dynamic and changing with possibly every login session, the DHCPv6 delegated prefix might be tied to your login credentials or DHCPv6 client's DUID after the first connection. A bit like a DHCP lease reservation.

If that is the case, there is some possibility that your ISP will run reverse route injection, and will always route your "fixed" prefix  to the currently active dynamic "outside" address.

Talk to your ISP and have them confirm that, once the PD'd /48 or /56 is initially assigned, it won't change, and that the same prefix will be delegated every time. Then you can treat it as if it were fully static, and you won't have to go down the ULA path.

I contacted one of our local ISPs, and they're doing it exactly that way: PPPoE for IPv4 and IPv6 (fully dynamic), and DHCPv6-PD with the /48 tied to the PPPoE login credentials. I might change to that ISP sooner or later.

With my current ISP, my IPv6 access is 6RD based. I get a /60, with my current public ipv4 address (by DHCP) embedded into those 60 bits. Readressing is bound to happen sooner or later, and it happens every so often, and it breaks my IPv6 ACLs.

I'm also looking for a way to write IPv6 ACLs with wildcard bits, not prefix/mask, so I can use them with ZBFW. So far, no sign of it.

A few more comments:

ULA addressing: 

It may look tempting, plausible and intuitive to use dual global and ULA addressing. 

I started this way as well. However, it turns out that Windows 7 has (had?) some issues with proper source address selection. The "longest common prefix" rule never seemed to work properly. In some cases, it would pick the global address to talk to ULA hosts, or stubbornly insist to use the ULA address to talk to an IPv6 internet host. It was a frustrating experience. Be sure to test this to the full extent (and back, and again and then some more) with every operating system you intend to use.

Using /120:

Be sure to test this as well, and very thoroughly. Subnet masks longer than /64 are sometimes called "uncharted territory" in IPv6. Longer subnet masks will break SLAAC, and there may be (embedded) devices that will not react benevolently to a subnet mask other than /64, or simply lack support for DHCPv6.

adjust-mss

I see you have "ip tcp adjust-mss 1300". While PMTUd may be mandatory with IPv6, I found it being broken already :-( . "ipv6 tcp adjust-mss .... " is now a separate command since IOS 15.4(1). I would suggest considering it, depending with your experience with PMTUd on IPv6.

[bjackson.3]

For the DHCPv6/PD and PMTUd -

It doesn't appear that our ISP has rolled out IPv6 yet, nor have they indicated how they will provide addressing. Plus, there isn't a compelling reason to switch over if they implement dual-stack, especially if the protocol and equivalent features aren't mature yet. I was being proactive in trying to get the configuration ready in case something happens and the trigger needs to be pulled. Thanks for mentioning the "ipv6 tcp adjust-mss" command, I haven't seen that yet and will work that in.

For the /120 and ULA  -

Even given the exponentially bigger address pool, I think the same mistakes are being made with IPv6 allocation that were made at the beginning of IPv4 allocation, and I don't need a larger internal pool than 256 addresses. There was no intention of the ULA spaces being auto-configured; I was going to get as close to current DHCP behavior as possible with these addresses. That being said, your caution regarding devices that don't recognize stateful DHCPv6 is appreciated and noted.

In my original draft, I had no intention of using ULA addresses. And if our ISP gives us a static /56 or /60 prefix (or if they do a "reservation" by tying the DUID to the prefix), there won't be any need do ULAs; I'll just include the prefix in the DHCP pool that I had in my original design, and that should be good.

Finally, it's disappointing that Cisco has implemented name strings for IPv6 prefixes, but not ACL support for those strings. It's almost like security is an afterthought here...