Thanks for the info
Yeah everything is working as normal so no complaints I’m just excited to see IPV6 running and being put on the new ranges.
Thanks for the info
Yeah everything is working as normal so no complaints I’m just excited to see IPV6 running and being put on the new ranges.
Same here I was super excited to try it out but I guess we have to wait a little bit longer. Others have managed to get IPV6 as they are using their own routers.
Any news on when the firmware update will be pushed for the Yayzi routers to enable IPv6?
We’re just testing the firmware, we don’t want to rush this as we could really cause issues for everyone, I want to make sure we nail this!
If you need a test ex820v to push the firmware to outside of your lab let me know. I’ll plug mine in and you can do your worst to it.
My EERO 6 network already has IPV6 enabled, so i assume it’ll just work once it’s pushed out to everybody?
It should work
Check IPv6 settings DHCPv6 and /60 for Prefix Delegation Size.
Any updates? Is not rushing this, days, weeks, or months away?
Thanks
I’ll try again, any updates?
I still can’t get a IPv6 Prefix Delegation via DHCP on a Linux router.
As far as I understand it IPv6 should be available to all Yayzi accounts now, if you’re using your own router?
I’ve setup the DHCPv6 client to request a PD with a hint request for a /60, but absolutely no response from Yayzi’s DHCP server.
I’ve sniffed the WAN side, and can see the DHCP requests going out successfully, but there is zero reply from Yayzi.
Can anyone who’s got a working DHCPv6 PD allocation now please grab a packet trace - so that I can compare the DHCP request I’m sending, with a known good one?
These are examples of the RS and DHCPv6 Solicit messages my client is sending which Yayzi’s DHCP is not responding to for some reason - can anyone see anything obviously wrong with them?
Thanks!
DHCPv6 Solicit (The expected 1st message in DHCPv6 flow):
17:14:26.046691 00:e0:4c:03:78:28 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 244: (flowlabel 0x18215, hlim 1, next-header UDP (17) payload length: 190) fe80::6993:1a5e:d26:d8b1.546 > ff02::1:2.547: dhcp6 solicit (xid=ee7340 (client-ID type 4) (elapsed-time 0) (vendor-class) (rapid-commit) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/60 pltime:0 vltime:0)) (Client-FQDN) (reconfigure-accept) (option-request DNS-server DNS-search-list Client-FQDN opt_82 opt_83))
ICMPv6 Router Solicit:
17:14:26.046047 00:e0:4c:03:78:28 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: (flowlabel 0xeed28, hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::6993:1a5e:d26:d8b1 > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16
source link-address option (1), length 8 (1): 00:e0:4c:03:78:28
0x0000: 00e0 4c03 7828
Are you sure about that? From my understanding, the router solicitation/advertisement messages are Link Local, so they’re not broadcast through routers.
It’s the router that sends a router solicitation/DHCPv6 request to Yayzi for a prefix delegation, and the next hop router via ICMPv6 Router Solicitation(ie Yayzi’s first hop router) from its WAN interface.
Your router then subnets the prefix delegation down to a /64, and applies that to your LAN interface, assigning one of the /64 subnet as the routers LAN address.
Then you can either run a DHCPv6 server on the LAN interface for clients to be assigned addresses, or instead run a Router Advertisement daemon (RADVD for eg) and have the clients self address themselves via SLAAC.
But in none of those cases do your IPv6 clients send a DHCPv6 or router solicitation to Yayzi’s first hop router, those requests are answered by your router.
Spot on.
Yes please, if anyone can post a trace of a successful Prefix Delegation from their WAN interface, showing the router requests, and Yayzi’s responses that would be very helpful to debug what’s different about the requests my router is sending.
Thank you.
I’ve got the full sequence here
Request.
• Length: 193 bytes on wire (1544 bits), 193 bytes captured (1544 bits)
• Arrival Time: Sep 20, 2024 00:02:07.561542000 BST (Sep 19, 2024 23:02:07.561542000 UTC)
• Time since reference: 71.060581 seconds
• Interface: sshdump
• Encapsulation Type: Ethernet (1)
• Protocols: Ethernet II, IPv6, UDP, DHCPv6
Ethernet II:
• Source MAC: Ubiquiti_2e:c1:5d (28:70:4e:2e:c1:5d)
• Destination MAC: IPv6mcast_01:00:02 (33:33:00:01:00:02)
• Type: IPv6 (0x86dd)
IPv6:
• Source Address: fe80::2a70:4eff:fe2e:c15d
• Destination Address: ff02::1:2 (Link-Local Multicast)
• Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
• Flow Label: 0xe5c79
• Payload Length: 139 bytes
• Next Header: UDP (17)
• Hop Limit: 1
UDP:
• Source Port: 546
• Destination Port: 547
DHCPv6:
• Message Type: Request (3)
• Transaction ID: 0xe5a2a3
• Elapsed Time:
• Option: Elapsed Time (8)
• Length: 2
• Elapsed Time: 0 ms
• Option Request:
• Option: Option Request (6)
• Length: 22
• Requested Options:
• SIP Server Domain Name List (21)
• SIP Servers IPv6 Address List (22)
• DNS Recursive Name Server (23)
• Domain Search List (24)
• Simple Network Time Protocol Server (31)
• NTP Server (56)
• Dual-Stack Lite AFTR Name (64)
• Prefix Exclude (67)
• S46 MAP-E Container (94)
• S46 MAP-T Container (95)
• S46 Lightweight 4over6 Container (96)
• Client Identifier:
• Option: Client Identifier (1)
• DUID: 00030xxxxxxxxxxx
• Type: Link-layer address (3)
• Hardware Type: Ethernet (1)
• Address: 28:70:4e:2e:c1:5d
• Server Identifier:
• Option: Server Identifier (2)
• DUID: 00030001d46d502dbeb7
• Type: Link-layer address (3)
• Hardware Type: Ethernet (1)
• Address: d4:6d:50:2d:be:b7
• Reconfigure Accept:
• Option: Reconfigure Accept (20)
• Length: 0
• Client Fully Qualified Domain Name:
• Option: Client Fully Qualified Domain Name (39)
• Length: 14
• Flags: 0x00 (Client wants to update its AAAA RRs and Server to update its PTR RRs)
• Top Level Domain (TLD): UDM-Pro-Max
• Warning: TLDs are rarely resolvable
• Identity Association for Prefix Delegation:
• Option: Identity Association for Prefix Delegation (25)
• Length: 41
• IAID: 00000001
• T1: 0
• T2: 0
• IA Prefix:
• Prefix Address: 2a11:2:x:x:XX;Xx
• Preferred Lifetime: 1800 seconds
• Valid Lifetime: 1800 seconds
• Prefix Length: 60
Advertise.
DHCPv6 - Advertise (Message Type: 2):
- Transaction ID: 0xc018a7
Server Identifier:
- Option: Server Identifier (2)
- DUID Type: Link-layer address (3)
- Server DUID: Cisco_2d:be(d4:6d:50:2d:be)
Client Identifier:
- Option: Client Identifier (1)
- DUID Type: Link-layer address (3)
- Client DUID: Ubiquiti_2e:c1:5d (28:70:4e:2e:c1:5d)
Reply.
• Length: 197 bytes on wire (1576 bits), 197 bytes captured (1576 bits)
• Arrival Time: Sep 20, 2024 00:02:07.568379000 BST (Sep 19, 2024 23:02:07.568379000 UTC)
• Time since reference: 71.067418 seconds
• Interface: sshdump
• Encapsulation Type: Ethernet (1)
• Protocols: Ethernet II, IPv6, UDP, DHCPv6
Ethernet II:
• Source MAC: Cisco_2d:b9:b4 (d4:6d:50:2d:b9:b4)
• Destination MAC: Ubiquiti_2e:c1:5d (28:70:4e:2e:c1:5d)
• Type: IPv6 (0x86dd)
IPv6:
• Source Address: fe80::d66d:50ff:fe2d:b9b4
• Destination Address: fe80::2a70:4eff:fe2e:c15d
• Traffic Class: 0xe0 (DSCP: CS7, ECN: Not-ECT)
• Flow Label: 0x00000
• Payload Length: 143 bytes
• Next Header: UDP (17)
• Hop Limit: 30
• Hop Limit: 30
UDP:
• Source Port: 547
• Destination Port: 546
DHCPv6:
• Message Type: Reply (7)
• Transaction ID: 0xe5a2a3
• Server Identifier:
• DUID: 00030001d46d502dbeb7
• Type: Link-layer address (3)
• Hardware Type: Ethernet (1)
• Address: d4:6d:50:2d:be:b7
• Client Identifier:
• DUID: 0003000128704e2ec15d
• Type: Link-layer address (3)
• Hardware Type: Ethernet (1)
• Address: 28:70:4e:2e:c1:5d
• Reconfigure Accept:
• Option: Reconfigure Accept (20)
• Length: 0
• Client Fully Qualified Domain Name:
• Option: Client Fully Qualified Domain Name (39)
• Length: 14
• Flags: 0x00 (Client updates AAAA RRs; Server updates PTR RRs)
• Top Level Domain (TLD): UDM-Pro-Max
• Warning: TLDs are rarely resolvable
• Identity Association for Prefix Delegation:
• Option: Identity Association for Prefix Delegation (25)
• Length: 41
• IAID: 00000001
• T1: 900
• T2: 1440
• IA Prefix:
• Prefix Address: 2a11:xxcx:xxxx:xxxx/60
• Preferred Lifetime: 1800 seconds
• Valid Lifetime: 1800 seconds
• Prefix Length: 60
• DNS Recursive Name Server:
• Option: DNS Recursive Name Server (23)
• Length: 32
• DNS Servers:
• 1: 2001:4860:4860::8888
• 2: 2001:4860:4860::8844
Theres far more info than is needed there but I cannot be bothered to go through every frame and pull out the relevant data and format.
If you message me on the yayzi discord i’ll send you the full cap.
@Lee Thank you very much for capturing that, I’ll msg you on Discord for the pcap, and then compare it to mine.
Not sure if it helps at all, but Yayzi changed my IP range (for geolocation issues) from 154.56.x.x to 217.180.x.x and in doing so, my IPv6 has sprung to life - could it be related that some routes dont have IPv6 activated?
(BTW only been with Yayzi a few days and already fantastic customer service - never known such quick responses and none of this “have you tried factory resetting”)
@Yayzi_Staff @Yayzi_Team Please can we get a straight answer to this question, as it is clearly causing confusion:
Is IPv6 definitely enabled on all accounts/IPv4 ranges now?
Some of your messaging says that IPv6 is enabled to all, other messages say that it’s rolling out gradually - which is it?
If the answer is it’s not enabled for all, is it enabled on my account:
YAYZI02832 ?
Thanks!
What IP range are you on?
I’m on 141.11.200.xxx but another user with working IPv6 is also on this subnet.
How it feels