5 ms·

Why is this not just default behaviour? If I don't have IPv4 connectivity, yet a 6-to-4 gateway exists and I have IPv6 connectivity, and some app tries to use

Why is this not just default behaviour? If I don't have IPv4 connectivity, yet a 6-to-4 gateway exists and I have IPv6 connectivity, and some app tries to use IPv4, then clearly the gateway should be used. How about some sysfs config option that says "redirect ipv4 to 6to4 gateway if no default ipv4 route exists", enabled by default.

yrro 3y ago
I'm sure LKML will be happy to review your proposed patch... :)
xerces8 3y ago
Probably due to side effect.
- xerces8 3y ago
  Uh, I mean: side effects It would probably have undesired effect... effects! Why does it autocorrect to effect??... in some cases.
the8472 3y ago
This is probably something you can setup with netfilter, not a sysfs knob.
ignoramous 3y ago
> How about some sysfs config option that says "redirect ipv4 to 6to4 gateway if no default ipv4 route exists", enabled by default. There are various 6to4 on-ramps that solve this. Popular ones are NAT64/DNS64, 464Xlat, and DS-Lite. In my experience, DS-Lite works nicely with v4-only apps/services or v6-only apps/services.
gorkish 3y ago
Yeah I agree this does seem like something that really ought to simply be configurable out of the box with options for transparently handling both 6-to-4 and 4-to-6 when the appropriate services are discoverable or configured on the network. The top level reply here discussing how MacOS handles it seems like something that should be able to be recreated with iptables, but when searching I am extremely surprised to discover that Linux does not seem to have the ability to do anything similar. It seems most solutions focus on using socat in userspace to proxy data between the sockets which is not really a practical solution.
- londons_explore 3y ago
  Linux is usually king when it comes to networking and configurability - so I too am really surprised it isn't an option to do something sane.
  - wmf 3y ago
    Linux has various implementations of 464 but they just aren't on by default in your distro.
p1mrx 3y ago
The right solution for Linux would be 464XLAT support in systemd: https://github.com/systemd/systemd/issues/23674 https://github.com/systemd/systemd/issues/23674

yrro 3y ago

I'm sure LKML will be happy to review your proposed patch... :)

xerces8 3y ago

Probably due to side effect.

xerces8 3y ago
Uh, I mean: side effects It would probably have undesired effect... effects! Why does it autocorrect to effect??... in some cases.

the8472 3y ago

This is probably something you can setup with netfilter, not a sysfs knob.

ignoramous 3y ago

> How about some sysfs config option that says "redirect ipv4 to 6to4 gateway if no default ipv4 route exists", enabled by default. There are various 6to4 on-ramps that solve this. Popular ones are NAT64/DNS64, 464Xlat, and DS-Lite. In my experience, DS-Lite works nicely with v4-only apps/services or v6-only apps/services.

gorkish 3y ago

Yeah I agree this does seem like something that really ought to simply be configurable out of the box with options for transparently handling both 6-to-4 and 4-to-6 when the appropriate services are discoverable or configured on the network. The top level reply here discussing how MacOS handles it seems like something that should be able to be recreated with iptables, but when searching I am extremely surprised to discover that Linux does not seem to have the ability to do anything similar. It seems most solutions focus on using socat in userspace to proxy data between the sockets which is not really a practical solution.

londons_explore 3y ago
Linux is usually king when it comes to networking and configurability - so I too am really surprised it isn't an option to do something sane.
- wmf 3y ago
  Linux has various implementations of 464 but they just aren't on by default in your distro.

p1mrx 3y ago

The right solution for Linux would be 464XLAT support in systemd: https://github.com/systemd/systemd/issues/23674 https://github.com/systemd/systemd/issues/23674