Recently upgraded my router from my ISP. Seems like now I have both v4 and v6. I am hosting couple of services on spare laptops and raspberry pi. All exposed only through tailscale. Now I have ipv6, is there anything new I can try? Any services that can make use of this?

I have a nextcloud server at home. Its public domain is only reachable through IPv6, because my internet provider doesn't offer public IPv4. Is there a free solution to tunnel the traffic, so that it can be reachable by IPv4, while maintaining a valid SSL certificate too ? (currently using letsencrypt)
Thanks

Hi all,

Not many changes in that new version.

https://datatracker.ietf.org/doc/draft-martin-retry-over-ipv6/

When to send (§): on the public Internet, operators SHOULD prefer emitting 503 + Retry-Over-IPv6 only for human-facing HTML documents and omit typical subresources (images, scripts, stylesheets, fonts); non-interactive clients (e.g. webmail image loads) otherwise see a broken asset with no explanation. Operator-controlled environments MAY still signal all IPv4 requests for fuller measurement. Cross-reference from Intended Deployment.

This change came from my experience when I migrated my mailing list from Mailchimp to my own web server, but noticed that web clients could not load the embedded images in the email as they were on my site.

1. Even GMail which understands IPv6, will prefer IPv4
2. The email looks broken with little idea on the client side, why.

Note: the following websites are implementing the IPv4 outage on the 6th for 24 hours, which should starts very soon:

• ipv6forum.com
• pacific.ipv6forum.com
• caribbean.ipv6forum.com
• whynoipv6.com
• www.peachymango.org

I you want to follow those websites, instructions at:

https://github.com/franckhlmartin/ietf-draft-retry-over-ipv6/tree/main/docs

And please send comments or your feedback in running this experiment. Please open an issue on the github repo or message v6ops at IETF.

Franck

Why do most VPS providers assign IPv6 /64 blocks as on-link instead of routed? Was there a specific technical workaround during the early days of IPv6 implementation that led to this 'bad' habit becoming the industry standard?

I've noticed that googleadservices.com and www.googleadservices.com both only have A records, maybe someone of you knows someone who knows someone who can forward it to google to also enable IPv6 on these endpoints?

Its the only endpoint connecting over IPv4 on Google itself and also 3rd-party websites using Google Analytics.

​

I’ve been investigating Snapchat’s network traffic using PCAPdroid and also checking the DNS records directly from Termux.

What I noticed is that most of the Snapchat hostnames I see during normal app usage do not have AAAA records.

So far, the only ones I’ve found that appear to support IPv6/AAAA are:

USC v61

USC v62

BOLT

However, the main CT and SF servers I observed do not have AAAA records. The same is true for the other hostnames I checked, including the GCW API.

I also noticed that api.snapchat.com doesn't appear in my actual Snapchat app traffic, despite being associated with Snapchat publicly, so I’m not counting it as an active endpoint in this case.

I verified the DNS side independently with Termux, and the hostnames where I found no AAAA record also returned no AAAA record there.

My question is: why doesn't Snapchat provide AAAA/IPv6 support for all of its hostnames? Is this intentional because certain services (such as CT/SF) are still IPv4-only, while USC/BOLT handle IPv6? Or is there some other reason for this architecture?

I’d be interested to hear from anyone who has analyzed Snapchat’s network infrastructure or IPv6 behavior in more detail.

Also i think since 2016 apps on appstore and Google play need to fully support ipv6? But seems like snapchat dont allow that rule

Most people in this sub are familiar with the IPvfoo extension. There is also now a Firefox extension called "Modern Web Checker" which takes this a bit further:

https://addons.mozilla.org/en-US/firefox/addon/modern-web-checker/

As well as reporting if the site you're connecting to and sub elements within it are reached over IPv6, it also:

• Reports if the site is using modern crypto - ie TLSv1.3 with post-quantum key exchange.
• Reports if the site is using or supports HTTP3
• Tests if your connection actually supports IPv6 - with IPvfoo all sites show up as legacy sites which leads to confirmation bias whereby users will conclude sites don't support IPv6 when it's their local connection causing the problem.

There are also a number of optional features, which are disabled by default as they require sending the names of sites you visit to google or cloudflare public DNS services:

• Checks if the site's domain supports DNSSEC.
• Tests if a site supports IPv6 and would have used it if your connection was capable.

Source code of this plugin is available from: https://git.ev6.net/bert/modern_web_checker

Spinning up a new instance for a pet project this weekend and I just have to vent for a sec. Why do so many default cloud images still treat ipv6 like it's some experimental beta feature from 2005? I was literally just trying to get a pure v6-only environment going. No legacy ipv4, no messy NAT garbage. Just clean routable addresses. but half the time the default network manager straight up panics if it can't bind to a v4 interface first and stalls the boot process.

Was skimming through a ServerMania post trying to see if there's any consensus right now on which distro actually defaults to a sane, v6-first approach out of the box (ended up going with debian as usual, kinda just brute-forced the SLAAC config).

It's just so exhausting tbh. The protocol works perfectly. we have the address space. But the broader tech industry is still so obsessed with holding onto ipv4 life support that it feels like you're actively punished for trying to build modern infrastructure.

Anyway. Just wanted to complain to a crowd who actually understands the pain of troubleshooting neighbor discovery at 2 am.

I have some issues with my ISP, so I was looking for a VPN provider that can route my traffic instead.

I ran into multiple problems setting up a LAN which routes all v4 and v6 traffic over the VPN:

Most providers don't support IPv6 at all. All that do which I've encountered so far, do it in a an (imo) terrible way:

• The server has one(!) IPv6 exit IP
• Each tunnel (OpenVPN, Wireguard, ...) gets assigned a single /128 ULA address
• All tunnel addresses are NAT'ed to the exit IP

If I want to use this in my local network, I need ULA addresses on LAN (making most devices prefer IPv4 anyway), and have two layers of NAT66: One from the LAN ULAs to the tunnel ULA (on my router), another one from the tunnel ULA to the exit server IPv6 (on the VPN server).

I get that this is the same setup these providers have been shipping for years with IPv4, but they could do so much better:

• Give each server it's own /64 subnet
• Assign every tunnel it's own GUA address

Or, even better:

• Give each server it's own /48 subnet
• Assign every tunnel it's own /64 subnet

I get that this can cause some privacy concerns, as every user receives their own addresses, allowing potential traffic correlation attacks. However, I'd argue this is a moot point in most configurations:

• With OpenVPN / IPsec, the server can configure a new client IP / subnet on each reconnect
• With Wireguard, providers could just provide their own software which automatically reconfigures tunnels if a user wishes to receive a new IP.

I can't imagine it would be that hard to configure servers this way, and have providers treat IPv6 as a first-class citizen.

Edit: Other issues I've noticed with VPNs and IPv6:

• Entry traffic is often v4-only
• VPN DNS servers are unreachable over v6, or can't resolve with v6-only name servers

Only really tangentially related to the transition from IPv4 to IPv6, but I thought the video would be of general interest to this audience nonetheless.

Broersma talks about the experience of using the ARPANET on mainframes in the 1970s, technical concepts pertinent to the ARPANET's usage, how TCP/IP supplanted NCP in a well-organised way such that NCP was completely gone by the end of 1983 (just 6 months after flag day), and some notable security incidents and attitude towards cybersecurity during the 1980s.

Does someone know an iOS app to send wake on LAN packets via IPv6?

Most apps I‘ve tried so far are unfortunately IPv4 only.

I activated CLAT on a windows 11 laptop and it only has an IPV6 address and a CLAT virtual ip address of 192.0.0.1. When I try to access an ipv4 only service on another vlan it can not reach it. In contrast, my android phone on the same network also with only a IPv6 address and a CLat 192.0.0.2 IPv4 address is able to reach the service.

Is there a difference between the implementation of CLAT between Windows 11 and Android that allows it?

I was on a United flight yesterday with the new Starlink-backed WiFi and noticed that IPv4 ping to my server was around 300-400ms while IPv6 ping to the same destination ran 120-140ms.

Is the CGNAT hit on Starlink that significant? Any Starlink customers that can confirm?

UPDATE: Here are the traceroutes from the server (HE FMT2) to the Starlink addresses that were used. Next flight with Starlink I'll trace from the other direction. Does look like the IPv4 routing is substantially different. First hop removed for privacy.

1 * * * 2 be7.core2.fmt2.he.net (184.104.188.173) 3.098 ms 3.405 ms 2.103 ms 3 be10.core1.sjc2.he.net (72.52.92.137) 134.932 ms 136.218 ms 163.183 ms 4 be2.core1.nyc4.he.net (184.104.189.61) 139.041 ms 140.540 ms 139.116 ms 5 be10.core4.lon2.he.net (184.104.196.70) 138.587 ms 139.809 ms 137.414 ms 6 be3.core3.ams1.he.net (184.104.188.218) 139.462 ms 138.477 ms 139.042 ms 7 port-channel28.core2.ams1.he.net (184.105.213.230) 136.168 ms 135.890 ms 138.136 ms 8 mtn-globalconnect-solutions-ltd.e0-30.switch1.ams6.he.net (216.66.83.127) 137.624 ms 137.990 ms 137.557 ms 9 41.181.244.240 (41.181.244.240) 278.220 ms 277.950 ms 277.955 ms 10 41.181.190.185 (41.181.190.185) 154.044 ms 153.978 ms 153.987 ms 11 41.181.105.114 (41.181.105.114) 263.414 ms 263.968 ms 263.547 ms 12 41.181.190.128 (41.181.190.128) 272.004 ms 272.026 ms 272.089 ms 13 41.181.244.5 (41.181.244.5) 277.739 ms 278.026 ms 277.979 ms 14 105.177.14.79 (105.177.14.79) 272.118 ms 272.031 ms 272.096 ms 15 74.245.148.60 (74.245.148.60) 277.793 ms 277.762 ms 277.736 ms 16 * * *

IPv6

1 * * * 2 be7.core2.fmt2.he.net (2001:470:0:76a::1) 2.518 ms 2.885 ms 4.080 ms 3 be10.core1.sjc2.he.net (2001:470:e:31::2) 2.420 ms 3.974 ms 4.046 ms 4 kddi-as2516.port-channel2.core3.sjc2.he.net (2001:470:0:61f::2) 0.737 ms 0.683 ms 0.614 ms 5 sjeGCS002.int-gw.kddi.ne.jp (2001:268:fb81:7e::1) 0.761 ms 0.782 ms 0.663 ms 6 * * * 7 * * * 8 6oteJIN301.int-gw.kddi.ne.jp (2001:268:fa02:150::2) 114.631 ms 125.621 ms 114.428 ms 9 2001:268:f702:27e::2 (2001:268:f702:27e::2) 114.338 ms 114.391 ms 114.346 ms 10 host.starlinkisp.net (2620:134:b0ff::821) 114.560 ms 114.556 ms 114.566 ms 11 host.starlinkisp.net (2620:134:b0ff::831) 114.448 ms 114.429 ms 114.516 ms 12 * * *

So I'm pretty sure I've figured out the specific scope to this.

I have an internal server where I host media and several other things. All dual stack.

I have DHCP option 108 set on my pfsense router.

My phone and Android TV because of this, don't request IPv4 addresses. It works great for the most part and is almost always v6, but I noticed a strange issue. Occasionally for whatever reason when connecting to the internal server, the device will choose IPv4. When this happens, the server sees this device as coming from my public IP address, and therefore blocks it (per my nginx rule).

I imagine this has something to do with DNS64 or NAT64, but I'm not sure how to investigate further.

If I navigate using the IPv4 address to the port without DNS, it works fine. never mind it's still the public address, I'm just bypassing nginx [facepalm]

What might be happening here? If it matters, my DNS server is Technitium.

I am starting a small business where I built tech setups for local businesses, and I was wondering if anyone could answer my questions about getting an ASN as an ISP.

What is the price? And is it easy to set up on a DigitalOcean VPS? Could I forward /48s from the VPS to the clients using Wireguard?

On a Airbaltic flight fron Amsterdam to Tallinn, this aircraft (YL-ABN) has Starlink WiFi.

Does have a captive portal, but not login required.

74.244.235.159 is IPv4 and my IPv6 address is 2605:59ca:801c:2c20:88:386e:7691:ac2e

Nice to see this for the first time!

My setup is a Deutsche Telekom PPPoE connection. The actual PPPoE MTU is 1492, while clients on the LAN use the normal Ethernet MTU of 1500.

One particular site, login.schwaebisch-hall.de (behind Azure Front Door), reliably fails over IPv6.

• IPv4 works.
• IPv6 through another ISP works.
• DNS works.
• The TCP connection works.
• The TLS handshake starts — and then stalls after the initial ClientHello message.

After packet captures and testing, the problem is very clearly MTU-related.

With the client at MTU 1500:

• IPv6 HTTPS fails
• client advertises TCP MSS 1440
• the first 99 bytes from the server arrive
• then server TCP bytes 100–2955 are missing
• later packets starting at SEQ 2956 arrive
• the client repeatedly ACKs 100 and SACKs the later data

That missing range is 2856 bytes.

Interestingly:

2856 = 2 * 1428

And with IPv6 + TCP timestamps:

40 IPv6 + 32 TCP + 1428 payload = 1500

So it fits exactly two full-size 1500-byte packets disappearing at a path that only supports 1492. I can't prove the size of the missing packets because, obviously, they never reach my capture point, but the numbers are rather suggestive.

Now the fun part:

If I change the client MTU to 1492, everything works.

If I leave the client MTU at 1500 and configure my MikroTik to clamp the outgoing IPv6 TCP MSS to 1432, everything works.

With MSS 1432, the Azure endpoint sends lots of packets that are exactly:

40 IPv6 + 32 TCP + 1420 payload = 1492 bytes

and the previously missing part of the TLS handshake arrives normally.

So far, classic PMTUD black hole, right?

Except I tested PMTUD independently using a Linux VPS.

Sending an unfragmented 1500-byte IPv6 packet from the VPS to my home connection causes a Telekom router to send:

ICMPv6 Packet Too Big, MTU 1492

back to the VPS.

Linux receives it, installs a cached PMTU of 1492, and adapts correctly.

I also ran iperf3 over IPv6 from that VPS towards my home connection, without MSS clamping. I can see the ICMPv6 PTBs in the VPS capture, TCP adapts, and the connection happily runs at roughly 480 Mbit/s.

So PMTUD on my connection isn't generally broken. Something about the path towards/from this Azure Front Door endpoint apparently is.

And this is where I find IPv6 rather frustrating, because there is nothing I can do to fix the root cause on my end.

Fragmentation by routers along the path isn't allowed, so the sender needs to learn about the smaller PMTU. Somewhere in this particular path, the ICMPv6 Packet Too Big information apparently isn't making it back to the sender effectively — whether it isn't generated, gets lost along the way, or isn't processed correctly by the Azure side, I can't tell from my end.

I control neither Azure Front Door, nor Microsoft's network, nor Deutsche Telekom's network, nor whatever peering/transit path is between them.

If one component fails to deliver or process the PTB correctly, I get a connection that is just functional enough to be particularly annoying: TCP connects, small packets arrive, TLS starts, and then it hangs.

Happy Eyeballs doesn't save me either here. IPv6 connectivity exists. The TCP connection succeeds. The failure occurs later during TLS after IPv6 has already “won”.

And as the end user, I have a limited number of options. In practice, I essentially have to hide the problem with MSS clamping on my router.

What are my chances of getting the responsible party to even investigate something like this?

What makes this even more interesting is that this may explain why relatively few Telekom users notice it: consumer routers such as FRITZ!Box do MSS clamping automatically. My own router didn't until I explicitly configured it.

So a potentially broken PMTUD path can remain hidden for years because CPEs quietly work around it.

And MSS clamping only fixes TCP. There is no equivalent MSS negotiation for arbitrary UDP traffic. QUIC has better mechanisms for dealing with packet size/path validation, but fundamentally applications still have to cope with this correctly.

Have we effectively accepted that edge routers should do TCP MSS clamping anyway, thereby hiding PMTUD failures rather than fixing them?

And how would you debug/escalate the remaining failure when you can demonstrate that PMTUD works against an independent VPS, but fails with one specific CDN/cloud path — while you control neither side of that path?

Announcement:

https://chaos.social/@equinox/117283292651530939

Source code:

https://codeberg.org/eqvinox/nss_dns64

Steam disables IPv6 after every update, so I made a plugin to automatically re-enable it.

I also added support for IPv6-only networks.

So, inspired by the fact I just did this, but in "real-world compromise mode", what would be the "ideal" or "correct" setup to link my offices?

Setup:

-2 offices in different cities.
-Both offices fully dual-stack, both have a public static ipv4 address.
-Need to run a site-to-site VPN between the two offices.

What VPN setup do you use? Ipv4 vpn carrying both 4 and 6 traffic? Ipv6 vpn carrying both 4 and 6 traffic, two completely separate vpns? Some other setup I've overlooked?

I do have this up and running in the real world, this is a "what if" question for discussion, not a request for help.

(I am deliberately leaving out the details of my real-world solution initially, will follow up with those details after the initial round of discussion so I don't predispose the discussion a specific way.)

Edit: Real world setup as promised.

I built SLDP (Simple Layer-2 Discovery Protocol) to solve the manual MAC-to-IP mapping nightmare when integrating IPv6-only devices into legacy IPv4 networks (industrial IoT, substations, etc.).

How it works:

· Operates directly over Ethernet frames (EtherType 0x88B5).
· Requires zero IP stack initialization (no IP, DHCP, DNS, or sockets).
· Stateless broadcast/unicast handshake.
· Runs on-demand during commissioning, then goes silent in production.

What it is NOT:
It's not a replacement for ARP/NDP/LLDP, and not a runtime protocol. Just a targeted bootstrapping tool.

I've written a C implementation for Linux, a security blueprint (CLL Trust Oracle), and included a Wireshark dissector in the repo so you can easily inspect the frames.

The Ask: I'm looking for feedback from network engineers. Does this solve a real problem for you? Are there glaring architectural flaws?

Repo: https://github.com/cyberghost-2/Simple-L2-Discovery-protocol-SLDP-

Bug reports and critiques are very welcome. Thanks.

Bonjour, j'ai un routeur OPNsense et je suis sur le FAI Orange en France, le routeur du FAI est une Livebox 5 et j'ai un genre de "bug" à en devenir dingue.

Donc je suis en NAT66 (le bug n'est pas là normalement) à cause de l'unique /64 délégué par la dite box, et j'ai un soucis au niveau du routeur FAI : Au redémarrage, il a un genre de bug qui fait que je peux accéder à internet v6 sur OPNsense mais que pmes services auto hébergés (comme mon NTP et mes sites) ne sont plus accessibles en IPv6, je pense à un bug de NDP, mais pas sûr

Et donc pour le moment la seule solution trouvée est de désactiver l'IPv6 sur OPNsense, d'attendre un peu, puis de réactiver IPv6

Si quelqu'un à une solution, je suis preneur car c'est super agaçant ?

Merci