> On 20 Jun 2025, at 23:14, Manuel Kuklinski <m...@asdfghasdfgh.de> wrote:
>
> Hi!
>
> Am Donnerstag 19 Juni 2025 um 10:48:53 +1000, schrieb David Gwynne 2,5K:
>> you should be able to use tcpdump on your box to see the packets
>> coming from the linux host. if you can find which interface the
>> tunnel packets are entering the system with, then you should be
>> able to catch some.
>
> As far as I was able to observe, there are no packets coming in on vio0
> / gre0 - but I'll verify this evening.
>
>> the only reason they would be sending an ipv6 destination options
>> header is if they're using some mobile ipv6 semantics to send a
>> Home Address option. OpenBSD does not implement support for the
>> Home Address option, so we drop the packet before we get to the GRE
>> input processing.
>>
>> the only other options specified for an ipv6 destination option header
>> is for padding, and we do support that.
>
> Tasillo from Freetransit replied the following, quoting verbatim:
>
> "The relevant destination option that is being sent is the Tunnel
> Encapsulation Limit, which is part of the GRE6 specification
> (https://www.rfc-editor.org/rfc/rfc2473.html#section-6.6).
> I would consider not processing that a bug in openbsd."
>
> I'm in no position to judge his statement, regarding a possible bug,
> especially since this is a little above my head ATM...
hmm. i’d want to see a packet capture to know exactly what’s being sent now.
the rfc talks a lot about generic tunnelling with the protocols supported by
gif(4), it doesn’t mention GRE even once. that doesn’t mean they’re not being
combined in interesting ways, i’d just want to see evidence.
at worst the tunnel encapsulation limit itself feels like the security flag
from rfc3514 to me. at best it’s an extra ttl or hop limit for tunnelled
packets.
>
>> can your provider disable that feature on their end?
>
> They're looking for a knob :-)
ok. i’m still trying to decide if it’s interesting enough to implement without
an actual example to work from.
>
> --
> Mit besten Wünschen /
> With best wishes,
>
> Manuel Kuklinski
>