Didn't find what you were looking for?
We have advanced search options to make it easier to locate posts, questions and answers on this community.
More information can be found at Advanced Search Options
If you are looking for something specific, please check if someone else has already asked or answered the same question.
IPv6 -- no response to dhcp6c solicitation, Maryville/Sevierville TN area
This has been going on for more than a week and contacting support via their chat results in a "its working on our end" response. Well, no it isn't and my attempt to get their chat folks to connect me to someone within the tech group failed — they claim "we're trained on this and its not our end." Well, yes it is — while all may be well in many areas and the routing inside the backbone may be working as well, but without a valid delegation and address that's pointless and from here the solicitation is simply never replied to. I've restarted both my gear (I'm using my own router) and also the modem — nothing has changed here over the last several years in terms of configuration.
This started with fairly long delays connecting to anything that has both a v6 and v4 address (like Garmin's sync function) as it was trying the v6 address first and getting no response, then falling back to v4. Attempting to ping known-working v6 locations failed and thus I started with attempting to renew the address at which point it was obvious that it was a black hole in this area.
IPv4 is working perfectly fine — its only v6, and Spectrum's DHCP server is not responding to solicitations at all:
08:12:40.204281 IP6 (hlim 1, next-header UDP (17) payload length: 101) fe80::20d:b9ff:fe46:7188.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=fe1f4b (client-ID hwaddr/time type 1 time 770213155 000db9467188) (IA_NA IAID:1 T1:0 T2:0) (rapid-commit) (elapsed-time 6350) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/56 pltime:1800 vltime:1800)))
08:13:44.685068 IP6 (hlim 1, next-header UDP (17) payload length: 101) fe80::20d:b9ff:fe46:7188.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=fe1f4b (client-ID hwaddr/time type 1 time 770213155 000db9467188) (IA_NA IAID:1 T1:0 T2:0) (rapid-commit) (elapsed-time 12799) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/56 pltime:1800 vltime:1800)))
Its not unhappy and sending back a "reject" — the request is simply going into a black hole somewhere inside Spectrum and I assume that same thing is why prior to trying to renew (when I had the previous delegation) that was failing as well.
And yes, I can ping the other end where that solicitation is going using Ipv6:
root@IpGw:/usr/local/etc # ping6 ff02::1%igb0
PING6(56=40+8+8 bytes) fe80::20d:b9ff:fe46:7188%igb0 --> ff02::1%igb0
16 bytes from fe80::20d:b9ff:fe46:7188%igb0, icmp_seq=0 hlim=64 time=0.249 ms
16 bytes from fe80::20d:b9ff:fe46:7188%igb0, icmp_seq=1 hlim=64 time=0.186 ms
16 bytes from fe80::20d:b9ff:fe46:7188%igb0, icmp_seq=2 hlim=64 time=0.155 ms
^C
My end is asking for a delegation of a /56 (as it always has), but I never get an allocation back. Again this has been working since 2020 without any changes at all on my end. Its not rejecting the request — it simply doesn't answer, which implies that either the dhcp6c server in this region is down or something is blocking its response within Spectrum's infrastructure.
No IPv6 is not the end of the world but this is supposed to be working and has been for the last several years — and now is not.
Answers
-
Are you running passthrough?
That is how I got it "working" years ago... /56, passthrough.
Winblows, firefox, etc. had their own issues with their recursive DNS and whatnot though (android devices seemed to work fine though).
Since the game's I play don't use v6 and there was no real reason to force v6... I disabled it on the router again.
0 -
New router is a bit funky... the v6 screens are much different now.
Still on an older 3.0 modem... but it is getting an v6 address (IPv6Only mode in fact).
Setting the Asus router to passthrough didn't work at all, though the old Asus did without a hitch several years ago.
6to4 kinda sorta worked... but only for the phone. Windows laptop was still misbehaving. The router was doing all the heavy lifting, so it missed a few points in the tests.
Flipped it to Native and didn't set anything... length came up as 64, all the auto config stuff enabled. Phone showed up in the log with a v6 address, has v6 gateway/DNS addresses, connection type says "Native with DHCP-PD".
After sitting a few minutes, trying to refresh the laptop connection a few times... still not getting a v6 address. But my phone and 2 devices (likely android TV boxes) are showing up in the router's V6 log.
Phone scored 20/20 on first test, 9/10 on another (DNS failed... likely the browser's recursive failed). Google reports I am using v6, as well as myip.ms.
So it does in fact appear to be working on the network side of things... but things are not well at the client.
Which is pretty much where it was LAST time I tinkered with it... and why I basically don't arse with it.
Everything I need to do on the internet still works fine with only IPv4 on my LAN.
¯\_(ツ)_/¯
0 -
Would add that while I could switch to a /56 prefix, could not get stateful to work.
Native, Stateless, DHCP with /64 or /56 prefix, auto connect to DNS and such seemed to work... though WIN10 just didn't want to play nice whether by wire or wifi.
HOWEVER... an old Optiplex 7010 (circa 2011/2012 board/CPU) I have been tinkering with Linux Mint on gets out on IPv6 just fine like my phone... 20/20, 10/10 on the tests.
0 -
As you can see I'm not getting any response at all to the DHCP6 solicitation at present.
As I said this has been working since I moved here in 2020 — and then suddenly stopped. Its the same configuration that I used at my old home (which was on Cox rather than Spectrum); there I could ask for a /60 or a /56.
Stateless info request ("tell me what you can do") gets me nothing:
root@IpGw:/usr/local/etc/rc.d # /usr/local/sbin/dhcp6c -D -f -i igb0
Jun/02/2024 08:03:17: extracted an existing DUID from /var/db/dhcp6c_duid: 00:01:00:01:2d:e8:85:23:00:0d:b9:46:71:88
Jun/02/2024 08:03:17: reset a timer on igb0, state=INIT, timeo=0, retrans=891
Jun/02/2024 08:03:18: Sending Information Request
Jun/02/2024 08:03:18: a new XID (b8ac49) is generated
Jun/02/2024 08:03:18: set client ID (len 14)
Jun/02/2024 08:03:18: set elapsed time (len 2)
Jun/02/2024 08:03:18: send information request to ff02::1:2%igb0
Jun/02/2024 08:03:18: reset a timer on igb0, state=INFOREQ, timeo=0, retrans=991
Jun/02/2024 08:03:19: Sending Information Request
Jun/02/2024 08:03:19: set client ID (len 14)
Jun/02/2024 08:03:19: set elapsed time (len 2)
Jun/02/2024 08:03:19: send information request to ff02::1:2%igb0
Jun/02/2024 08:03:19: reset a timer on igb0, state=INFOREQ, timeo=1, retrans=1892
Jun/02/2024 08:03:21: Sending Information Request
Jun/02/2024 08:03:21: set client ID (len 14)
Jun/02/2024 08:03:21: set elapsed time (len 2)
Jun/02/2024 08:03:21: send information request to ff02::1:2%igb0
Jun/02/2024 08:03:21: reset a timer on igb0, state=INFOREQ, timeo=2, retrans=3617
Jun/02/2024 08:03:24: Sending Information Request
Jun/02/2024 08:03:24: set client ID (len 14)
Jun/02/2024 08:03:24: set elapsed time (len 2)
Jun/02/2024 08:03:24: send information request to ff02::1:2%igb0
Jun/02/2024 08:03:24: reset a timer on igb0, state=INFOREQ, timeo=3, retrans=7326
^CThe dhcp6c server on Spectrum's end is not answering AT ALL.
0 -
Are you pulling the DNS address and such automatically? (Just curious if it is hitting a bad address)
Just turned it back on and it automatically set this for DNS:
2001:1998:f00:1::1 2001:1998:f00:2::1
I literally did noting in the Asus GUI but toggle IPV6 from disabled to Native and hit the Apply button. All the default settings to enable auto config, with prefix set to 64.
0 -
That may be the issue; they may have gotten rid of dhcp6 and gone to "native" which gives out a /64. Which is worthless for me because I have subnets, and have to have a /56 because I need to segregate and only allow things that "can" have direct access outbound to in fact be able to do so (a /60 is also ok; Cox would let me have either.)
If they've shut that off and gone to SLACC-only then, well, I live without until Kub gets their fiber here and then Spectrum loses me because that I cannot live with.
Except… ACCEPT_RTADV is set and that should, if Spectrum attempts to hand me an SLACC address, I should get it. I'll do more digging.
0 -
When I was tinkering the other night it granted a /56 request but I couldn't request anything larger.
That is a lot of addresses though.
0 -
A /56 is the standard for most ISPs; frankly a /60 is enough for nearly any residential use (since it allows two subnets, a "clean" and a "dirty") but that give out a /56 is even more-so, and as I noted most ISPs do. Spectrum has never honored a /60 request in my experience (they reject it, but has always handed out a /56 without a problem) although Cox would when I lived in their service area.
But now I'm not getting anything back from their DHCP6 server — not a reject, allocation, nothing at all which implies that their head end for this area either has no IPv6 connectivity at all or they screwed something up internally.
0
