[HN Gopher] Enabling IPv6 support for IPv4-only apps on Linux
___________________________________________________________________
Enabling IPv6 support for IPv4-only apps on Linux
Author : pabs3
Score : 173 points
Date : 2023-10-04 05:59 UTC (17 hours ago)
(HTM) web link (blog.apnic.net)
(TXT) w3m dump (blog.apnic.net)
| ninkendo wrote:
| Coming from the Apple ecosystem, this is solved on macOS/iOS by a
| native implementation of 464XLAT on the device (particularly the
| CLAT relay part.)
|
| If you have a working NAT64/DNS64 setup, macOS can make a AAAA
| (ipv6 DNS) request to ipv4only.arpa, and observe the form the
| result comes back as, in order to learn the IPv6 prefix used for
| IPv4 compatibility on the network (eg. 64:ff9b::/96), and if it's
| not given an IPv4 address via DHCP, will set up a local interface
| at 192.0.0.1 that is the default route for all IPv4 traffic.
| Anything sent to this interface will translate the address to the
| corresponding IPv6 compatibility address and send it to your IPv6
| router (which should use NAT64 to send it to the destination.)
|
| In this sense, you don't need any IPv4 infrastructure at all in
| your network (no DHCP, etc) and all traffic on your LAN will be
| IPv6, but IPv4-only apps (including those that hardcode IPv4
| addresses and try to connect to them) work fine.
|
| A quick web search says that linux has a similar thing
| implemented as a userspace daemon (clatd) which presumably does
| something similar, and importantly doesn't rely on LD_PRELOAD
| hacks like this article suggests (LD_PRELOAD doesn't work with
| static binaries like those written in Go, for instance.)
| pavel_odintsov wrote:
| Author is here.
|
| Thank you for sharing! Yes, macOS has such logic and it works
| just fine. The main issue from clatd that it's pretty tricky to
| setup and it emulates presence of IPv4 on machine which is not
| very desirable as it tends to hide issues with other tools.
|
| My plan was to explicitly disable IPv4 connectivity for machine
| and hide it from other app but keep it active for subset of
| well known broken tools and then fix them one by one and switch
| to IPv6 only setup.
| e61133e3 wrote:
| Where can I find documentation about this?
| WirelessGigabit wrote:
| T-Mobile has it in the USA for their mobile network.
|
| https://archive.nanog.org/sites/default/files/wednesday_gene.
| ..
| WirelessGigabit wrote:
| The largest problem with this is that that this IPv6 router
| lives outside of your devices. It lives somewhere at the ISPs
| infrastructure.
|
| And this causes a massive headache when it comes to systems
| that track you based on your IPv4 address. For example there
| are applications that track you by your IP address. And if you
| want to opt-out they refuse because the IPv4 address you give
| them is owned by T-Mobile.
|
| Also, it completely breaks stateless applications.
|
| When you have an IPv4 <> IPv4 UDP tunnel you can just send
| traffic. If one device is behind NAT you set up port
| forwarding. It'll work today, it'll work tomorrow, and in 2
| years.
|
| The tunnel that the NAT64 system sets up is time-bound. So
| while outgoing traffic re-establishes the route, incoming
| traffic is not stateless. It stops.
|
| I have this issue with WireGuard and iOS. The iOS
| implementation sadly prefers A over AAAA. So when I'm on 5G it
| connects over a NAT64 route, but due to the NAT64 route
| dropping after x time push notifications break. When you then
| turn on the phone, some traffic re-establishes the NAT64 tunnel
| and all of the sudden you get a whole bunch of notifications.
| p1mrx wrote:
| The problems you describe apply to CGNAT in general, which is
| unavoidable in a world with more humans than IPv4 addresses.
|
| Our best hope to avoid CGNAT is more/better IPv6 support.
| ninkendo wrote:
| > The largest problem with this is that that this IPv6 router
| lives outside of your devices. It lives somewhere at the ISPs
| infrastructure.
|
| I use my own router which supports NAT64. I use OpenBSD which
| supports it natively in-kernel, but you can get NAT64 with
| any competent router software (OpenWRT, pfsense, etc.)
|
| > And this causes a massive headache when it comes to systems
| that track you based on your IPv4 address. For example there
| are applications that track you by your IP address. And if
| you want to opt-out they refuse because the IPv4 address you
| give them is owned by T-Mobile.
|
| Huh? I don't follow what you're saying... websites see an
| IPv4 address when I connect. I'm using NAT64, after all. It's
| just the _client OS_ that thinks it doesn't have an IPv4
| address. My OS sends traffic as IPv6 to 64:ff9b::/96, but the
| router turns around and makes an IPv4 request with the IPv4
| address I get from my ISP. I have IPv4 at the gateway but
| nothing else in my network sees it.
|
| > Also, it completely breaks stateless applications.
|
| I don't know what this means but I haven't seen a single
| broken application?
|
| > When you have an IPv4 <> IPv4 UDP tunnel you can just send
| traffic. If one device is behind NAT you set up port
| forwarding. It'll work today, it'll work tomorrow, and in 2
| years.
|
| I can NAT inbound IPv4 requests to my internal IPv6 machines
| too, I don't know what the issue is for you here. I choose
| not to, since I don't want to deal with it, but the option is
| available if I want.
|
| > The tunnel that the NAT64 system sets up is time-bound. So
| while outgoing traffic re-establishes the route, incoming
| traffic is not stateless. It stops.
|
| I don't know what you're referring to here... it's _exactly_
| the same as how NAT works in IPv4. Outbound requests from my
| internal network are tracked with NAT, and return traffic is
| rewritten back to the IPv6 address that sent it. There 's no
| difference between that and IPv4 outbound NAT here. I don't
| know what you're talking about with "tunnels" or anything.
| londons_explore wrote:
| Google and Apple have both established an unofficial standard
| that any middleboxes that keep state (eg. NAT) has to keep a
| session open for 30 minutes for both TCP and UDP. Anyone that
| doesn't will have push notifications failing as you've
| pointed out.
| ok123456 wrote:
| Having to do an LD_PRELOAD to front run system calls in order to
| support IPv6, tells you that IPv6 is just fundamentally broken.
| pavel_odintsov wrote:
| It was more about way to fix some very broken tool. ssh was
| just an example. It may be proprietary app without source code
| available.
| sschueller wrote:
| Does anyone have a good write up of taking ones home network and
| going 100% ipv6 including dealing with iot devices that can't? I
| am thinking of doing it but I have a huge mix of devices from
| linux to windows and servers.
| m463 wrote:
| I'm 100% the opposite. Define everything ipv4, turn off ipv6
| and have one set of private ip addresses, one set of firewall
| rules and NAT at the firewall/router.
| hot_gril wrote:
| Yep, first thing I always do on a new router or PC is get out
| of the dual stack situation by disabling v6.
| menthe wrote:
| There's absolutely _no_ good reason to do that if you're only
| facing the internet with a single IP on your router as a NAT
| gateway, except to make your life hell. Only thing that may be
| worth doing is parting ways with the one internet-facing IPv4
| and relying solely on IPv6 there, but that's mostly up to your
| ISP and their own infrastructure. Even if you were to 100% NAT
| your IPv4 LAN to IPv6 WAN, and your ISP still dedicated your
| router a public IPv4, it'd benefit no one.
| BlueTemplar wrote:
| Why wouldn't you be able to disable IPv4 in the router ?
|
| Also, isn't trying to run both IPv4 and IPv6 inherently a
| security issue coming from the complexity of dealing with two
| overlapping networks with very different logic ?
| simiones wrote:
| Then how would you reach the IPv4-only internet (i.e. a
| large part of the Internet)?
| crote wrote:
| It depends on your ISP, but providers are slowly
| switching to IPv6-only connections to their customers.
| The customer's router converts v4 to v6, and a translator
| at the ISP converts back to v4.
|
| If you do the 4-to-6 translation on your own machine,
| your local router doesn't need to know about v4 at all.
| This is already happening with mobile networks.
| sschueller wrote:
| I get a static /48 IPv6 subnet from my ISP so I want to give
| it a try.
| rnhmjoj wrote:
| There's virtually nothing on this, I guess nobody cares enough
| about IPv6 to spend time to actively remove IPv4 on their home.
| I did it, mostly for fun and because I hate managing a dual
| stack: I have been running a 100% IPv6-only network at home for
| a couple of years, now.
|
| It works by having several IPv6-only subnets and a dual stack
| router (running openwrt) that performs stateful NAT64 [1] using
| Jool. This allows to access both the IPv4 internet and local
| IPv4 islands[2] (basically old devices like printers).
|
| There's no DHCP or NAPT involved: the router gets a /56 prefix
| from the ISP and performs prefix delegation, so every device
| does SLAAC and assigns itself a fully routable IPv6 address.
|
| For DNS I use dnscrypt-proxy2: it's very easy to set up and it
| can do DNS64 and static hostnames mapping. Since prefix is
| stable, I just assign names to the stable EUI-64 addresses of
| the hosts I care about. Alternatively you can use bind for
| DNS64 and mDNS if you don't like manually assigning names.
| There's also a script to automatically assigns names based on
| ICMPv6 neighbours discovery [3].
|
| I also host some services on the IPv4 internet from IPv6-only
| hosts: for this you need the NAT64 equivalent of port
| forwarding, which is setting up static BIB entries [4].
|
| [1]: https://nicmx.github.io/Jool/en/intro-xlat.html#stateful-
| nat...
|
| [2]: https://ungleich.ch/u/blog/managing-ipv4-islands-with-
| jool-a...
|
| [3]: https://github.com/AndreBL/ip6neigh/
|
| [4]: https://nicmx.github.io/Jool/en/bib.html
| zekica wrote:
| If the network already supports NAT64 I would use CLAT running on
| the system. That way you don't need LD_PRELOAD.
| Kaxo wrote:
| I feel the exact opposite. I've recently been experimenting
| with ipv6 only via NAT64/DNS64 and run into the same problem
| (with steam trying to connect out to hard-coded ipv4
| addresses).
|
| I started to look into CLAT and really didn't want to have to
| go through the hassle of a whole new virtual interface with
| routes etc, when one single app can't just pass a couple
| different args to connect().
|
| I actually had thought about trying to write something exactly
| like this myself.
|
| I'm glad to learn it already exists.
| giancarlostoro wrote:
| So when and how will IPv6 become the absolute standard? I presume
| an act of government law would do it, otherwise, if tech
| companies got together to force the change en masse, that would
| also do it.
|
| I don't understand why IPv6 has not become more prevalent over
| the coming years. Seems like we're taking baby steps and growing
| in our dependence on IPv4 IPs, although based on other comments
| here it sounds like at least Linux and Mac have a way to handle
| this transparently, not sure about Windows.
| hatch_q wrote:
| Possibly never, because security. NAT at least tries to hide
| insecure IoT device on your grandma's wifi.
|
| shodan.io has support for ipv6. With ipv4 you're somewhat
| restricted to devices that get public ip (corporate networks)
| or devices that drill a hole (uPnP/port forward). IPv6 devices
| are publicly visible by default and you need to manually setup
| firewall to filter this out (not trivial - especially for UDP
| and ICMP)
| lazide wrote:
| Every firewall I've dealt with since forever has default deny
| on inbound traffic, state full allow for outbound
| connections. Regardless of NAT or not, and regardless of how
| cheap it is.
| hatch_q wrote:
| Name one vendor? I can name you 3 that don't. Zyxel,
| Ubiquiti, Mikrotik. Also anything wrt based (eg. dd-wrt).
|
| In fact one of the warnings on dd-wrt official IPv6
| tutorial: """ Keep in mind it can be dangerous to enable
| IPv6 without also having a firewall on each client that
| handles IPv6 packets, or having ip6tables on your router to
| filter incoming connections. ip6tables is NOT included by
| default with DD-WRT, which means your clients will be
| directly exposed to the Internet once you have enabled
| IPv6. """
| lazide wrote:
| Hmm, I think you're right! Apologies! And now off to
| check my firewall rules!
| hot_gril wrote:
| This is my concern too. NAT is nice because it's stupid
| and secure by default. No matter how you misconfigure it,
| the router simply doesn't know where to forward inbound
| packets to, unlike a firewall which has to actively
| block. My assumption for routers is that they won't
| handle firewalls right, especially the many cheapo ones.
| andrewaylett wrote:
| Ubiquiti do -- and it's very nice to be able to punch
| holes in it when I _do_ want to let HTTPS traffic in to
| specific addresses, rather than need to try to shoehorn
| everything onto a single IPv4 address.
|
| IPv6 support is sufficiently widespread that pretty much
| the only place I can't access IPv6-only services from is
| the office :P.
| ianburrell wrote:
| IPv6 has been silently growing. If Hacker News supported IPv6,
| there is a good chance you would be accessing it with IPv6. The
| problem is that may have hit a plateau with the easy
| migrations. The issue is that there is no incentive for most
| businesses to make switch.
|
| I was thinking that there should be movement that IPv6 is the
| new default protocol. That includes requesting IPv6 from sites.
| Also, lots of docs on how to enable IPv6 with routers, program
| to label gear as IPv6-ready, and persuading manufacturers to
| enable IPv6 by default.
|
| Finally, have best practices for IPv6 on corporate networks.
| With NAT64, it is possible to have IPv6-only network with IPv4
| on the edge. I think it needs docs that describe how to do it,
| and lots of work in changing opinions of network engineers.
| blueflow wrote:
| The main advantage of Linux over other systems is that its
| available from source and thus can be patched and recompiled
| easily. Here we see someone using LD_PRELOAD to patch the
| behavior of a binary, because they rely on distributions pre-
| compiled packages without means to change the source code
| themselves. This sort of negates that advantage, right?
| charcircuit wrote:
| This way works with any binary. Your idea of patching the
| source would have to be done to every single program that uses
| the network that you want to work like this. Really this should
| just be a part of the OS though.
| nightfly wrote:
| Having an additional way to effect changes in behavior without
| recompiling an application hardly negates the benefit you
| described. They don't say the _cant_ or _couldn't_ change the
| source themselves either. And what you described is hardly the
| main advantage of Linux, FreeBSD enables that _much_ easier.
| yrro wrote:
| I don't think openssh upstream would accept a patch that makes
| ssh interpret ipv4 addresses as anything other than ipv4
| addresses, and who wants to carry such a patch downstream
| forever?
| blueflow wrote:
| You don't need to merge upstream! Its your source, your
| build, your rules.
| yrro wrote:
| And if you're happy to take on that work (and the
| associated risk) forever, go for it. For others, hacks like
| tnat64 work fine. They also work for lots of programs,
| where patching each one individually to somehow detect that
| it's behind NAT64 and behave differently is a lot of work!
| londons_explore wrote:
| Maintaining your own patchset for your personal use is
| usually not a good use of your time and expertise.
|
| Every time someone runs a linter over upstream, you're
| going to have to remake that patch. Sure, it's only 20
| mins... But that multiplied by every bit of software you
| patch and every release, and you quickly realise that a
| huge chunk of your life was wasted doing what is
| effectively busywork.
|
| Instead, contribute your time and efforts back to upstream,
| and now your efforts can help millions of people not just
| one. If others do the same, you'll see far more
| improvements to the software you use than you alone could
| ever write and maintain.
| blueflow wrote:
| You don't have to, its your own fork.
| londons_explore wrote:
| But you might want to integrate security patches... And
| one day you're going to need to make changes to support
| non-ancient glibc versions etc.
|
| Even staying still in the world of software involves some
| level of effort.
| KirillPanov wrote:
| The "upstream or nothing" attitude is an attempt to erase
| any difference between free software and "visible
| source".
|
| Offering changes back to upstream is always encouraged,
| but whether or not it is accepted is largely irrelevant
| to the patch author.
| londons_explore wrote:
| I just don't think it's a good use of OP's time -
| effectively developing and maintaining software for 1
| user.
|
| One main benefit of software/computers/the internet is
| that work done by one person can benefit millions - thats
| what sets us apart from cavemen who had to do everything
| for themselves, and got a worse quality of life as a
| result.
| dspillett wrote:
| This method could apply to other tools with the same IPv4/IPv6
| behaviour, without further modification. Changing the behaviour
| in the utility directly would only fix it for that one utility
| meaning that to fix another you need to do the same work again.
| It is perhaps also safer than modifying such a core component
| as SSH: if you introduce a bug the trick can be easily disabled
| until fixed, if you accidentally break SSH you might cause
| yourself significantly more hassle.
|
| _> This sort of negates that advantage_
|
| LD_PRELOAD trickery doesn't negate the advantage of having full
| source access, patching SSH would also have been a perfectly
| valid option, but is perhaps a better tool for this particular
| job.
|
| For another use of the trick see
| https://github.com/mariusae/trickle (the project looks stale,
| though that may be because it is properly done and there have
| been no security/other bugs to fix in recent history) which
| slips its own functions in the call chain to apply user
| controlled (rather than firewall/routing level) throughput
| shaping to utilities that don't offer it out of the box.
| depr wrote:
| Isn't having the source available only the advantage it has
| over Windows? For most people the advantage is probably, as
| 'bcantrill once said, that they can Google their stacktraces.
| andylynch wrote:
| Plenty of people aren't that concerned about building stuff
| from source, even when they are running on Linux. Often,
| proprietary third-party code doesn't have source available at
| all.
| userbinator wrote:
| Try actually recompiling something nontrivial but open-source,
| and getting the exact binary you already have, the one which
| you know works but just needs the one modification you want.
|
| You'll quickly discover that "open source" doesn't make
| everything easier.
| loondri wrote:
| I think retrofitting IPv4-only apps for IPv6 compatibility might
| be a short-term fix. It could be more forward-thinking to focus
| on developing new apps with inherent IPv6 support to prevent
| accruing technical debt and facing complications tied to
| maintaining outdated IPv4-only applications.
| BlueTemplar wrote:
| Please name and shame software/hardware that doesn't support
| IPv6 released after 2017 (when the IPv6 standard was _finally_
| finalized).
| SSLy wrote:
| Any android phone
| crote wrote:
| Android has had support for IPv6 since at least 2014, and
| there are plenty of mobile networks which are IPv6-only and
| work just fine with Android phones doing CLAT.
|
| The only thing missing is DHCPv6, and that's a deliberate
| decision - albeit a somewhat controversial one.
| janc_ wrote:
| What do you mean? My Android phone does IPv6?
| trustingtrust wrote:
| > To prove that IPv6 is ready for production use
|
| No one is debating it's not ready for production use. It's just
| that it's a lot easier to configure clients in dual stack than do
| a 6 to 4 translation.
| [deleted]
| londons_explore wrote:
| 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.
| p1mrx wrote:
| The right solution for Linux would be 464XLAT support in
| systemd: https://github.com/systemd/systemd/issues/23674
| ignoramous wrote:
| > _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 wrote:
| 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 wrote:
| 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 wrote:
| Linux has various implementations of 464 but they just
| aren't on by default in your distro.
| yrro wrote:
| I'm sure LKML will be happy to review your proposed patch... :)
| the8472 wrote:
| This is probably something you can setup with netfilter, not a
| sysfs knob.
| xerces8 wrote:
| Probably due to side effect.
| xerces8 wrote:
| Uh, I mean: side effects
|
| It would probably have undesired effect... effects! Why does
| it autocorrect to effect??... in some cases.
| kuon wrote:
| Discord hardcodes ipv4 addresses and will not work for webrtc
| calls in DNS64 setup. In 2023 I consider it an insult to the
| internet as a whole.
| giancarlostoro wrote:
| I'm of the opinion that IPv6 is old enough that the fact we
| have not hopped to it yet means its not happening anytime soon.
| I wanted it back in 2008 when I first learned about it, and I
| know its older than that (90s iirc) so its either going to come
| one day "abruptly" by force and break half the internet, or
| people will do hacks to maintain IPv4 as is.
|
| I think the only way IPv6 will ever become mainstream is if
| either the EU or US Congress pass a bill making it the
| preferred IP standard.
| heartjudytenuta wrote:
| China has mandated moving to single-stack IPv6 by the end of
| the decade.
|
| It is not well publicized.
|
| It turns out when you have a government that can tell you
| "move to IPv6 or we'll have your legs broken and your family
| thrown in prison" it's a bit easier to get things moving.
| anticensor wrote:
| More like "move to IPv6 or you will be disconnected from
| the internet completely".
| hot_gril wrote:
| When they need to solve the address space crisis, they can
| make a "v4.1" that's just v4 but with an expanded address
| space. Existing addresses and decimal format stay; NAT DNS
| DHCP ARP etc stay mostly the same aside from supporting
| longer addresses. Cloudflare DNS is still 1.1.1.1, my private
| ip is 192.168.1.2, public 71.177.17.171, some new ISP hands
| out 11.127.13.121.143.356 when they run out of shorter
| addresses, life moves on.
|
| I know v6 supports NAT, but it was basically designed to
| remove it with the whole random addressing scheme, and that
| isn't necessary for solving this problem (idk if things were
| different in the 1990s).
| kuon wrote:
| Yeah, we need more incentive. Ipv6 is harder to implement
| yes, it is true, there is no point in denying this and
| arguing it solves tons of problem (it does). Most companies
| have ipv4 experience and it's just simpler. There must be
| some political pressure to make it move. But "hopefully" the
| economical pressure is starting to build up, a lot of
| providers are cheaper in ipv6 only configuration.
|
| Still, for a company like discord, not even using host names
| to allow DNS64 is really sad.
| ianburrell wrote:
| One thing that might help is government regulation that any
| ISP using CGNAT must offer IPv6. Customers should get
| public IP address, single IPv4 or /64 IPv6.
|
| Another would be that government customers need to have
| IPv6-enabled sites. This could get a lot of companies to
| add IPv6 hosting.
| photonbeam wrote:
| Plenty of big sites have no AAAA record even
| pavel_odintsov wrote:
| It can be easily sorted out with DNS64 and NAT64:
| https://pavel.network/building-gateway-to-access-legacy-
| ipv4...
| hot_gril wrote:
| If ipv4 is just simpler and people prefer it like you say,
| that's a sign that v6 isn't a good option for replacement.
| ianburrell wrote:
| 40-45% of Google traffic uses IPv6. If you are in the US,
| your mobile traffic is probably IPv6. At home, your ISP
| likely supports IPv6, you can get by enabling on router or
| upgrading router.
|
| The problem areas are with hosting and corporate networks.
| The Google numbers are smaller during the week as people use
| IPv4-only corporate networks.
| VoodooJuJu wrote:
| IPv6 is an insult.
| keep_reading wrote:
| - we never got the integrated IPSEC
|
| - enough addresses for everyone on the planet, but we can't
| freely give out permanent static allocations to everyone
| because it would explode the routing tables
|
| - so we never got our permanent roaming addresses we were
| promised
|
| - NAT66 exists
|
| - IPv6 was (still is?) a moving target for implementors
|
| It's worse than an insult
| Dylan16807 wrote:
| "It only has _some_ of the benefits over IPv4 " is not
| worse than an insult.
|
| Best practices changing applies to IPv4 too.
|
| NAT exists but you don't need it and even if you do use it
| you don't have to track connections.
| hot_gril wrote:
| IPv6 to me is an example of "not letting a good crisis go to
| waste." The real problem was running out of addresses, but
| the solution got lots of less necessary changes bundled into
| it, rather than just adding more address space.
| johnklos wrote:
| Discord not running in a browser on a system that can ONLY do 3
| billion instructions a second is an insult to the Internet.
| zajio1am wrote:
| DNS64 is horrible back, that is way reasonable IPv6-only setups
| use 464XLAT.
| pavel_odintsov wrote:
| Thank you for great feedback! I decided to cover NAT64 and DNS64
| gateway setup guide mentioned in this article briefly:
| https://pavel.network/building-gateway-to-access-legacy-ipv4...
| sargun wrote:
| I made a Terrible decision of a project at Netflix. The idea was
| that you could swap out an IPv4 (AF_INET/SOCK_STREAM) socket with
| an AF_INET6 one.
|
| Turns out actually doing this with the Linux kernel is
| exceptionally difficult. You can swap out the underlying sk, but
| doing it safely is damn near impossible because the two data
| structures aren't really built like that.
|
| One day, I'd love if someone added the ability to swap Unix
| sockets for TCP sockets at runtime to the kernel -- for other
| reasons.
| dezgeg wrote:
| Did you try just dup2()'ing a new socket file descriptor over
| the old socket file descriptor? Probably it bring other kinds
| of problems, but would be interesting to hear what they are.
| sargun wrote:
| Yep. You lose sockopts (trivially restorable), async
| ownership (less trivially restorable, but with some kernel
| patches, it's possible), and epoll registration (which omg,
| wtf.).
|
| The other problem is that we found runtimes that would
| immediately send data after a non blocking connect (or
| receive data), and you needed a way to kick these off again.
| It was really a nightmare to restore all that state in a
| running socket.
|
| The real solution was to add a new address family, and patch
| the kernel (as opposed to a module), that could dynamically
| switch back and forth (think AF_KCM). Unfortunately, I never
| got around to that.
| endre wrote:
| Tell us more about Netflix experimental projects like this.
| usr1106 wrote:
| ssh 64:ff9b::1.3.3.7
|
| What address syntax is that? I mean I can easily guess what it
| means, but I wasn't aware such mixture exists. Do connect(2) and
| friends support that?
| pavel_odintsov wrote:
| Thank you very much for this question. I've rewrote and improve
| my article to cover exactly this topic:
| https://pavel.network/building-gateway-to-access-legacy-ipv4...
| g232089 wrote:
| It's an RFC6052 address.
| usr1106 wrote:
| Thanks for the pointer. Actually RFC6052 just refers to
| RFC4291 from 2006 in this case. And that simply calls it an
| alternative representation.
|
| Edit: RFC1884 from 1995 already had it, nothing has changed
| in that aspect.
| chungy wrote:
| It's an IPv4-mapped IPv6 address. Just interpret the IPv4
| address like it's the last 32 bits of the v6 address.
|
| In the example, 64:ff9b::103:307 is equivalent. A more
| complicated example might be akin to 64:ff9b::198.51.100.231,
| equivalent to 64:ff9b::c633:64e7.
| anticristi wrote:
| Too bad I live in a developing country when it comes to IPv6. Hi
| from Sweden!
| maltris wrote:
| I kid you not, WordPress.org does not support IPv6 to fetch
| plugins, themes etc.
|
| https://meta.trac.wordpress.org/ticket/3090
|
| "The WordPress.org systems team DO have IPv6 plans, but at
| present there are higher priority tasks and there's no widespread
| requirement for IPv6 connectivity."
|
| Its not possible to run a WordPress instance and auto-update with
| IPv6-only and without any kind of adress translation.
| maltris wrote:
| Ticket is 6 years old by the way ...
| johnklos wrote:
| Wordpress auto-update is fundamentally broken, anyway, which is
| why it's still one of the most popular phishing site hosting
| platforms out there.
|
| This is sad, but not surprising.
| finaard wrote:
| Would be interesting to know which applications actually have
| problems with v6 - the example with directly using a v4 IP is
| more a user error, not an application issue.
|
| I pretty much stopped submitting patches enabling v6
| functionality to various projects back in 2005 as everything I
| cared about was working at that point. (Side note, I was just
| trying to search a few of those - but seems that period pretty
| much doesn't exist in search engine caches anymore. I knew the
| state of preserving internet history is bad, but I didn't expect
| it to be _that_ bad)
| Faaak wrote:
| The folding@home client, for example, is written in C with a
| "does everything" library (called cbang if I recall correctly).
| The library only uses sockets with AF_INET and thus it doesn't
| work even with AAAA records..
| nova77hn wrote:
| WSL2 famously doesn't support ipv6 (because of NAT) which is
| mightily annoying.
| ajsnigrutin wrote:
| Why is NAT a problem here? IPv6 supports full NAT (no matter
| that the basic idea of ipv6 is "no nat").
| uxp8u61q wrote:
| The prerelease finally supports ipv6:
| https://github.com/microsoft/WSL/releases
| yetanotherloss wrote:
| There seem to be hard cuts in search returns at 5 and 10 years,
| it's been really difficult to find anything from before 2012
| without incredibly specific searches. Lots and lots of link rot
| too so it's hard to say how much of that is google/bing/etc.
| josephcsible wrote:
| Docker's support for IPv6 is really poor. Basics are still
| gated behind the "experimental" flag, and there are bugs that
| have been open for years preventing very common configurations
| from working.
| mmis1000 wrote:
| It don't even support dynamically assigned ipv6 address. And
| ipv6 prefix need to be hardcoded into config. And even worse
| , ipv6 address(not suffix) is bounded directly to the
| container at creation time. If your ipv6 prefix changed for
| whatever reason.(laptop is a thing since 20 years ago, you
| know) Best you can do is scrap the container and make a new
| one. I would say keep it experimental at current status is a
| good decision. It's simply not usable currently.
| dementik wrote:
| Colima on mac is struggling with ipv6. Not sure what component
| is responsible, but I have been unable to connect ipv6 hosts
| from colima containers.
| cramjabsyn wrote:
| 6 to 4 is pretty easy with socat but comes with the downsides of
| being a userspace l3 proxy
| xerces8 wrote:
| And me living here and now with no ipv6 at all.
|
| (they say my or most ISP can enable ipv6 on reuest; country :
| Slovenia, year : 2023)
| unmole wrote:
| I moved to a new place ~600 meters away and had to go from
| having IPv6 over FTTH to IPv4 over copper. It's been over 6
| months but I still can't get over it.
| heartjudytenuta wrote:
| "To prove that IPv6 is ready for production use, I built a second
| PC so I can access the IPv4 Internet"
| viraptor wrote:
| Being able to access legacy systems from new ones is a good
| property of new systems. This workaround is important.
|
| (Also that may be done on routers which today deal with NAT
| anyway)
| heartjudytenuta wrote:
| This isn't a workaround; it is a kludge. There are far better
| solutions in this problem space (some mentioned in this very
| thread).
| Bluecobra wrote:
| Yeah I don't get it. If you need to access IPv4 for legacy
| reasons then dual stack seems like the solution here. Yes
| it's a lot of overhead since you have to deal with an IPv4
| and IPv6 routing table. AFAIK Windows has had both enabled
| by default for a long time.
| usr1106 wrote:
| An average user is not expected to do that. But I understand
| there are mobile operators out there who have been doing this
| (instead of NAT) for a while because they don't have IPv4
| addresses for every consumer subscription? Wasn't T-Mobile US
| one of them? (Not living in the US.)
| BlueTemplar wrote:
| An average user shouldn't be able to find hardware not
| supporting IPv6, because it shouldn't be allowed to be sold.
| (And soon, hardware supporting IPv4.) Just like it happened
| with digital TV standards.
| dolmen wrote:
| Yes. Like EU making mandatory the standard for phone
| chargers.
| pavel_odintsov wrote:
| In home network single $70 USD device with 2 daemons running
| may be clearly too much but for corporate or even office
| network it's just one more box in addition to dozens of network
| devices.
| sgjohnson wrote:
| This is actually a very good workaround/transition mechanism,
| because it lets you go fully IPv6 native, keeping the
| translation layer for things that absolutely must use IPv4.
|
| And after transition is done, in theory, all you'd do would be
| turn off the translation box. In practice you'll have to keep
| it up until the end of days, but that's a separate matter.
| pavel_odintsov wrote:
| Thank you very much for approving my idea!
| imoverclocked wrote:
| Super cool! I tried doing a pure IPv6 network a little over a
| decade ago; Maybe I'll try it again. Though, my cheap IoT devices
| likely still need IPv4... but perhaps not internet connectivity.
| It might be fun to explore just how much IPv4 continues to be
| ingrained into cheap Things (eg: Arduino WiFI?) There always
| seems to be a long tail of small places where IPv4 pops straight
| back into the equation.
| nelgaard wrote:
| plus these individual devices will live for a long time.
|
| I recently had to setup a non-encrypted website because I have
| a few old devices that can no longer do HTTPS.
|
| IPv4 on local networks will probably exist for a very long
| time.
| dspillett wrote:
| _> I recently had to setup a non-encrypted website because I
| have a few old devices that can no longer do HTTPS._
|
| That sounds like they haven't been updated for TLS>1.1 - if
| that is the case then rather than going all the way down the
| HTTP you could enable TLS1.1 (and maybe 1.0). It is open to
| POODLE/BEAST/others that way, but still have _some_
| protection and the site 's configuration differs less from
| the rest of your infrastructure.
|
| Unless the site is completely internal only of course, in
| which case just sticking with HTTP may be less faf.
| tsimionescu wrote:
| Is there any way to get a certificate that these old
| devices would trust and that would work over TLS < 1.2?
| nelgaard wrote:
| No, that is the problem. They worked with less and less
| websites until there were none left. I needed to install
| some packages, which I could just put on my own server.
|
| And I have an old Blackberry Bold that now show current
| electricity prices, so I know when to starte my washing
| machine. That can also run on own webserver.
|
| https://gitlab.com/nelgaard/elpriser
| toast0 wrote:
| Technically the certificate issues are separate from the
| protocol versioning. It's just that clients that don't
| support TLS 1.2 often also don't support sha2
| certificates or may not have a path to validate
| certificates from currently available CAs (although you
| can usually push through that; no protocol support and no
| cert signature support is not a user bypass prompt)
|
| As a side note, barely anything supports TLS 1.1 but not
| TLS 1.2
| red_trumpet wrote:
| Small places?
|
| When I disabled IPv4 a few weeks ago, I couldn't use: HN,
| GitHub, Reddit, Discord, Duckduckgo.
| broeng wrote:
| _Almost_ sounds like a productivity enhancement.
| shapefrog wrote:
| Docker hub was the one that pushed me over the edge, so I
| just paid the extra 50c a month per server for ipv4 on cloud
| servers.
|
| Update - 23 Aug 2023 -- Today, we are pleased to announce the
| general availability of IPv6 support for the Docker Hub
| Registry
|
| Apparently it can be done now, I wont be finding out in a
| hurry.
| dehrmann wrote:
| I don't have IPv6 enabled. Literally everything works.
| roygbiv2 wrote:
| Also Android doesn't support DHCPv6
| piperswe wrote:
| What's the benefit of DHCPv6 over SLAAC (genuine question,
| never looked into DHCPv6 at all)
| sgjohnson wrote:
| all of the DHCP options, for example.
|
| SLAAC just tells the endpoint device to self-assign an
| address and to roll with it. For example, there's no way
| to pass in DNS servers with SLAAC.
| rnhmjoj wrote:
| The DNS bit it's not true: there's RFC8106 [1] for this
| and it's widely supported. You can set a list of DNS
| servers to use (RDNSS) and a domain suffix for resolving
| unqualified hostnames (DNSSL), exactly as for DHCP.
|
| [1]: https://datatracker.ietf.org/doc/html/rfc8106
| MayeulC wrote:
| Can't you provide DNS servers as part of router
| advertisement packets ? RFC8106
| sgjohnson wrote:
| I stand corrected, but I haven't seen this in practice
| yet.
| magicalhippo wrote:
| This requires client support though, which isn't a given.
| stephen_g wrote:
| I expect basically anything that supports SLAAC would
| have supported DNS advertisements for at least a few
| years...
| ArchOversight wrote:
| That is most operating systems and devices these days.
| throw0101a wrote:
| > _What 's the benefit of DHCPv6 over SLAAC (genuine
| question, never looked into DHCPv6 at all)_
|
| In corporate-y environments it allows for easier tracking
| of user-MAC-IP mappings for auditing purposes. If you use
| SLAAC there is no auto-logging as the client simply picks
| an address itself.
|
| One way to do tracking with SLAAC could be to SNMP
| scrape/trap ipNetToPhysicalTable of RFC 4293. Another
| would be 802.1X or MAC authentication (interim)
| accounting via RADIUS (RFC 2866).
| aidenn0 wrote:
| The primary advantage is you can delegate prefixes over
| DHCP, but that probably doesn't matter for most Android
| devices
|
| There are other advantages too, like if you want to
| assign specific addresses to specific devices without
| having to configure each device separately.
| chungy wrote:
| You can do finer-grained subnets with DHCP than SLAAC
| will give you.
| darkr wrote:
| As a general rule, if you're deploying IPv6 subnets sized
| as anything other than /64, you're doing it wrong
| chungy wrote:
| It's all too common for ISPs to give you just a single
| /64 going into your home.
|
| So if you want to define subnets within that, you're
| "doing it wrong"? Nah. Just use DHCPv6 and be happy.
| ArchOversight wrote:
| Name and shame the ISP! And update your DHCPv6 Prefix
| Delegation request for a larger prefix (try /60, that
| seems to be a common supported PD size for most at home
| ISPs).
| tsimionescu wrote:
| The only reason for that "rule" is SLAAC.
| p1mrx wrote:
| I think SLAAC's /64 limit functions as a "trojan horse"
| forcing ISPs to give everyone at least 64 bits of address
| space. Most would allocate /112-/128 per customer if it
| were slightly easier.
|
| Designing the internet with lots of unused space at the
| edges will probably be useful in 100 years.
| tsimionescu wrote:
| Regardless of the /64 limit, I expect DHCPv6 will win out
| in the consumer side (with ISPs giving customers pre-
| configured wifi routers with DHCPv6 already configured).
| SLAAC is both very complicated, and its privacy
| extensions are anyway not something ISPs have been
| friendly to even if it weren't such an extra hassle.
| p1mrx wrote:
| > and its privacy extensions are anyway not something
| ISPs have been friendly to
|
| That is an argument for forcing ISPs to support SLAAC, so
| it's difficult to bill a customer based on the number of
| devices in their home. ISP-friendly often means user-
| hostile.
|
| If ISPs can deploy device-counting DHCPv6, then router
| manufacturers will respond with IPv6 NAT, and then the
| IPv6 landscape will be as shitty as IPv4.
| tsimionescu wrote:
| Device counting has always been possible with IPv4
| routers, and yet I don't know of a single ISP which does
| this.
|
| To be clear, I'm talking of ISP-provided (usually wifi)
| routers, which at least in my country are extremely
| common. Those could receive an IPv6 prefix and do DHCPv6
| inside your own network.
| darkr wrote:
| Actually it's primarily due to NDP and EUI-64.
| Eliminating ARP is a very good thing for reasons of
| scalability, reliability and security.
| tsimionescu wrote:
| NDP doesn't impose any restrictions on IP addresses, it
| uses special prefixes anyway.
|
| EUI-64 is a part of SLAAC, not NDP.
|
| Finally, NDP is not really any more secure at least than
| ARP (at least not if you don't implement SEND as well,
| which I'm not sure if anyone does, at least in consumer
| networks). Not sure about reliability or scalability
| either.
| hkgjjgjfjfjfjf wrote:
| [dead]
| Dagger2 wrote:
| Those all work for me, on my v6-only desktop. (I don't use
| Discord, but their homepage loads at least.)
|
| None of those sites have v6 though, so you'll need some form
| of backwards compatibility running to reach them. Presumably
| you were missing that.
| simiones wrote:
| Instead of doing something like `export A="64:ff9b::"` and then
| using `ssh $A1.3.3.7`, it's apparently much easier to install a
| new software package and do `export LD_PRELOAD=/the/new/package`
| and hope it doesn't break anything...
| nelgaard wrote:
| the easiest would be to add to ~/.ssh/config:
|
| host *.*.*.*
|
| hostname 64:ff9:%h
|
| (without the empty line)
|
| Also work with scp, rsync,
___________________________________________________________________
(page generated 2023-10-04 23:02 UTC)