On 07/09/2026 09:42, Saku Ytti via NANOG wrote:
You can in many platforms decide to originate ICMP messages from e.g. loopback instead of the RFC1918 interface. But in that case, why bother with the RFC1918, far-side may route it internally and create attack vector to protect against that you have to consider all kinds of attacks towards that RFC1918. With RFC8950 you don't have to, you only have to worry about the IPv6.
If you don't have IPv6 and you can originate ICMP from loop, maybe IPv4 LL address is less risky than RFC1918?
There's also https://datatracker.ietf.org/doc/html/draft-ietf-idr-linklocal-capability which allows for IPv6 peering using link-local addresses only, which can then carry both IPv4 and IPv6 global unicast routes. That reduces the global attack surface to zero, which is great, and neither of the peers need allocate any global IP prefix to the link, which is also great. Any ICMPv4/v6 errors can be sourced from the loopback interface, as you say. We (and many other data centre operators) use this extensively in-house. Works great, but of course it currently needs the implementations to agree on how the global next-hop field should be filled/understood when there's no global IPv6 address available to put there. Tore