Yes, it seems to work fine with a prefix with a lifetime longer than a minute. No idea if Android is “fussy” about the lifetime, but I would question the ISP about the short lifetime.
So, should I ask the ISP about why their ULA lifetimes are so short? Is there anything else I can do on my end?
The ULA is fine and generated/managed by OpenWrt. The ISP’s GUA prefix lifetime seems unusually low. If you put the ISP router back, and click that Release and Renew section in the GUI, does it refresh your Prefix and or lifetime?
I’d try power cycling everything (leave it down longer than a minute) and see if it refreshes after it powers on. Not a great plan, but worth a try.
Semi-interesting discussion of the frequency of router advertisement intervals related to lifetime for battery-powered devices. The gist I got was Google recommends the lifetime be 15x as long as the interval. odhcpd seems to use 3x in your case.
Nothing really actionable here, but seems like it has been problematic for a while for some.
Edit: already mentioned before:
1 Like
Thanks, these are actually really interesting to read.
I tried releasing and renewing the prefix on the ISP router, and even powered it down for a while to see if I can get a new prefix or address, but both the prefix and address stayed the same.
Does this mean that I’m SOL on getting IPv6 working on Android devices?
EDIT: I noticed that my ISP hasn’t rotated my IPv4 address for maybe a month now. Previously, I would get a rotated IPv4 address every time I restarted my router. Not sure if this has anything with my inability to request a larger prefix, but still wanted to throw this out there.
I believe Android devices will ignore RA lifetimes shorter than 180 seconds. As mentioned above, having super short lifetimes not only causes increased battery drain but also potentially intermittently broken IPv6 on battery powered devices as multicast packet loss on WiFi can be very high depending on AP settings and device implementation. Battery powered devices missing RAs due to multicast packet loss is relatively common when the device is sleeping.
This. But I'm to lazy to find the source right now.
@OpnEnt Afaik this is not a real world issue at all because in a network which needs short fail over you would have multiple routers each doing RA.
And for servers (just as a side note), you would use dynamic routing anyway if you need HA and not RA.
1 Like
Thank you both, I never thought about the impact short RA lifetimes might have on battery life. Is there any way that I can increase the RA lifetime, or request it to be increased?
You can see it in the AOSP source code, but I don’t remember exactly where. 
@OpnEnt If those were RAs from your ISP, you will probably have to ask your ISP to fix their IPv6 network configuration. Try what @dave14305 said first though, just in case.
I’ve looked back at this issue a couple over the last couple of months, and I haven’t been able to find the solution. With my current config, my Linux, iOS/macOS and Windows devices all have IPv6 connectivity, but my Android phone still doesn’t. If anyone would like to pick up from my work, and the advice of others in this thread, here are my current configs:
I've increased the DTIM Interval from 2 to 5 on all wireless networks.
root@router:~# ubus call system board
{
"kernel": "6.12.66",
"hostname": "router",
"system": "ARMv8 Processor rev 4",
"model": "ASUS TUF-AX6000",
"board_name": "asus,tuf-ax6000",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "25.12.0-rc3",
"firmware_url": "https://downloads.openwrt.org/",
"revision": "r32486-30527a4c34",
"target": "mediatek/filogic",
"description": "OpenWrt 25.12.0-rc3 r32486-30527a4c34",
"builddate": "1768954854"
}
}
/etc/config/network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fdbf:9907:7140::/48'
option packet_steering '1'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
list ports 'lan5'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '64'
option ip6hint '0'
config interface 'wan'
option device 'eth1'
option proto 'dhcp'
option peerdns '0'
option type 'bridge'
config interface 'wan6'
option device 'eth1'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix 'auto'
option peerdns '0'
option extendprefix '1'
option type 'bridge'
option ra_management '1'
option ra_interval '600'
option max_ra_interval '10800'
option min_ra_interval '10800'
option prefered_lifetime '10800'
option valid_lifetime '10800'
config interface 'HomeVPN'
option proto 'wireguard'
option private_key '=='
option listen_port '54280'
list addresses '10.10.10.1/24'
config wireguard_HomeVPN
option description 'Phone'
option public_key '=='
option private_key '=='
option preshared_key '=='
list allowed_ips '10.10.10.2/32'
option route_allowed_ips '1'
config wireguard_HomeVPN
option public_key '=='
option private_key '=='
option preshared_key '=='
option description 'MacBook'
list allowed_ips '10.10.10.3/32'
option route_allowed_ips '1'
option persistent_keepalive '5'
config wireguard_HomeVPN
option description 'Archbox'
option public_key '=='
option private_key '=='
option preshared_key '=='
list allowed_ips '10.10.10.4/32'
option route_allowed_ips '1'
config device 'guest_dev'
option type 'bridge'
option name 'br-guest'
config interface 'guest'
option proto 'static'
option device 'br-guest'
option ipaddr '192.168.3.1/24'
/etc/config/firewall
config defaults
option syn_flood '1'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
list network 'HomeVPN'
config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
list network 'wan'
list network 'wan6'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
config redirect
option dest 'lan'
option target 'DNAT'
option name 'Divert-DNS'
option src 'wan'
option src_dport '53'
option dest_port '53'
config redirect
option dest 'lan'
option target 'DNAT'
option name 'HomeVPN'
list proto 'udp'
option src 'wan'
option src_dport '54280'
option dest_ip '192.168.1.1'
option dest_port '54280'
config zone 'guest'
option name 'guest'
option network 'guest'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
config forwarding 'guest_wan'
option src 'guest'
option dest 'wan'
config rule 'guest_dns'
option name 'Allow-DNS-Guest'
option src 'guest'
option dest_port '53'
option proto 'tcp udp'
option target 'ACCEPT'
config rule 'guest_dhcp'
option name 'Allow-DHCP-Guest'
option src 'guest'
option dest_port '67'
option proto 'udp'
option family 'ipv4'
option target 'ACCEPT'
config redirect
option dest 'guest'
option target 'DNAT'
option name 'Divert-DNS for ISO Network'
option src 'wan'
option src_dport '53'
option dest_port '53'
config rule
option src 'lan'
option dest 'guest'
option name 'Allow access to guest from main'
option target 'ACCEPT'
/etc/config/dhcp
config dnsmasq
option domainneeded '1'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/local/'
option domain 'local'
option expandhosts '1'
option cachesize '0'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option localservice '1'
option ednspacket_max '1232'
option noresolv '1'
option localuse '1'
list server '127.0.0.53'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv4 'server'
option ra 'relay'
option ndp 'relay'
option dhcpv6 'relay'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
config dhcp 'wan6'
option interface 'wan6'
option ignore '1'
option master '1'
option ra 'relay'
option dhcpv6 'relay'
option ndp 'relay'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
option piofolder '/tmp/odhcpd-piofolder'
config host
option name 'RaspberryPi'
option dns '1'
list mac ''
option ip '192.168.1.3'
option leasetime 'infinite'
config host
option name 'Arch'
option dns '1'
list mac ''
option ip '192.168.1.30'
option leasetime 'infinite'
config host
option name 'Box'
option dns '1'
list mac ''
option ip '192.168.1.10'
option leasetime 'infinite'
config host
option name 'Pixel'
option dns '1'
list mac ''
option ip '192.168.1.40'
option leasetime 'infinite'
config host
option name 'iPad'
option dns '1'
list mac ''
option ip '192.168.1.50'
option leasetime 'infinite'
config host
option name 'MacBook'
option dns '1'
list mac ''
option ip '192.168.1.20'
option leasetime 'infinite'
config host
option name 'CoreOne'
list mac ''
option ip '192.168.1.100'
option leasetime 'infinite'
config dhcp 'guest'
option interface 'guest'
option start '100'
option limit '150'
option leasetime '1h'
config host
option name 'CoreOneCamera'
list mac ''
Interfaces
Interfaces > lan > General Settings:
Interfaces > lan > Advanced Settings:
Interfaces > lan > Firewall Settings:
Interfaces > lan > DHCP Server:
Interfaces > wan6 > General Settings:
Interfaces > wan6 > Advanced Settings:
Interfaces > wan6 > Firewall Settings:
Interfaces > wan6 > DHCP Server:
Thanks to everyone who tried to help in this thread. Any further help is appreciated. I'm considering contacting Verizon to see what they tell me about IPv6 connectivity with their 5G Home internet service, because I haven't found a way to make IPv6 works on their stock router on any of my devices.
This is your problem. Android steadfastly refuses to accept an ipv6 address from relay for any more than a few seconds.
The official google response is that it is not proper ipv6 so is rejected.
You have to either use prefix delegation or nat66.
Delegation works for everything as does nat66.
If your isp does not support prefix delegation, perhaps you should consider changing.
The only downside for nat66 (other than getting flamed by ipv6 purists) is that I would not be able access your Android device from here... /s 
2 Likes
extendprefix and relay mode are two different approaches to the same problem so you should only use one. I have never used extendprefix.
Relay mode works with my cheap Samsung Android. I don't run DHCPv6 at all on the home relay-mode network, only RA.
Properly configured in relay mode, the you may notice the lan interface itself does not have a GUA IP (this means it does not need ip6assign or ip6hint, which are only relevant if you are delegating an ISP prefix). That is OK it still works. odchpd advertises the wan /64 on the LAN, and when a client chooses an IP with SLAAC, it snoops the NDP exchange to install a /128 route to each client. The phone uses the router's link-local IP as the v6 gateway.
(post deleted by author)
I contacted Verizon about getting a larger IPv6 prefix assigned, this is how the chat went.
TL;DR: DHCPv6 is currently my only option. Verizon's 5G Home Internet is currently shipped with broken IPv6 connectivity that cannot support SLAAC, they are aware of the issue, but have no short-term solution. Verizon's Fiber service now delegates /56 prefixes, but their 5G Home internet service always assigns /64 prefixes, and nothing can be done on their end. Verizon's Tier 2 customer support also sounds suspiciously like ChatGPT.
You •
2:00 AM
Customer Escalation from Bot
You •
2:00 AM
Any feature or service is not working
You •
2:01 AM
Hello, I'm having issues getting IPv6 working on my home network. The issue is that my devices can't use SLAAC to get an IPv6 address because my IPv6 prefix is too small. I would like to request a larger IPv6 prefix.
Support team •
2:01 AM
Thanks for contacting Verizon, My name is REP #1 your Tech Support buddy for today!
I got you!
Thanks so much waiting here in queue.
Kindly refrain from swiping off or closing the chat to avoid disconnection and having to start a new contact with our chats. This will help us in completing and resolving your concern efficiently.
Can you please share to me more on how can I help you with your phone service is not working?
You •
2:02 AM
Hello, I'm having issues getting IPv6 working on my home network. The issue is that my devices can't use SLAAC to get an IPv6 address because my IPv6 prefix is too small. I would like to request a larger IPv6 prefix. My home internet is through the 5 Home Internet.
Support team •
2:02 AM
I want to make sure that we get to the bottom of this right away. May you share with me more if this is for your home wifi concern?
Support team •
2:02 AM
OH I got you, thanks so much for bring this up with our attention, Rest assure to work on this one step at a time.
You •
2:04 AM
Ok, thank you.
Support team •
2:06 AM
I got you!
If you don't mind me asking, could you please share with me if you are able to use that IPv6 on your home network?
Support team •
2:07 AM
I am still here, are we still connected?
You •
2:11 AM
We are still connected.
Support team •
2:11 AM
Apprecaite you so much! Could you please let me know if you were able to receive my last messages?
You •
2:12 AM
My devices that support DHCPv6 are able to get an IPv6 address, but my devices that only support SLAAC are unable to get an IPv6 address.
Support team •
2:15 AM
I just want to make sure that we can cover everything, that I can be on the right path, and that we can have this resolved. And to confirm you wanted this replacement of a larger IPv6 prefix for your home wifi?
You •
2:17 AM
Yes, I would like a /56, or at the very least /60 IPv6 prefix for my home internet service.
Support team •
2:18 AM
Got it, working on it now. I will make a report for this request, an update you as soon as possible. May you share with me the best time I can email and call you?
Support team •
2:18 AM
The reason I ask this is that I need to wait for approval from our Dedicated Team for this request. Once it is approved, I will let you know.
You •
2:19 AM
I'm in the US Eastern Time zone. You can email me anytime, and I will get back to you.
Support team •
2:20 AM
That is noted. Also, please provide me with your best contact number.
Support team •
2:20 AM
And please allow me to stay on this thread so I can ping you here right away🙏
You •
2:20 AM
+1(111) 111-1111
Support team •
2:21 AM
I truly appreciate your patience with me on this. I got this. Working on the report request now.
You •
2:21 AM
Thank you.
Support team •
2:23 AM
My pleasure!
Support team •
2:23 AM
You may receive the auto generated message here "Just checking in?
This conversation will pause soon. Reply in 30 minutes to continue".
You can ignore this message.
You can continue with your routine and and we are adding notes and will take care of everything, alright?
You •
2:24 AM
Ok, I might go to sleep in about 20 minutes, because it is 2:24 AM where I am.
Support team •
2:24 AM
I will stay connected with you for sure, as I would like to make sure we have got this all covered. I will be just here,
Support team •
2:24 AM
Please take your time and just leave this thread up, 🙌🙏
You •
2:25 AM
Ok, feel free to email or call me if you don't get a response from me, because at that point I have likely fallen asleep.
Support team •
2:26 AM
I got you! As an added help here, I will give you my chat link and sent to your phone number so that once you need further assistance you can use this anytime, to have me the same agent and same chat conversation and no need to repeat yourself to anyone else, sound's like a plan?
You •
2:26 AM
Yes, I saw the text message earlier.
Support team •
2:27 AM
Thanks so much! I will snet it to your line 2580
You •
2:27 AM
Sounds good.
Support team •
2:30 AM
My chat link and the request has been sent,, to your line 2580, do you have it?
You •
2:30 AM
Yes
Support team •
2:31 AM
Appreciate you so much for the confirmation.
Support team •
2:31 AM
Please take your time with your routine, as I am currently waiting for the update.
Support team •
2:32 AM
I can stay here and rest assure to ping you here once all set, alright?
You •
2:32 AM
Ok
Support team •
2:33 AM
Thanks so much!🙌
Support team •
2:40 AM
Just checking in. If your chat has been resolved, you can consider this session closed and no need to reply. If you still need to engage, we’re here for you.
You •
2:40 AM
Ok, I guess I'll get a follow up email about the allocation of a larger prefix?
Support team •
2:41 AM
Yes I am still here.
Support team •
2:41 AM
I apologize for the confusion regarding the AI bot messages. Please feel free to disregard them.
You •
2:42 AM
Oh, ok. All the messages show up as "Verizon Agent".
Support team •
2:42 AM
You may take your time with your errand on your end, and please rest assured that I will update you as soon as possible.🙌
Support team •
2:49 AM
Just checking in. If your chat has been resolved, you can consider this session closed and no need to reply. If you still need to engage, we’re here for you.
Support team •
2:52 AM
Thank you for reaching out to us today. We’ll go ahead and close this session and no need to reply. If you need us, we’re here for you 24x7.
You •
2:52 AM
Do not disconnect
Support team •
2:52 AM
Your conversation has been transferred. You will be assisted by the next available agent. Thank you for your patience.
Support team •
2:53 AM
Resolved
You •
2:54 AM
I'm still waiting for my request to be resolved.
Support team •
2:54 AM
Thank you for contacting Verizon, this is Reign, your tech representative for today. Having a working device is indeed important. No worries! I will make sure that I will help you resolve this concern in no time. Please stay with me and do not close the chat. and I hope you are doing great today! Be assured I got you! How can I help you today?
Support team •
3:01 AM
Just checking in. If your chat has been resolved, you can consider this session closed and no need to reply. If you still need to engage, we’re here for you.
Support team •
3:04 AM
Thank you for reaching out to us today. We’ll go ahead and close this session and no need to reply. If you need us, we’re here for you 24x7.
Support team •
3:40 AM
Need more information
You •
3:41 AM
What information do you need?
Support team •
3:42 AM
We appreciate you for contacting Verizon, My name is REP #2. I do see you have contacted about infromation. I will make sure that I will help you resolve this concern in no time, Please stay with me and do not close the chat, and I hope you are doing great today. Be assured I got you!
Kindly please tell me more about your concern?
You •
3:44 AM
I've already described my issue to someone, they said they will escalate it to their supervisors, and now I got a text that more information is needed from me. What more information do you need from me?
Support team •
3:47 AM
We appreciate you for reaching us about your issue. I will be happy to check all options to help you on this and rest assured that we will resolve your concern within this chat ASAP. Please allow me a moment to pull up your account.
Support team •
3:47 AM
By the way, may I ask whom I have the pleasure speaking with today?
Support team •
3:54 AM
Just checking in. If your chat has been resolved, you can consider this session closed and no need to reply. If you still need to engage, we’re here for you.
Support team •
3:56 AM
Just checking in, how are things going so far now?
Support team •
3:57 AM
Thank you for reaching out to us today. We’ll go ahead and close this session and no need to reply. If you need us, we’re here for you 24x7.
Support team •
4:33 AM
Need more information
You •
11:19 AM
Hello, I would like to check the progress of my request.
Support team •
11:20 AM
We Got You here at Verizon, home of the Best Value Guarantee!!
My name is REP #3. I want to personally thank you for being a Verizon Customer. You've reached the Tier 2 team. Can you please help me with your full name and the line number and can share little bit of your concern so I can work on your request quickly?
You •
11:23 AM
Hello, all the details should be in the chat. My name is MY NAME, and the line number of my 5G Home Internet is 111-111-1111. The previous agent said she escalated the request to her superiors, so I'd like to see if there was any progress
Support team •
11:24 AM
Nice to meet you . Thank you for sharing the details. I hope you are doing well.
Support team •
11:24 AM
I am really sorry but right now I am unable to access the previous notes due to few of the tools issues so can you help me how I can help you with your concern.
You •
11:25 AM
Hello, I'm having issues getting IPv6 working on my home network. The issue is that my devices can't use SLAAC to get an IPv6 address because my IPv6 prefix is too small. I would like to request a larger IPv6 prefix. My home internet is through the 5G Home Internet.
You •
11:25 AM
My devices that support DHCPv6 are able to get an IPv6 address, but my devices that only support SLAAC are unable to get an IPv6 address.
You •
11:26 AM
I would like a /56, or at the very least /60 IPv6 prefix for my home internet service.
Support team •
11:27 AM
I understand how frustrating that can be, especially when you have a mix of devices like Android phones or IoT hardware that rely specifically on SLAAC (Stateless Address Autoconfiguration) rather than DHCPv6.
Support team •
11:27 AM
If your SLAAC-only devices aren't getting an address, it usually means the Router Advertisements (RA) aren't being sent correctly, or the "Managed" bit is set in a way that tells devices to only use DHCPv6.
Support team •
11:28 AM
I will share the troubleshooting steps with you. In the mean time may I know how your day is going so far?
You •
11:29 AM
That's fine. My day is going fine.
Support team •
11:29 AM
Glad to know about this.
Support team •
11:30 AM
Sometimes the Prefix Delegation gets "stuck." Try disabling IPv6 in the router settings, waiting 30 seconds, and re-enabling it. This forces the router to request a new prefix and restart the advertisement daemon.
Support team •
11:31 AM
In some specific regions (particularly with certain ONTs), there is a known compatibility glitch. If your devices get an address but can't actually load pages, try disabling IPv6 Checksum Offloading in your device settings (if it's a PC) or check if your router has a "Legacy" or "Compatibility" mode for IPv6.
You •
11:32 AM
I don't have fiber, I use 5G Home internet.
Support team •
11:32 AM
With the 5G Home Internet gateways (like the ARC-XCI55AX "cube" or the WNC-CR200A), the way IPv6 is handled can be a bit more restrictive. On these mobile-network-based systems, the gateway often receives a single $/64$ prefix from the cell tower.
Support team •
11:32 AM
The issue you're seeing—where DHCPv6 works but SLAAC doesn't—is a known "quirk" specifically impacting devices like Android phones, which strictly require SLAAC and do not support DHCPv6 at all.
You •
11:36 AM
That's the conclusion I've actually made an extensive forum thread trying to troubleshoot the issue: https://forum.openwrt.org/t/android-devices-cannot-get-an-ipv6-address/241413
Support team •
11:37 AM
I see you've already done the heavy lifting on this! It’s clear you’ve pinpointed the exact technical bottleneck: the Gateway is broadcasting the M-bit (Managed Address Configuration) while effectively silencing the A-bit (Autonomous Address Autoconfiguration). For Android users and SLAAC-dependent hardware, that's a total dead end.
Support team •
11:38 AM
I've been checking the latest internal bulletins and user reports regarding our 5G Home Gateways (especially the ARC and WNC models). Here is the "no-fluff" reality of where we stand with this specific IPv6 behavior:
Support team •
11:38 AM
On many of our 5G firmware versions, the gateway is locked into Stateful DHCPv6. This is often because the mobile core assigns a single $/64$ prefix to the gateway. In a standard networking environment, you'd want a $/56$ to sub-delegate, but with a $/64$, the gateway tries to maintain strict control over address assignments to prevent "IP exhaustion" or routing loops within its simplified firmware.
Support team •
11:41 AM
Are you aware of this?
You •
11:42 AM
Can I be assigned a larger prefix? Essentially everyone I've talked to about this issue says that a /60 or /56 is more appropriate for ISPs to give customers.
Support team •
11:42 AM
You’ve hit the nail on the head. In the networking world, the standard recommendation (per RFCs and best practices) is for ISPs to provide a $/56$ or at least a $/60$ to allow for proper subnetting and device management.
Support team •
11:43 AM
While our Fios (Fiber) service has largely moved to delegating $/56$ prefixes (allowing for 256 subnets), our 5G Home Internet runs on our mobile core infrastructure.
Would you like to know about more about this so I can transfer this to our Fios team for you?
You •
11:44 AM
Fios is not available in my area, so transferring me to the FIOS team will do me no help.
Support team •
11:45 AM
Oh, I am sorry to hear about this.
You •
11:45 AM
To get back to my point, can I get some kind of solution to get SLAAC working on my 5G home internet? I can get IPv6 through SLAAC when I'm on mobile data, but not on my home network.
Support team •
11:46 AM
You aren't imagining things: Verizon Mobile Data handles IPv6 differently than Verizon 5G Home Internet. On your phone’s direct 5G connection, the network acts as a peer and allows for SLAAC. However, the 5G Home Gateway acts as a "Router," and our current firmware on those boxes is hard-coded to Stateful DHCPv6 only for its local LAN.
Support team •
11:47 AM
Since the gateway isn't broadcasting the "A-bit" (Autonomous address configuration) in its Router Advertisements, your Android and SLAAC-only devices will simply never get a global IPv6 address from it.
You •
11:49 AM
I'm not using the stock Verizon router, just the receiver plugged into my own router. Is there any way you can allocate a larger prefix for me so that IPv6 isn't broken on my network?
Support team •
11:51 AM
To give you the direct answer as your representative: No, we cannot manually allocate a larger prefix (like a $/56$ or $/60$) for our 5G Home Internet customers. Believe me, I understand why that’s a frustrating answer for a power user. Our 5G network core is architecturally designed to assign a single $/64$ to each residential terminal. Unlike our Fios service, which has the "overhead" to delegate hundreds of subnets, the 5G system treats your gateway as an end-point on the cellular network.
You •
11:53 AM
So, IPv6 is knowingly broken on the 5G Home Internet network, and that's expected behavior?
Support team •
11:54 AM
To be completely candid with you: Yes, the current behavior is "working as designed" from an infrastructure perspective, even though it is technically "broken" for modern networking standards.
From a Verizon engineering standpoint, the 5G Home Internet service is prioritized for a "plug-and-play" experience using our stock equipment. Because the mobile core only hands out a single $/64$ prefix, the system defaults to Stateful DHCPv6 to ensure the Gateway remains the authoritative manager of every IP on that single subnet.
You •
11:55 AM
Ok, is there anything you can do?
Support team •
11:56 AM
I can submit a Technical Feature Gap report on your account. I will specifically note: "Customer requires /56 Prefix Delegation to support SLAAC/Android devices on 3rd-party hardware." Our engineering teams use these specific metrics to decide which features get added to the next "standalone" (SA) 5G core updates.
You •
11:57 AM
Ok, thank you. Is the 5G Home Internet network running on 5G SA or NSA?
Support team •
11:58 AM
In 2026, Verizon has transitioned its mobile core to 5G Standalone (SA) nationwide. However, for 5G Home Internet users, the news is a bit of a "mixed bag."
While the SA core is live, the SLAAC/Prefix Delegation issue remains because of how the network handles "Fixed Wireless" versus "Mobile" traffic.
You •
11:58 AM
Ok, as you can see from the thread on the OpenWRT forum, my issue has been around since before October 2025.
Support team •
12:00 PM
I appreciate the reminder about the OpenWRT forum thread—and I acknowledge that you’ve been dealing with this technical stalemate for well over a year now. If it’s the thread I’m familiar with, it highlights the exact "catch-22" you're in: OpenWRT is ready to handle IPv6 correctly, but the upstream Verizon receiver is effectively blocking it by refusing to delegate a prefix.
Support team •
12:07 PM
Just checking in. If your chat has been resolved, you can consider this session closed and no need to reply. If you still need to engage, we’re here for you.
Yes it sounds like Verizon is admitting the Home Internet is broken. I use T-Mobile (a "Tablet/Hotspot" plan not Home Internet) with a third party modem and it does work. I'll try to set up a test USB tethering my Verizon phone through an OpenWrt router.
The LTE standards really push for v6, but it is also industry practice to only give each customer line a single /64. I doubt the network is set up for larger prefixes.
They do admit that they do delegate /56 to their fiber customers, but I think that would have to reconfigure their mobile core (their 5G Home Internet uses 5G SA now) to delegate larger prefixes for 5G Home customers, and keep delegating /64 prefixes for cellular customers.
Yes, Samsung seems to be the exception to the Google "rule". Testing with relay, a Samsung phone did indeed work. But a UleFone with Android 10, and another with Android 12 would drop the public ipv6 after ~60 seconds. No amount of tweaking on the router would fix this - I spent a lot of time on it, all the usual tools etc.
Changing to prefix delegation or nat66, problematic Androids worked perfectly.
A quick test that @OpnEnt could do is to enable nat66 and report back......
As Android generally does not like relay, as you have found out, you are left with two choices:
- Enable nat66 until the current isp fixes the problem
- Change your isp
Believe me, you will not even notice you have nat66 enabled, unless you want public inbound access to something on your lan, and most people do not want that.
As I suggested previously, you should at least test nat66 and see if it works for you.
Agreed.
-
I've decided to leave things as they are, and not bother with NAT66. It's Verizon's fault that IPv6 is not deployed correctly on their 5G Home Internet product, and it's their problem to fix. They know it's broken, their fiber offering delegates /56 prefixes. I've set my wan6 interface to try requesting /56 prefixes to hopefully "nudge" them at least a little.
-
I've considered changing my ISP, but the only other 100mbps+ option at my location is Xfinity at triple the price, half the download speed and third my current upload speed.
-
Someone in the GrapheneOS chat also suggested using Hurricane Electric's tunnel broker service. I'm not going to be using that, but thought I should throw the info out here for any future readers with the same issue.
Thanks to everyone who helped me troubleshoot and get down the source of the issue.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.