kasperd

https://westergaard.social/users/kasperd

Currently testing this platform to decide whether it's the future of social networking.

Curriculum Vitae:
PhD degree from Aarhus University
Worked at Google Zürich and London
Partner at Intempus Timeregistrering - until it was acquired by Visma
Operating [nat64.net/](https://nat64.net/ )

Public Key

npub1jhpgfu25y30c3h9xrrlxhrhge7669h3xwphjs99nau4k66ctsnyqjxut5y

NIP-05 Address

kasperd_at_westergaard.social@momostr.pink

Profile Code

nprofile1qqsfts5y792zghugmjnp3lnt3m5vlddzmcn8qmegzje772mddv9cfjqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds7msqqm

Publishing to

yabu.me

relay.damus.io

nos.lol

Author Public Key

npub1jhpgfu25y30c3h9xrrlxhrhge7669h3xwphjs99nau4k66ctsnyqjxut5y

Show more details

Last Notes

2026-08-29 12:36:39 UTC

- reply

You didn't mention what is done when a client sends an X-Forwarded-For header to Caddy.

2026-08-21 21:43:08 UTC

- reply

When using CLAT it doesn't make a difference whether MSS clamping is done by CLAT, NAT64, or both. I recommend doing it on both sides to ensure it gets done.
If the NAT64 gateways you use are outside of your control and doesn't do MSS clamping you will get more reliability by having your CLAT do MSS clamping.
I am not sure how much ping will help troubleshooting MTU problems when protocols can be handled differently. I think to ensure you have addressed all the possible MTU problems you'd have to test TCP, UDP, and ping separately. (As far as I recall no other protocol is required to be supported by the NAT64 RFC).
For TCP you can pretty much avoid MTU problems by using MSS clamping. And for UDP there is an extension to do fragmentation on the UDP layer rather than the IP layer. This extension is intended to work better with NAT than IP fragmentation. But it's fairly new and not widely supported.
For DNS it's recommended to switch to TCP if the payload would exceed 1280 bytes on UDP over IPv6. I don't know if other UDP based protocols also aim to avoid fragmentation.

2026-08-21 20:26:49 UTC

- reply

Fragmentation combined with any sort of NAT is going to be fragile. For TCP traffic my recommendation is for the NAT64 to do MSS clamping to 1220 or less.
MSS clamping is a hack, but so is NAT. And most of the downsides of MSS clamping are going to be present anyway when using NAT.
I don't know if Tayga supports MSS clamping. If it does not then I think it should be added as it would probably be beneficial to a significant fraction of users.

2026-08-11 22:52:28 UTC

- reply

I am wondering what percentage of these vulnerabilities were reported previously and not fixed. Not all developers are equally willing to fix reported vulnerabilities.
At times I have gotten the impression that some security vulnerabilities would not be taken seriously unless somebody developed a PoC exploit. This is particular counter-productive in cases where it's a lot more work to develop an exploit than it is to fix the original bug.
This makes me think that maybe for some code bases vulnerabilities now reported by LLM are treated with more urgency than if the same vulnerability had been reported by a person.
There are also cases where bug reports are taken seriously. A TLS downgrade attack I discovered in Django earlier this year was handled very professionally. It could be that the projects now fixing many bugs are ones which already took reports seriously.

2026-07-22 13:24:31 UTC

- reply

I once had a customer demanding a screenshot showing that a certain security feature was turned on. I told the customer there is no such setting in the application because we don't offer any way to turn this security feature off. They kept insisting.

2026-07-06 20:53:30 UTC

- reply

I don't know the instruction set of the CPU in question. On slightly more modern CPU architectures you'd want a HLT instruction inside of that loop to reduce power consumption during idle time.

2026-04-22 18:47:25 UTC

- reply

Do you really need .exe if you already have .com?

2026-04-19 11:52:11 UTC

- reply

Client side failover is a necessity if you want reliability. Even when IPv4 is long gone, I predict the failover code is here to stay. The failover code may even get a little bit more sophisticated.
If we want to minimize client side complexity during the transition, then DNS64 is the way to go. Dual-stack and 464xlat both add complexity on the client side, which you can avoid when using DNS64.
I agree transition technologies should not stay forever. Had people been upgrading in due time, we would never have needed DNS64 and NAT64 in the first place.

2026-04-19 09:32:25 UTC

- reply

I assume you never operated a public NAT64 service. There are networks between the NAT64 gateway and the client which are completely outside of my control. But I can achieve high availability by running multiple NAT64 gateways in independent locations.
I have health checks of the gateways which automatically updates DNS64 accordingly. And I give clients addresses using multiple prefixes to allow for client-side failover. Client-side failover is crucial as sometimes individual clients are unable to reach specific gateways for reasons that are on networks that I don't use myself and thus outside the visibility of my health checks.
A client with a good implementation of fallback between AAAA records works great in this scenario. 464-xlat doesn't handle this as well.

2026-04-18 23:58:32 UTC

- reply

Yeah, ipv4only.arpa exists on authoritative DNS servers and is served essentially like a name would have been served from any other TLD. As far as I recall there is an RFC recommending that DNS recursors hard-code that particular name in order to not need depend on authoritative DNS for that name. But last I checked BIND 9 would query authoritative servers for the name.
DNS64 can work just fine without special casing ipv4only.arpa. It can just translate it like any other IPv4-only domain name, and clients can use that for discovery.
I can definitely confirm that Android supports ipv4only.arpa for NAT64 discovery by default. It might support other methods as well, and I haven't verified which order it will try the methods on a network that supports different methods. None of the NAT64 deployments I have personally encountered used the well-known prefix. So I think falling back to the well-known prefix isn't a great option.
As an operator of public NAT64 gateways I will say that using ipv4only.arpa for NAT64 discovery is not perfect, but all the alternatives I have seen are worse. An inherent drawback of ipv4only.arpa is that it cannot handle scenarios where different NAT64 prefixes are being used depending on IPv4 range. That part is supported when DNS64 is being used.
Another drawback is more of an implementation shortcoming. 464-xlat implementations usually don't support use of multiple NAT64 prefixes for redundancy and will rather just pick one and stick with it. And it's not guaranteed that a client will pick up changes of prefix in a timely fashion.
So if a NAT64 gateway goes down for maintenance it may be necessary for 464-xlat users to disconnect and reconnect in order to switch to a different prefix. Use of PREF64 is worse for that use case. Users actually have to change their router configuration in order to apply the changes. There appears to exist no standardized mechanism for a public NAT64 service to communicate prefix changes to routers of users.
In theory a router could make use of ipv4only.arpa to do NAT64 prefix discovery and communicate this downstream using PREF64. But I haven't heard of any implementation doing this, and I don't see any advantage of this over the client doing discovery directly using ipv4only.arpa.

2026-04-04 13:08:38 UTC

- reply

Problem is you can only do that if you have dual-stack on your own network. Some of us have IPv6-only networks.

2026-04-02 22:05:43 UTC

- reply

I see. Those are following the /64 mappings in RFC 6052. This is not exactly the purpose that RFC 6052 is intended for. And you already identified the scalability challenges of that approach.
I am guessing they use duplicate-address-detection to ensure two machines don't pick the same address. if that guess is correct you can easily verify what happens. Just make have a machine use all of the addresses ending in c0:0:0:0 ti c0:0:700:0 before the test machine connects to the network.
If the implementation is even just a little bit sensible it will see that its preferred IPv6 addresses are already in use and pick a random IPv6 address instead. It can still use any address in the 192.0.0.0/29 range locally.

2026-04-02 18:39:14 UTC

- reply

Why would the scope of 192.0.0.2/29 expand beyond the individual host?

2025-11-06 07:46:09 UTC

- reply

Something is very messed up with the rendering of that page.
https://static.westergaard.social/pleroma/a7fbd107735b577dd9f5693593d562bc698dedb741f5bea53db935c5fbda39a4.png

2025-05-25 15:39:56 UTC

- reply

Did they deliver a working product, and is the product what was agreed upon?

2025-04-27 07:37:49 UTC

- reply

Will reducing the client MTU actually solve this problem in general?
I guess what happens when you do that is that the client knowing this lower MTU will advertise a smaller MSS so the server sends packets which are small enough to fit in the tunnel.
However I can think of a couple of scenarios where that would not help. If the protocol being used isn't TCP, but rather some other protocols such as one based on UDP, then you don't get the MSS negotiation. An application layer negotiation could help if the application layer protocol supports that. But then the applicaiton protocol also have to keep UDP payloads small enough, it couldn't take advantage of IP fragmentation since the IP layer is not going to know about the negotiated size.
Another scenario which won't work is if the client side is more than a single node. For example we have the need for clients to run a virtual network segment for Docker which communicates through a VPN connection. In that scenario the MSS sent by the client would be based on the Docker network and not the VPN tunnel. So the client will advertise an MSS of 1440, because that fits on the Docker network. The server will support that as well. Neither side knows about the VPN in advance, so PMTU discovery will need to work.
I think what's supposed to happen is that when the server sends a packet which won't fit in the PPPoE connection a packet-too-big error is returned to the server. And then WireGuard would need to take that into account for future packets. But if a misconfigured network drops the packet-too-big error messages, then that won't work.

2025-04-01 16:31:38 UTC

- reply

What's the reason a few more weeks is enough?

2025-03-20 19:18:47 UTC

- reply

IPv6 first is what everyone should be doing. I have a frontend on `116.202.1.213` that can be used to reach IPv6-only services by simply adding an A record. Works for all protocols using TLS-SNI and also works for HTTP and SMTP.

2025-03-20 19:06:41 UTC

- reply

Your connection should include a static IPv4 address as well that you can use to connect to your home from the legacy networks on those hotels.
If you choose to run your home network as IPv6-only, then that's absolutely a choice I can respect. But as you realized it does come with some challenges. I am running a couple of public services to help anyone running IPv6-only, since I want to see more IPv6-only networks.

2025-03-07 17:04:03 UTC

- reply

Does this indicate a weakness in LastPass? Or is it simply a matter of users having used a weak master password which is vulnerable to brute force? How much entropy does a master password for a password manager need in order to resist such attacks?

2025-03-05 20:39:10 UTC

- reply

It looks better than modern desktops.

2025-01-17 18:45:12 UTC

- reply

The rationale was that spammers are lazy and don't implement the retry logic whereas legitimate senders will retry properly and the mail will get through once the greylisting period ends.
It would usually affect all senders equally (in principle a spamines score could be computed and used to adjust the greylisting period). However it will usually only affect the first mail from each sender. So people you communicate with repeatedly can email you without that delay.
If a particular sender generates a new sender address each time, they can be affected more often by greylisting than not.
Whether it's a good idea or not can be debated. Spam filters have unfortunately gotten so intrusive that sometimes they cause more harm than the spam they are intended to prevent. I will say that the delay caused by greylisting is a more acceptable behavior than completely blocking some legitimate mails.
Of course it's also entirely possible that it's just the one particular sender who has insufficient capacity.

2025-01-17 03:23:59 UTC

- reply

Sometimes the delay is caused by the receiving server.
Greylisting is somewhat widespread. With greylisting the receiving server will initially respond to an email with a temporary error forcing the sender to wait and retry later.
The code setting the expiry time has no way of knowing how long that will take.

2025-01-04 18:31:47 UTC

- reply

For a moment I thought it said flags would be at half-staff due to the passing of democracy.

2024-10-13 15:44:59 UTC

- reply

That means it can't be used as substitute for L2TP. There will be users on networks where UDP-based protocols are the only options.

2024-10-13 14:57:48 UTC

- reply

Can that be used through NAT? A typical use case for L2TP involves a tunnel running through NAT444.

2024-10-12 16:14:06 UTC

- reply

What is the recommended protocol for use cases that only need tunneling and don't need the cryptography offered by a full-blown VPN?
I know that @npub1sv0…rq9x is one well regarded ISP who includes L2TP tunnels as part of their offering.

2024-09-02 15:58:30 UTC

- reply

I have often used MTU problems as an interview question. Good candidates would usually figure it out in 30 minutes. Not so good candidates would not figure it out in 60 minutes.
And then there was that one time I had a candidate who figured it out in 10 minutes. He was offered the position and then declined.

2024-08-26 21:46:53 UTC

- reply

One example from my own experience is with DNS. Back in 2015 we had a series of outages due to the provider who was hosting our DNS zones.
First the provider had a six hour outage during which we could do nothing, and we couldn't even get in touch with the provider.
Then we tried redundancy across two different DNS providers, which lead to another two outages when the first provider did not handle redundant setups correctly.
At that point I said we will never want to go through this again. And we decided to operate our own DNS servers with redundancy across four different hosting providers.
We have now used that setup for over nine years and not had a single outage of our DNS zone. We have of course had individual DNS servers be down for some time every now and then, but we never had all four go down.
Such a track record of course helps when I am making arguments for multi provider redundancy. I can point at this setup and say over nine years with 100% uptime, had we used Cloudflare we wouldn't have had such a high uptime.

2024-08-26 20:28:58 UTC

- reply

I am thinking one should never trust a single supplier no matter how big and trustworthy you think they are.
One opinion I have heard a few times goes like this: It's not a problem if we are completely dependent on CloudFlare, GCE, or Amazon. If they go down many other systems will go down as well, and customers won't blame us.
The problem with that line of thinking is, that the bigger the provider is, the less important each customer is to the provider. There have been stories about individual customers of big providers getting into trouble.

2024-08-25 14:25:21 UTC

- reply

But why did your router send destination unreachable errors?
Using tcpdump I saw `ICMP6, destination unreachable, unreachable address 2a05:87c6:1:1cc8::1, length 88` coming from 2a00:1098:2::7. And in the traceroute output above that is indicated as `!H`
That behavior from your router is one I would only expect if the next hop address did not respond to neighbor solicitation.
Did you verify that the address you pinged was identical to the next hop address currently in the routing table on that particular router?

2024-08-25 14:06:05 UTC

- reply

That's not what I saw. When I used traceroute I got destination unreachable errors from one of your routers. Here is the traceroute output I shared earlier:
```
traceroute to 2a05:87c6:1:1cc8::1 (2a05:87c6:1:1cc8::1), 30 hops max, 80 byte packets
1 2a00:1098:1::2d 0.284 ms 0.231 ms 0.217 ms
2 2a00:1098:2:ffff::9c 0.401 ms 0.387 ms 0.375 ms
3 2a00:1098:2:1::1c:1 0.437 ms 0.417 ms 0.453 ms
4 2a00:1098:2::7 0.323 ms 0.376 ms 0.365 ms
5 2a00:1098:2::7 3055.197 ms !H 3055.184 ms !H 3055.165 ms !H
```

2024-08-25 13:41:08 UTC

- reply

I agree that is one of the most likely explanations of the root cause. It is something which could have been automatically detected when receiving the advertisements from the route server. But I do not know if any BGP implementation has the logic to detect and filter such faulty advertisements.

2024-08-25 12:46:40 UTC

- reply

It does not look specific to A&A. One of the network paths confirmed to be affected did not go through A&A.
It's confirmed which exchange the issue lies at. But it's unclear to me if the issue is with the destination network or the exchange itself. I do not have a presence at that exchange myself, so the only information I have to work from is output from traceroute and similar tools.
It looks to me like one aspect of the BGP implementation you are using is a contributing factor. But that may very well be standard behavior. For all I know it could be that all other BGP implementations would respond the same in this corner case.

2024-08-25 11:29:47 UTC

- reply

A router server is indeed what I imagine as the most likely way to get the same failure mode as what I saw with OSPF.
It's technically possible to verify that neighbor discovery works for the next hop that you receive from a route server. How to actually implement it depends on the underlying platform and could be complicated.
What did you verify on the data path? The traceroute command I tried failed before the packet reached the data path from 2a00:1098:2::7 to the next hop.

2024-08-25 10:46:49 UTC

- reply

This reminds me of a failure mode I observed in OSPF. I don't know for certain if the same failure mode exists in BGP, but the symptoms sure look similar.
In OSPF the nodes connected to an Ethernet segment will elect a master. OSPF will verify that each node can communicate with the master, and this can be continuously verified with BFD.
OSPF will then assume that if two nodes can both communicate with the master, then they can also communicate directly with each other. If that assumption does not hold OSPF will configure routes which will always fail during the neighbor discovery step of the packet forwarding. I observed this behavior in two mainstream OSPF implementations.
@npub1wy5…64vc @npub1sv0…rq9x Does the BGP implementation that you are using accept routes for which the advertised next hop does not respond to neighbor solicitation?

2024-08-25 10:05:54 UTC

- reply

That hostname resolves to `2a05:87c6:1:1cc8::1` for me. I confirmed that the IP address is reachable from most networks I tried but it is not reachable from @npub1wy5…64vc or @npub1sv0…rq9x
The problem seems to affect both ssh and ping. With both protocols I get an ICMPv6 error message back:
```
ICMP6, destination unreachable, unreachable address 2a05:87c6:1:1cc8::1, length 88
```
The origin of the ICMPv6 error message is 2001:8b0:0:53::109 or 2a00:1098:2::7 depending on which provider I connect from.
Here is an example traceroute output:
```
root@nat64-london:~# traceroute -n -I 2a05:87c6:1:1cc8::1
traceroute to 2a05:87c6:1:1cc8::1 (2a05:87c6:1:1cc8::1), 30 hops max, 80 byte packets
1 2a00:1098:1::2d 0.284 ms 0.231 ms 0.217 ms
2 2a00:1098:2:ffff::9c 0.401 ms 0.387 ms 0.375 ms
3 2a00:1098:2:1::1c:1 0.437 ms 0.417 ms 0.453 ms
4 2a00:1098:2::7 0.323 ms 0.376 ms 0.365 ms
5 2a00:1098:2::7 3055.197 ms !H 3055.184 ms !H 3055.165 ms !H
root@nat64-london:~#
```
The last hop limit exceeded message came from the same IP as the unreachable address. The later error message was delayed by 3 seconds.
In my experience the 3 second delay is most often caused by a neighbor discovery timeout. That indicates that 2a00:1098:2::7 and 2001:8b0:0:53::109 have a route forward towards the destination, but the next hop is not responding to neighbor solicitation messages.