i really should not have to have the βlook, i am a well-known security engineer, when i say i am not getting ipv6 traffic i mean it and will publish this interaction on my blog if you all donβt fix itβ conversation with my ISP (google fiber)
this is what it looks like when your ISP gaslights you because they canβt be bothered to fix their DHCPv6-PD setup
why fix problems when you can gaslight instead?
i am very close to just deploying a virtualized headend at my colo which is 0.4ms ping from my house. seriously.
@ariadne@social.treehouse.systems hey at least you have IPv6; I have FiOS and I'm stuck on IPv4 only 
why i have not done this already? my IPs are in various GeoIP databases as βcontentβ IPs, so they will be treated as if I were using a VPN company.
holy fuck y'all, i decided to fuck around with things and it's so much worse than i thought initially.
after about an hour of fucking around, i discovered google fiber is handing out duplicate ipv6 prefix delegations... ones which are being actively used by other customers. π±
here's the email i just sent to their tech support, which i am sure won't be read, but whatever.
https://distfiles.ariadne.space/grumpy-google-fiber-email.txt
holy fuck y'all, i decided to fuck around with things and it's so much worse than i thought initially.
after about an hour of fucking around, i discovered google fiber is handing out duplicate ipv6 prefix delegations... ones which are being actively used by other customers. π±
here's the email i just sent to their tech support, which i am sure won't be read, but whatever.
https://distfiles.ariadne.space/grumpy-google-fiber-email.txt
@ariadne@social.treehouse.systems just wanted to add @tschaefer@ipv6.social here π
@ariadne@social.treehouse.systems Wait, do they just have everyone SLAAC off the same /64? That looks horribly wrong... I'd have thought at least each customer gets their own /64 for SLAAC!
@lina@vt.social yes, they have SLAAC enabled on a single /64 for some reason. they use DHCPv6-PD to delegate /56 prefixes to customers.
@ariadne@social.treehouse.systems So you can just like... ping other customer's LAN boxes without going through any hops, if they're just using the /64 in bridge mode instead of PD? Are you getting everyone's ND traffic too? Can you just pretend to be multiple customers behind the same ONU and grab a bunch of prefixes?
@ariadne@social.treehouse.systems So you can just like... ping other customer's LAN boxes without going through any hops, if they're just using the /64 in bridge mode instead of PD? Are you getting everyone's ND traffic too? Can you just pretend to be multiple customers behind the same ONU and grab a bunch of prefixes?
@ariadne@social.treehouse.systems Heck how does your own router even know how to route delegated prefixes to other routers, if it doesn't have a full routing table for them? Just bouncing off their headend every time? If you ping another customer's SLAAC router IP from a PD subnet IP, does the request go directly within the subnet and the reply get bounced through the headend?!?!
@ariadne@social.treehouse.systems Heck how does your own router even know how to route delegated prefixes to other routers, if it doesn't have a full routing table for them? Just bouncing off their headend every time? If you ping another customer's SLAAC router IP from a PD subnet IP, does the request go directly within the subnet and the reply get bounced through the headend?!?!
@lina@vt.social
# ip -6 route show
anycast 2604:5500:706b:: dev eth1 proto kernel metric 0 pref medium
2604:5500:706b::/64 dev eth1 proto ra metric 1005 expires 2591846sec mtu 1500 pref medium
anycast 2604:5500:706b:3e00:: dev eth0 proto kernel metric 0 pref medium
2604:5500:706b:3e00::/64 dev eth0 proto dhcp metric 1003 expires 21474836sec pref medium
unreachable 2604:5500:706b:3e00::/56 dev lo proto dhcp metric 1001 pref medium
@lina@vt.social
# ip -6 route show
anycast 2604:5500:706b:: dev eth1 proto kernel metric 0 pref medium
2604:5500:706b::/64 dev eth1 proto ra metric 1005 expires 2591846sec mtu 1500 pref medium
anycast 2604:5500:706b:3e00:: dev eth0 proto kernel metric 0 pref medium
2604:5500:706b:3e00::/64 dev eth0 proto dhcp metric 1003 expires 21474836sec pref medium
unreachable 2604:5500:706b:3e00::/56 dev lo proto dhcp metric 1001 pref medium
@lina@vt.social
and of course default via the link-local address on the headend:
default via fe80::629c:9fff:feb4:2ca8 dev eth1 proto ra metric 1005 expires 1646sec mtu 1500 pref medium
@lina@vt.social
and of course default via the link-local address on the headend:
default via fe80::629c:9fff:feb4:2ca8 dev eth1 proto ra metric 1005 expires 1646sec mtu 1500 pref medium
@ariadne@social.treehouse.systems This is so cursed...
@ariadne@social.treehouse.systems This is so cursed...
@lina@vt.social @ariadne@social.treehouse.systems incredibly cursed yet sadly not uncommon with busted US ISPs :/
@lina@vt.social @ariadne@social.treehouse.systems incredibly cursed yet sadly not uncommon with busted US ISPs :/
@astraleureka@social.treehouse.systems @lina@vt.social yeah but this DHCPv6-PD issue is just next-level busted
@astraleureka@social.treehouse.systems @lina@vt.social yeah but this DHCPv6-PD issue is just next-level busted
@ariadne@social.treehouse.systems @astraleureka@social.treehouse.systems @lina@vt.social Sadly not rare.
my last dhcpv6-pd issue (comcast business):
1) you must request your static /56 as many separate /59 delegations, it will refuse to delegate anything larger in one go
2) you must enable IPv4 DHCP on the CPE. Doesn't matter that your router is on a static ip, or that you will not actually ever issue a DHCPDISCOVER. If the DHCPv4 service isn't running, it'll send you DHCPv6 messages claiming to have delegated your prefix but not actually update the routing table on the CPE and your prefix won't route anywhere
@ariadne@social.treehouse.systems @astraleureka@social.treehouse.systems @lina@vt.social Sadly not rare.
my last dhcpv6-pd issue (comcast business):
1) you must request your static /56 as many separate /59 delegations, it will refuse to delegate anything larger in one go
2) you must enable IPv4 DHCP on the CPE. Doesn't matter that your router is on a static ip, or that you will not actually ever issue a DHCPDISCOVER. If the DHCPv4 service isn't running, it'll send you DHCPv6 messages claiming to have delegated your prefix but not actually update the routing table on the CPE and your prefix won't route anywhere
@azonenberg@ioc.exchange @ariadne@social.treehouse.systems @astraleureka@social.treehouse.systems @lina@vt.social it could be WAY worse:
when I got my fiber connection, I found for some reason it worked on OpenWRT but not my Debian box. After some digging, it turned out all DHCPv6 packets were 1514 byte Ethernet frames, regardless of IPv6/UDP content len.
Those extra bytes were a bug on the last-hop Cisco switches' DHCPv6 relay/inspection. Random snippets out of the switch's memory.
Including configs.
With other customer's names and line IDs (port descriptions)
@azonenberg@ioc.exchange @ariadne@social.treehouse.systems @astraleureka@social.treehouse.systems @lina@vt.social it could be WAY worse:
when I got my fiber connection, I found for some reason it worked on OpenWRT but not my Debian box. After some digging, it turned out all DHCPv6 packets were 1514 byte Ethernet frames, regardless of IPv6/UDP content len.
Those extra bytes were a bug on the last-hop Cisco switches' DHCPv6 relay/inspection. Random snippets out of the switch's memory.
Including configs.
With other customer's names and line IDs (port descriptions)
Ariadne Conill π°
:therian:
