I have been a faithful Cisco user for many years as my primary router/firewall. Their firewalls are certainly pricey, but you get what you pay for. Ever since the Cisco ASA 5505 was deprecated they lacked any real IPv6 support. I decided to upgrade to one of their newer generation Cisco ASA 5500-X models. The 5506-X hadn't been released and I trolled eBay to find a raging deal on an ASA 5512-X. Its a fantastic firewall and have been happy. The only problem was that even though it supported IPv6, it did not support DHCPv6 Prefix Delegation (PD) client. This prevented me from being able to use IPv6 since that was what my ISP Comcast/Xfinity uses.
The Issue, the Tech, the Dumps
In August 2016, Cisco released a newer firmware 9.6.2 that they touted support for DHCPv6-PD. So I decided to download and try. I had difficulty finding anyone who was able to get it working, but found an excellent post by a guy who was able to get it working on Telstra (Australian ISP). I tried out his configuration and got nothing. So I put it away for a couple of months and then decided to try again in January 2017. I set up the config, and I got nothing. I tried newer versions of the firmware in hopes that it was a Cisco bug, but it was still to no avail. So I decided to dig deeper.
How DHCPv6 works is that periodically, the DHCPv6 Server sends out a Router Advertisement (RA) a broadcast packet. This tells your client about server routers and who you will communicate with. Your DHCPv6, receives this, takes the RA and sends a Router Solicit (RS) from UDP ports 546 to 547 on the server where you ask for a prefix size (how many IPv6 addresses you will want to use) and DNS information. The DHCPv6 server replies with an Advertisement XID which contains information on the prefix blocks you can use and the DNS information. The DHCPv6 Client takes that information and sends back a Request XID stating that it will use a certain Prefix and various options. The DHCPv6 then sends a Reply XID which contains the prefix that has been allocated to you. The entire process looks like this:
Digging DeeperGoing through the Cisco docs, I can start looking at the debugging of the packets. So I looked at debugging the Router Advertisements and found this:
router# debug ipv6 nd
ICMPv6-ND: Received RA from fe80::201:5cff:fe62:a246 on outside ICMPv6-ND: Sending RA to ff02::1 on nlp_int_tap ICMPv6-ND: MTU = 1500 ICMPv6-ND: prefix = fd00:0:0:1::/64 onlink autoconfig ICMPv6-ND: 2592000/604800 (valid/preferred)
Looks good... Comcast is doing what they are supposed to. I get the router advertisement. My RS packets appear to be set up to send out every minute and a half, so waiting, I noticed the RS packet being sent to Comcast's router. So far so good, except I never receive back an Advertisement.
# sh ipv6 dhcp client pd statistics Protocol Exchange Statistics: Total number of Solicit messages sent: 474 Total number of Advertise messages received: 0 Total number of Request messages sent: 0 Total number of Renew messages sent: 0 Total number of Rebind messages sent: 0 Total number of Reply messages received: 0 Total number of Release messages sent: 0 Total number of Reconfigure messages received: 0 Total number of Information-request messages sent: 0
After going through the Cisco docs, it looks like I can set up an ACL to capture a dump of the traffic on the outside interface. So off I go:
router(config)# cap capout interface outside access-list test_ipv6
router(config)# show cap capout
7 Feb 20 2017 21:11:34 fe80::201:5cff:fe62:a246 547 fe80::f60f:1bff:fe76:fa57 546
UDP request discarded from fe80::201:5cff:fe62:a246/547 to outside:fe80::f60f:1bff:fe76:fa57/546
271: 22:27:48.672648 fe80::201:5cff:fe62:a246.547 > fe80::f60f:1bff:fe76:fa57.546: udp 121 [hlim 0] Drop-reason: (hop-limit-exceeded) hop-limit exceeded
272: 22:27:48.674983 fe80::201:5cff:fe62:a246.547 > fe80::f60f:1bff:fe76:fa57.546: udp 121 [hlim 0] Drop-reason: (hop-limit-exceeded) hop-limit exceeded
Internet Protocol Version 6, Src: fe80::201:5cff:fe62:a246, Dst: fe80::8c4:4700:22ad:bfd8
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic class: 0x00 (DSCP: CS0, ECN: Not-ECT)
.... .... .... 0000 0000 0000 0000 0000 = Flow label: 0x00000
Payload length: 133
Next header: UDP (17)
Hop limit: 0
[Source SA MAC: Cadant_62:a2:46 (00:01:5c:62:a2:46)]
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 547, Dst Port: 546
Section 3 (p. 4):Hop Limit 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero.
Section 8.2 (p. 27):8.2 Maximum Packet Lifetime Unlike IPv4, IPv6 nodes are not required to enforce maximum packet lifetime. That is the reason the IPv4 "Time to Live" field was renamed "Hop Limit" in IPv6. In practice, very few, if any, IPv4 implementations conform to the requirement that they limit packet lifetime, so this is not a change in practice. Any upper-layer protocol that relies on the internet layer (whether IPv4 or IPv6) to limit packet lifetime ought to be upgraded to provide its own mechanisms for detecting and discarding obsolete packets.