cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5005
Views
15
Helpful
9
Replies

ASA-5512X/9.6.2/9.7.1 DHCPv6-PD not ready for prime time?

jgenender
Level 1
Level 1

I have been pulling my hair out about this for a while and am coming to the conclusion that the DHCPv6-PD is not working properly on Cisco ASA platform.  Here is my setup...I have the following configuration:

Arris 6183 (Bridge/passthrough) -> Cisco ASA 5512-X (running 9.7.1) -> My network

This runs on Comcast as my ISP.  I have IPv4 running just perfectly.  Comcast offers IPv6 to me since when I plug a laptop ino my modem, I get a nice IPv6 address and I can ping ipv6.google.com, etc.  I decided to try getting it to run on my Cisco ASA so I could begin using IPv6 throughout my network.  The key to all of this is having DHCPv6 working since that is what Comcast requires.  Since 9.6.2 was released, I was hopeful that the ASA platform would finally provide DHCPv6 capabilities.  With 9.6.2 I was unable to get it to work.  I tried 9.7.1 in hopes that perhaps bugs were found.  No love with that either.

My findings appear that the DHCP-PD client is not accepting or seeing RAs.  The interesting part of this is that I can see the RAs through the debug and packet captures.  Perhaps the DHCP client is broken?  or perhaps my config is just missing something that hasn't been documented.

Here is my config:

interface GigabitEthernet0/0
 nameif outside
 security-level 0
 ip address dhcp setroute
 ipv6 address autoconfig default trust dhcp
 ipv6 address dhcp default
 ipv6 enable
 ipv6 nd suppress-ra
 ipv6 nd managed-config-flag
 ipv6 nd other-config-flag
 ipv6 dhcp client pd hint ::/60
 ipv6 dhcp client pd COMCAST

Don't worry about any inside interfaces... the key is to be able to get the outside to ping out to the net.  One step at a time...

What I find interesting is I get this on the debug ipv6:

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)

I see RAs.  Ok.. good. Lets look at the debug ipv6 nd:

Lets have a look at those packets through a capture:

ICMPv6-ND: Received RA from fe80::201:5cff:fe62:a246 on outside
ICMPv6-ND: Received RA from fe80::201:5cff:fe62:a246 on outside
ICMPv6-ND: Received RA from fe80::201:5cff:fe62:a246 on outside
ICMPv6-ND: Received RA from fe80::201:5cff:fe62:a246 on outside
ICMPv6-ND: Received RA from fe80::201:5cff:fe62:a246 on outside
ICMPv6-ND: Received RA from fe80::201:5cff:fe62:a246 on outside
ICMPv6-ND: Received RA from fe80::201:5cff:fe62:a246 on outside
ICMPv6-ND: Received RA from fe80::201:5cff:fe62:a246 on outside

Looks like RAs are coming in bound.  Looks good.  Lets check the packet capture to be sure everything is good:

   1: 22:58:43.635770 0001.5c62.a246 3333.0000.0001 0x86dd Length: 198
      fe80::201:5cff:fe62:a246 > ff02::1: icmp6: router advertisement(chlim=0, MOrouter_ltime=1800, reachable_time=3600000, retrans_time=1000)
	  (prefix info: valid_ltime=604800,preferred_ltime=302400,prefix=2001:558:4070:7f::/64)
	  (prefix info: valid_ltime=604800,preferred_ltime=302400,prefix=2001:558:5021:7::/64)
	  (prefix info: valid_ltime=604800,preferred_ltime=302400,prefix=2001:558:6040:7f::/64)
	  (prefix info: valid_ltime=604800,preferred_ltime=302400,prefix=2001:558:803a:45::/64) 
	  (len 144, hlim 255) 
	  
 0x0000	 3333 0000 0001 0001 5c62 a246 86dd 6000	33......\b.F..`.
 0x0010	 0000 0090 3aff fe80 0000 0000 0000 0201	....:...........
 0x0020	 5cff fe62 a246 ff02 0000 0000 0000 0000	\..b.F..........
 0x0030	 0000 0000 0001 8600 0e9c 00c0 0708 0036	...............6
 0x0040	 ee80 0000 03e8 0304 4000 0009 3a80 0004	........@...:...
 0x0050	 9d40 0000 0000 2001 0558 4070 007f 0000	.@.... ..X@p....
 0x0060	 0000 0000 0000 0304 4000 0009 3a80 0004	........@...:...
 0x0070	 9d40 0000 0000 2001 0558 5021 0007 0000	.@.... ..XP!....
 0x0080	 0000 0000 0000 0304 4000 0009 3a80 0004	........@...:...
 0x0090	 9d40 0000 0000 2001 0558 6040 007f 0000	.@.... ..X`@....
 0x00a0	 0000 0000 0000 0304 4000 0009 3a80 0004	........@...:...
 0x00b0	 9d40 0000 0000 2001 0558 803a 0045 0000	.@.... ..X.:.E..
 0x00c0	 0000 0000 0000

Yep... looking peachy. Ok... so I run a sh ipv6 routers to see what we are getting...

Router fe80::201:5cff:fe62:a246 on outside, last update 0 min, CONFLICT
Hops 0, Lifetime 1800 sec, AddrFlag=1, OtherFlag=1
Reachable time 3600000 msec, Retransmit time 1000 msec
Prefix 2001:558:4070:7f::/64
Valid lifetime 604800, preferred lifetime 302400
Prefix 2001:558:5021:7::/64
Valid lifetime 604800, preferred lifetime 302400
Prefix 2001:558:6040:7f::/64
Valid lifetime 604800, preferred lifetime 302400
Prefix 2001:558:803a:45::/64
Valid lifetime 604800, preferred lifetime 302400

I see prefixes...I see a router... good.  But that CONFLICT doesn't look too good.  Further review of that since this is an outside interface is that the CONFLICT can be ignored.  I garnered that from this thread here:

https://supportforums.cisco.com/discussion/12713876/conflict-ipv6-routers-show-result

I am not sure if that is the problem or not.  I even tried setting access-list filter to only allow RAs from that router but it never cleared that CONFLICT. 

Now for the very interesting part...the DHCPv6 client doesn't seem to be getting these RAs... or so it reports.

# 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

Look at that... no advertise messages received.  It is as if the DHCPv6-PD client is just ignoring the advertisements completely.

My thoughts are that if the DHCPv6-PD client can "see" or accept the RAs that are being sent, everything else should fall into place.  It is as if it either doesn't receive the advertisements or its just ignoring them all together.

There are other links on the interwebz where people have gotten this working with other ISPs, such as Telstra (see http://www.alcatron.net/?tag=cisco-5506-x-ipv6).  However Comcast appears to not be compatible with the Cisco ASA DHCPv6-PD client, there is a bug, or I am just missing something completely crazy.  In this thread, https://supportforums.cisco.com/document/61451/cisco-asa-ipv6-quick-start, the Cisco employee Phillip Remaker comments "[if] you are attached to a service that provides prefixes by DHCP-PD (like Comcast), it is what you need."  So the Cisco folks are claiming it should work.  Ok... lets see it. ;-)

I have yet to find any postings that people have gotten the Cisco ASA DHCPv6-PD client working with IPv6 on Comcast anywhere.  It would be awesome if someone can show me the errors of my ways and help get this working.  I would love to see the Cisco ASAs working nicely with SLAAC/Comcast/DHCP-PD.

Any input would be greatly appreciated.

9 Replies 9

jgenender
Level 1
Level 1

So after doing a packet capture, I see the Cisco ASA doing the RS and I see the Comcast router coming back with an Advertise XID.  It has a /60 prefix in it as well which is great.

But the Cisco ASA is completely ignoring the Advertisement XID (I get 2 of them BTW ... not sure if that's the cause of the conflict).  It seems that since it ignores the advertisement, no further DHCPv6 handshaking occurs and thus I never continue with the process.

The advertisements appear to occur on port 547 inbound to 546.  I added something to the outside interface to allow that.  But still no acknowledgement that the ASA is using the DHCPv6 protocol.

Any ideas?

More info...

looked at the syslog and I see this:

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

Its getting discarded..

So I decided to look at why its getting dropped through an asp-drop capture, and I see this:

 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

Hop limit exceeded?

Sure enough in the Advertise XID, the IP6  shows:

Hop limit: 0

Not sure how to get around this... is there a way on the ASA to allow that through?  If I can prevent that drop from happening, I should get this to work...

Hitting the same issue. Using Comcast as well.

Arris 6183 (Bridge/passthrough) -> Cisco ASA 5506-X (running 9.6.2(11)) -> My network

You might want to adjust your outside interface to include the following:

ipv6 nd reachable-time 3600000

I found that when I used the same config you had on your outside interface, I would receive the following error when enabling ipv6 on the interface:

%ASA-3-325001: Router fe80::201:5cff:fe83:7e46 on outside has conflicting ND (Neighbor Discovery) settings

Show ipv6 routers would include the conflict statement as you noted. Adjusting reachable-time makes that go away, yet I am still with no ipv6 connectivity through the ASA.

Also seeing the same asp drops from the exceeded hop limit when set to 0. From the looks of things, it's a bug on Comcast's side.

Also found this post on reddit regarding the matter:

https://www.reddit.com/r/ipv6/comments/5vcd8q/cisco_asa_5500xdhcpv6comcast_issues/

Thanks for the reachable time tip.  That worked to get rid of the conflict.

AFAICT, the bug is indeed a Comcast thing.  It would be nice if they would fix it.  They claimed that RFC 2460 is still draft and therefore they don't need to apply it.  I found that rather comical since the entire IPv6 header/structure, etc, is based off that document.  They implemented 99% of it, but left out a key part of it that makes some nice Cisco routers/firewalls not work.  They should know better since their IPv6 fellow/lead John Brzozowski authored several RFCs with regard to IPv6 and you would think that this would be of concern to him - he has been informed of the issue with no response.

I have a quick update.  I upgraded to Xfinity Gigabit service today with a new docsis 3.1 Motorola MB8600 modem.

Same thing.  Hop limit is 0 and the Cisco is rejecting the packets.  I spoke to the tech and showed him the packets, etc.  He agreed Comcast has a stack problem.  He will try to escalate the issue, but I am not confident it will get far.

Luckily they are still handing our IPv4 addresses, even though his management said the gigabit is 100% ipv6.

It looks like a disaster at this stage.

I can verify the following for IPv6 DHCP on Comcast\Xfinity


Cisco ASA 9.8 and 9.9 does not have the bug fix in it as of 11/8/2018
-Verified 9.8.3 by code load on a ASA5516x doesn't work. Also no mention of the RFC 8200 fix.
-Verified 9.9.2 by looking at the release notes no mention of the RFC 8200 fix.

Only 9.10.1 has the fix as previously verified by other users

 

If you want to check the release notes in the future. Check ou this link.
https://www.cisco.com/c/en/us/support/security/asa-5500-series-next-generation-firewalls/products-release-notes-list.html

Search for: CSCvi46759 Allow ASA to process packet with hop limit of 0 (Follow RFC 8200)


My CMTS in Chicago has not been upgraded with the bug fix that has been discussed in this and other threads. Where the DHCPv6 packet from the ARRIS CMTS has a Hop Limit of 0, which is a Harris Bug. Cisco ASA will drop this packet, do a show asp drop to verify. Cisco has only impleted RFC 8200 on the 9.10.1 version of code which allows the Hop Limit to be 0.

ASA Comcast IPv6 DHCPd Working Config and show commands. ASA Version 9.10.1
---------------------------------------------------------------------------
Gi1/1 - Outside Comcast interface (Recieved a /60)
Gi1/2 - Inside LAN interface
DHCP is configured for IPv4 LAN
IPv6 LAN Addressing is autoconfig

Sorry i blocked out my IPv4/IPv6 and MAC addresses with xxxx

interface GigabitEthernet1/1
description Comcast Internet
nameif outside
security-level 0
ip address dhcp setroute
ipv6 address dhcp default
ipv6 enable
ipv6 nd suppress-ra
ipv6 dhcp client pd hint ::/56
ipv6 dhcp client pd From-Comcast

interface GigabitEthernet1/2
description LAN
nameif inside
security-level 100
ip address 192.168.1.1 255.255.255.0
ipv6 address From-Comcast ::1/64
ipv6 address autoconfig
ipv6 enable
!
dhcpd auto_config inside interface outside
!
dhcpd address 192.168.1.101-192.168.1.199 inside
dhcpd lease 86400 interface inside
dhcpd auto_config outside interface inside
dhcpd enable inside
**auto-config from interface 'outside'
**auto_config dns 75.75.75.75 75.75.76.76
**auto_config domain xxx.il.comcast.net.

 

Firewall# show interface g1/1
Interface GigabitEthernet1/1 "outside", is up, line protocol is up
Hardware is Accelerator rev01, BW 1000 Mbps, DLY 10 usec
Auto-Duplex(Full-duplex), Auto-Speed(1000 Mbps)
Input flow control is unsupported, output flow control is off
Description: Comcast Internet
MAC address 500f.80xx.xxxx, MTU 1500
IP address 73.22.xx.xx, subnet mask 255.255.254.0
27381 packets input, 16521726 bytes, 0 no buffer
Received 198 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 pause input, 0 resume input
0 L2 decode drops
24054 packets output, 5208726 bytes, 0 underruns
0 pause output, 0 resume output
0 output errors, 0 collisions, 0 interface resets
0 late collisions, 0 deferred
0 input reset drops, 0 output reset drops
input queue (blocks free curr/low): hardware (2009/1912)
output queue (blocks free curr/low): hardware (2047/2040)
Traffic Statistics for "outside":
27379 packets input, 16011367 bytes
24054 packets output, 4742192 bytes
2259 packets dropped
1 minute input rate 3 pkts/sec, 700 bytes/sec
1 minute output rate 4 pkts/sec, 876 bytes/sec
1 minute drop rate, 0 pkts/sec
5 minute input rate 14 pkts/sec, 7929 bytes/sec
5 minute output rate 13 pkts/sec, 3017 bytes/sec
5 minute drop rate, 0 pkts/sec


Firewall# sh ipv6 interface outside
outside is up, line protocol is up
IPv6 is enabled, link-local address is fe80::520f:xxxx:xxxx:166
Global unicast address(es):
2001:558:xxxx:xxxx:xxxx:xxxx:xxxx:286b, subnet is 2001:558:xxxx:xxxx:xxxx:xxxx:xxxx:286b/128
Joined group address(es):
ff02::1:ff06:286b
ff02::2
ff02::1:ffc0:166
ff02::1
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
Hosts use stateless autoconfig for addresses.
Firewall# sh ipv6 interface inside
inside is up, line protocol is up
IPv6 is enabled, link-local address is fe80::520f:xxxx:xxxx:167
Global unicast address(es):
2601:xxxx:xxxx:xxx0::1, subnet is 2601:xxxx:xxxx:xxx0::/64
Joined group address(es):
ff02::1:ff00:1
ff02::1:ffc0:167
ff02::2
ff02::1
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
ND advertised reachable time is 0 milliseconds
ND advertised retransmit interval is 1000 milliseconds
ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds
Hosts use stateless autoconfig for addresses.

 

Firewall# show ipv6 dhcp interface outside

GigabitEthernet1/1 is in client mode
Prefix State is OPEN
Renew will be sent in 1d23h
Address State is OPEN
Renew for address will be sent in 1d23h
List of known servers:
Reachable via address: fe80::201:xxxx:xxxx:9a46
DUID: 000100011xxxxxxxxxxxxxxCC
Preference: 0
Configuration parameters:
IA PD: IA ID 0x00020001, T1 172800, T2 276480
Prefix: 2601:xxxx:xxxx:xxx0::/60
preferred lifetime 345600, valid lifetime 345600
expires at Nov 12 2018 12:19 AM (344444 seconds)
IA NA: IA ID 0x00020001, T1 172800, T2 276480
Address: 2001:558:xxxx:xxxx:xxxx:xxxx:xxxx:286b/128
preferred lifetime 345600, valid lifetime 345600
expires at Nov 12 2018 12:19 AM (344456 seconds)
DNS server: 2001:558:feed::1
DNS server: 2001:558:feed::2
Information refresh time: 0
Prefix name: From-Comcast
Prefixes sent as hint:
::/56


See the IPv6 address Leased out to the LAN

Firewall# show ipv6 neighbor
IPv6 Address Age Link-layer Addr State Interface
2601:xxxx:xxxx:xxx0:3xxx:xxxx:xxxx:xxx3 9 70xx.xxxx.xxxa STALE inside
2601:xxxx:xxxx:xxx0:6xxx:xxxx:xxxx:xxx6 3 74xx.xxxx.xxxd STALE inside
fe80::xxxx:xxxx:xxxx:xxx6 1 00xx.xxxx.xxx6 STALE outside
fe80::xxxx:xxxx:xxxx:xxx3 1 18xx.xxxx.xxxb STALE inside
fe80::xxxx:xxxx:xxxx:xxxb 11 74xx.xxxx.xxxd STALE inside

Firewall# show dhcpd binding

IP address Client Identifier Lease expiration Type

192.168.1.101 0190.xxxx.xxxx.x1 85313 seconds Automatic
192.168.1.102 0170.xxxx.xxxx.xa 85323 seconds Automatic
192.168.1.103 0134.xxxx.xxxx.xe 85525 seconds Automatic

Since this topic has not been updated in some time, and if someone encounters this issue, I wanted to post an update. Cisco has issued fixed software for this issue detailed in bug:

 

Allow ASA to process packet with hop limit of 0 (Follow RFC 8200)
CSCvi46759
 
For the ASA 9.8 train, release 9.8(4) and higher fixes this bug.
And, of course, ASA 9.10(1) and higher fixes this bug.
 

Thanks for the update

No worries!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: