Spectrum not routing IPv6 prefix delegation addresses
-
I am having issues setting up IPv6 at home connected to Spectrum. My WAN interface can ping IPv6 sites successfully but traffic sent from the IPv6 prefix delegation range is not getting return traffic from Spectrum.
-
WAN interface has DHCPv6 enabled and requesting an /56 prefix delegation.
-
WAN interface gets assigned 2605:6000:9fc0:79:xxxx:xxxx:xxxx:xxxx and I receive the 2603:8080:xxxx:xxxx:: /56 IPv6 prefix.
-
My LAN/DMZ interfaces are using Track Interface and getting a global address assignment within the /56 prefix range.
-
DHCPv6 Server & RA configured. LAN networks are receiving a /64 from the /56 prefix. Workstations are receiving a global IP address from the /64 range assigned to their subnet.
Here are packet captures between the pfSense router and my modem. The modem is my equipment and is not a firewall.
DHCPv6 capture between pfSense WAN and Spectrum router:
Advertise XID DHCPv6 Packet addressing verification:
Failed ping from my workstation seen leaving the WAN interface.
WAN interface can ping6 the same dst address and reach IPv6 DNS/NTP
Spectrum support was not helpful. They just claimed my internet is working fine. They are not completely wrong, I am not having IPv4 issues or issues with the IPv6 WAN address. The weird thing is the IP prefix delegation did work initially. I set it up on one LAN interface and traffic was passing. When I copied the configuration to the other LAN interfaces and rebooted the router, the connection stopped working. IPv6 traffic from that /56 delegation range leaves my workstation and routes successfully out the WAN interface but I don't see return traffic.
Am I doing something wrong or is Spectrum's routing to that /56 broken?
-
-
@drideout said in Spectrum not routing IPv6 prefix delegation addresses:
Am I doing something wrong or is Spectrum's routing to that /56 broken?
I had a similar problem with my ISP, a major cable company, almost 5 years ago. IPv6 was working fine and then stopped. My WAN address worked, but nothing from my prefix. I demonstrated to the 2nd level support that the pings were going out but no reply. I also showed that when I pinged something on my LAN from elsewhere, they weren't even arriving at my WAN interface. This told me it was a problem with routing somewhere. I then got a senior tech to my home and showed him the problem. He then tried with his modem and computer and had the same problem. BTW, this was after I found my next door neighbour had the same problem and I was able, using packet captures, toshow there was an error message from the CMTS. I was even able to identify the failing CMTS by host name. The senior tech then went to the head end and tried 4 different CMTS. It only failed on the one I was connected to. After that, they fixed the problem. It took a lot of effort on my part, far beyond what any customer should have to do to get it fixed. I also have over half a century of experience in telecom, computers and networks, so my abilities and knowledge are far beyond that of a typical customer and even much of my ISPs tech support.
BTW, a few months ago, I was doing some work in my ISPs local office and saw the offending CMTS.
PfSense running on Qotom mini PC
i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
UniFi AC-Lite access pointI haven't lost my mind. It's around here...somewhere...
-
BTW, here's the error message from the CMTS, with the relevant info in bold:
Frame 29: 214 bytes on wire (1712 bits), 214 bytes captured (1712 bits)
on interface 0
Ethernet II, Src: Casa_9a:a1:99 (00:17:10:9a:a1:99), Dst:
Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea)
Internet Protocol Version 6, Src: fe80::217:10ff:fe9a:a199, Dst:
fe80::214:d1ff:fe2b:edea
User Datagram Protocol, Src Port: 547, Dst Port: 546
DHCPv6
Message type: Reply (7)
Transaction ID: 0x18a8e9
Client Identifier
Option: Client Identifier (1)
Length: 14
Value: 0001000123eb5e12001617a7f2d3
DUID: 0001000123eb5e12001617a7f2d3
DUID Type: link-layer address plus time (1)
Hardware type: Ethernet (1)
DUID Time: Feb 4, 2019 15:33:22.000000000 EST
Link-layer address: 00:16:17:a7:f2:d3
Server Identifier
Option: Server Identifier (2)
Length: 14
Value: 00010001159bb6e50021285fd2b7
DUID: 00010001159bb6e50021285fd2b7
DUID Type: link-layer address plus time (1)
Hardware type: Ethernet (1)
DUID Time: Jun 27, 2011 17:47:17.000000000 EDT
Link-layer address: 00:21:28:5f:d2:b7
Identity Association for Prefix Delegation
Option: Identity Association for Prefix Delegation (25)
Length: 72
Value: 000000000000000000000000000d003800064e6f20707265...
IAID: 00000000
T1: 0
T2: 0
Status code
Option: Status code (13)
Length: 56
Value: 00064e6f2070726566697820617661696c61626c65206f6e...
Status Code: NoPrefixAvail (6)
Status Message: No prefix available on Link
'CMTS89.WLFDLE-BNDL1-GRP3'
DNS recursive name server
Option: DNS recursive name server (23)
Length: 32
Value: 2607f7980018001000000640712552042607f79800180010...
1 DNS server address: 2607:f798:18:10:0:640:7125:5204
2 DNS server address: 2607:f798:18:10:0:640:7125:5198You might want to do a packet capture of the full DHCPv6 sequence, to see if any clues turn up.
-
@drideout
I have Spectrum cable (in SoCal) and am using it with a basic crappy HITRON modem (not router). I too get a 56 from Spectrum, and assigned a prefix to each vlan. For me, I saw no reason to enable DHCP6, I set the computer vlans to SLAAC and the iot to unmanaged. Of course, I also made sure that there are allow outgoing ICMPV6 rules on the LAN and all the VLANS as it's important for IPV6. Made sure the proper overall outgoing rules were in place as there is no default allow all rule on the additional LAN networks you create. Knock on wood, it works fine in my case.If you go back to the initial settings again, with just the lan set with IPV6, does it again work???
-
I appreciate your knowledge and input. Getting that deep with the ISP customer support is my fear. I don't know if its worth the effort. It would probably be easier changing ISPs :).
Luckily, the problem fixed itself after several days! I didn't change my PfSense configuration but I did bring the WAN interface down and back up again today. I guess whatever was hanging up the CMTS is fixed as it decided to honor the prefix delegation it supplied me. IPv6 traffic within that prefix range is finally routing back.
Thank you again.
