How to use fetch tool with IPv6

I’m solving a problem with the fetch tool. I am trying to send a request using the POST method to an HTTPS address that has both A and AAAA records on the DNS servers. For example:

/tool fetch url="https://api.wedos.com/" http-method=post http-data="{\"request\":{\"command\":\"ping\"}}" output=user-with-headers as-value]

Unfortunately, fetch is trying to connect over IPv4. How do I force fetch to connect over IPv6?

+1, I would like to know too

Have you tried setting the src-address?

@Radek01: The short answer is: you can’t.

The reason is that ROS unfortunately lacks capabilities to control the dual-stack for embedded tools and services such as IPsec, WireGuard, DNS, IP Cloud, resolver, fetch, etc.

{
/ipv6 firewall address-list
add address=api.myip.com list=api.myip.com
:delay 2s
:local ipv6add ([/ipv6 firewall address-list print as-value where comment=“api.myip.com”]->0->“address”)
:set ipv6add [:pick $ipv6add 0 [:find $ipv6add “/” -1] ]
:put [/tool fetch host=api.myip.com url=“https://api.myip.com/index.php” output=user as-value]
:put [/tool fetch host=api.myip.com url=“https://$ipv6add/index.php” output=user as-value]
remove [find where address=api.myip.com and list=api.myip.com]
}

Yeah, that’s likely a functional but ugly workaround for a flawed dual-stack management. Let’s hope MT will fix this eventually.

It was just meant to be a temporary solution…
Like the others that I have proposed over time and it took years to integrate them into RouterOS…

Thank you all for your replies. Unfortunately, I’m not pleased. I hope Mikrotik will fix it soon.

I use RouterOS 7.14 and following row gives this error message “failure: Conflicting hostnames provided in URI and parameter”:

:put [/tool fetch host=api.myip.com url="https://$ipv6add/index.php" output=user as-value]

Try with

:put [/tool fetch url="http://$ipv6add/index.php" http-header-field="Host:api.myip.com" output=user as-value]

Note: use http protocol, https requires (E)SNI host name which is not set from URL when accesing over IP and SSL handshake will fail since certificate is not issued for IP. Also this will not work on web services which redirects http to https but api.myip.com is not doing that, unfortunately api.wedos.com (from OP) does and this trick cannot be used on that host.

Exactly as you wrote, unusable for api.wedos.com because it also redirects to https. Thanks for the info.