[admin@Ranume] > ping ipv6.google.com
invalid value for argument address
[admin@Ranume] >
[admin@Skhal] > ping ipv6.google.com
invalid value for argument address
[admin@Skhal] >
[admin@Jeekim] > ping ipv6.google.com
dns name exists, but no appropriate record
invalid value for argument ipv6-address
[admin@Jeekim] >
[ivo@haskaa ~]$ ping6 ipv6.google.com
PING ipv6.google.com(2a00:1450:8003::68) 56 data bytes
64 bytes from 2a00:1450:8003::68: icmp_seq=1 ttl=52 time=55.3 ms
64 bytes from 2a00:1450:8003::68: icmp_seq=2 ttl=52 time=53.4 ms
^C
--- ipv6.google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 53.486/54.393/55.301/0.936 ms
[ivo@haskaa ~]$
v5.11 and still the same situation. Why is is so difficult to get fixed/supported?Testing on 5.4 but not functional yet regular.
[admin@mikrotik] > :put [:resolve ipv6.google.com]
failure: dns name exists, but no appropriate record
on linux behind this MT resolv works good.
RouterOS 5.11 (c) 1999-2011
[admin@hs] > /ping [:resolve ipv6.google.com]
HOST SIZE TTL TIME STATUS
2a00:1450:8005::6a 56 49 73ms echo reply
2a00:1450:8005::6a 56 49 59ms echo reply
sent=2 received=2 packet-loss=0% min-rtt=59ms avg-rtt=66ms max-rtt=73ms
[admin@hs] > :put [:resolve ipv6.google.com]
2a00:1450:8005::6a
It's been almost ten months now, is this change any closer?So the change is coming.
It's been over eleven months now, is this change any closer?So the change is coming.
[admin@MikroTik] > ping ipv6.google.com
dns name exists, but no appropriate record
invalid value for argument ipv6-address
[admin@MikroTik] > ping 2a00:1450:4017:800::1012
HOST SIZE TTL TIME STATUS
2a00:1450:4017:800::1012 56 57 64ms echo reply
2a00:1450:4017:800::1012 56 57 64ms echo reply
2a00:1450:4017:800::1012 56 57 64ms echo reply
2a00:1450:4017:800::1012 56 57 66ms echo reply
sent=4 received=4 packet-loss=0% min-rtt=64ms avg-rtt=64ms max-rtt=66ms
/ping [:resolve ipv6.google.com]since workaround is pretty trivial
Then where definitely should be at least something like resolve6! Damn, two years is almost done since the promised feature....So in the mean time do this instead ... since workaround is pretty trivial
Not a resolve6, but the ping6.Then where definitely should be at least something like resolve6! Damn, two years is almost done since the promised feature....So in the mean time do this instead ... since workaround is pretty trivial
I was tired at work and was not attentive. Yes. The problem is confirmed.hm-m-m... I think, 8.8.8.8 is not very IPv6...
Not according to a dig I just did....[admin@MikroTik Router] > ping nextbigfuture.com
invalid value for argument address:
invalid value of mac-address, mac address required
invalid value for argument ipv6-address
failure: dns name exists, but no appropriate record
is this the same problem? anyone know if nextbigfuture.com is using an ipv6 address now?
;; QUESTION SECTION:
;nextbigfuture.com. IN A
;; ANSWER SECTION:
nextbigfuture.com. 1800 IN A 98.124.199.3 <----- only this A record, and no AAAA record
;; AUTHORITY SECTION:
nextbigfuture.com. 172800 IN NS dns5.name-services.com.
nextbigfuture.com. 172800 IN NS dns2.name-services.com.
nextbigfuture.com. 172800 IN NS dns4.name-services.com.
nextbigfuture.com. 172800 IN NS dns3.name-services.com.
nextbigfuture.com. 172800 IN NS dns1.name-services.com.
;; ADDITIONAL SECTION:
dns1.name-services.com. 152547 IN A 98.124.192.1
dns2.name-services.com. 152547 IN A 98.124.197.1
dns3.name-services.com. 152547 IN A 98.124.193.1
dns4.name-services.com. 152547 IN A 98.124.194.1
dns5.name-services.com. 152547 IN A 98.124.196.1
[rtradmin@core] > /ping ipv6.google.com
invalid value for argument address:
invalid value of mac-address, mac address required
invalid value for argument ipv6-address
failure: dns name exists, but no appropriate record
Is winter coming also? Seriously, getaddrinfo migration takes this long?Devs want to address this in general manner not hacking each place with domain separately. So the change is coming.
Thanks for the clarification, sadly it's not an IPv4 vs IPv6 preference issue. You simply cannot ping an IPv6 only host. Try the record ipv6.google.com on a PC and then try it from a MikroTik router.This is not getaddrinfo in this case. This is set in RouterOS and, currently, it is not going to be changed to return IPv6 address first and IPv4 after that, but will return IPv4 address if available.There is no information when this will be changed to conform with the RFC to return IPv6 address if usable and then IPv4.
PS C:\> Resolve-DnsName -Server 8.8.8.8 -Name ipv6.google.com -Type A
Name Type TTL Section NameHost
---- ---- --- ------- --------
ipv6.google.com CNAME 86399 Answer ipv6.l.google.com
Name : l.google.com
QueryType : SOA
TTL : 59
Section : Authority
NameAdministrator : dns-admin.google.com
SerialNumber : 160439217
TimeToZoneRefresh : 900
TimeToZoneFailureRetry : 900
TimeToExpiration : 1800
DefaultTTL : 60
PS C:\> Resolve-DnsName -Server 8.8.8.8 -Name ipv6.google.com -Type AAAA
Name Type TTL Section NameHost
---- ---- --- ------- --------
ipv6.google.com CNAME 86394 Answer ipv6.l.google.com
Name : ipv6.l.google.com
QueryType : AAAA
TTL : 299
Section : Answer
IP6Address : 2607:f8b0:4009:811::200e
[admin@rtr1] > ping count=2 ipv6.google.com
invalid value for argument address:
invalid value of mac-address, mac address required
invalid value for argument ipv6-address
failure: dns name exists, but no appropriate record
the problem will go away when IPv6 is set as a preferred option for the :resolve command and elsewhere where RouterOS attempts to resolve a hostname to IP address. When forced the :resolve command is returning the IPv6 address, hence the workaround of /ping [:resolve ipv6.only.domain] is working.
This workaround is a definitive solution?
the problem will go away when IPv6 is set as a preferred option for the :resolve command and elsewhere where RouterOS attempts to resolve a hostname to IP address. When forced the :resolve command is returning the IPv6 address, hence the workaround of /ping [:resolve ipv6.only.domain] is working.
RouterOS 6.43.7 on all devices.
I have exactly the same problem with Mikrotik unable to resolve AAAA records from a hostname.
My test Mikrotik LtAP device gets CGNAT protected private IPv4 address of 100.64.0.0/18 from the mobile operator. There is no inbound access to that.
The same Mikrotik LtAP device gets dynamic and changing IPv6 address address and IPv6 prefix, which is nice. That IPv6 address is accessible from the Internet.
The "/ip cloud" DDNS hostname now has both A and AAAA records, which is nice. The X.sn.mynetname.net gets updated with the CGNAT external A-record and the native IPv6 address. Nice.
When I am on Mikrotik CLI elsewhere in the world, there is no way to use IPv6 when saying "/system ssh 123456789.sn.mynetname.net".
One of the listed "solutions" 6 years ago was " /ping [resolve ipv6.google.com]" . That only works when the hostname has only the AAAA record, but no A record.
The X.sn.mynetname,net addresses have both A and AAAA records. And again, Mikrotik will only resolve to a lonely A record, if that is available. Another example of the same thing is when user says "/ping [:resolve google.com]", resolving allways to IPv4-only. "google.com" hostname has the AAAA record, Mikrotik is never bothered to ask that, ever.
Even when the Mikrotik DNS cache has the target hostname and its AAAA record already known and cached (and no A record cached), Mikrotik resolver will still A-record query the outside DNS resolvers, and force using the A record for everything. Not good.
This seems to be really unwanted issue to fix in Mikrotik.
For the easiest solution, could Mikrotik implement a new ":resolve" function with name of ":resolve6"? That ":resolve6" will only query AAAA recods (and follow CNAMES of course). A matching ":resolve4" would be important to have too, forcing query of the plain A records (and following the CNAMEs). And still now, the funny plain stupid-vanilla ":resolve" thingie can stay as it is and as it wants to [not]work.
This suggestion does not break anything, all systems and scripts will work exactly as before. Now the users who have to use hostnames and forcing IPv6 addresses, can say "/ping [:resolve6 google.com]" and get the functionality and results they need.
They are looking for another thinks like KidControlRouterOS 6.43.7 on all devices.
I have exactly the same problem with Mikrotik unable to resolve AAAA records from a hostname.
My test Mikrotik LtAP device gets CGNAT protected private IPv4 address of 100.64.0.0/18 from the mobile operator. There is no inbound access to that.
The same Mikrotik LtAP device gets dynamic and changing IPv6 address address and IPv6 prefix, which is nice. That IPv6 address is accessible from the Internet.
The "/ip cloud" DDNS hostname now has both A and AAAA records, which is nice. The X.sn.mynetname.net gets updated with the CGNAT external A-record and the native IPv6 address. Nice.
When I am on Mikrotik CLI elsewhere in the world, there is no way to use IPv6 when saying "/system ssh 123456789.sn.mynetname.net".
One of the listed "solutions" 6 years ago was " /ping [resolve ipv6.google.com]" . That only works when the hostname has only the AAAA record, but no A record.
The X.sn.mynetname,net addresses have both A and AAAA records. And again, Mikrotik will only resolve to a lonely A record, if that is available. Another example of the same thing is when user says "/ping [:resolve google.com]", resolving allways to IPv4-only. "google.com" hostname has the AAAA record, Mikrotik is never bothered to ask that, ever.
Even when the Mikrotik DNS cache has the target hostname and its AAAA record already known and cached (and no A record cached), Mikrotik resolver will still A-record query the outside DNS resolvers, and force using the A record for everything. Not good.
This seems to be really unwanted issue to fix in Mikrotik.
For the easiest solution, could Mikrotik implement a new ":resolve" function with name of ":resolve6"? That ":resolve6" will only query AAAA recods (and follow CNAMES of course). A matching ":resolve4" would be important to have too, forcing query of the plain A records (and following the CNAMEs). And still now, the funny plain stupid-vanilla ":resolve" thingie can stay as it is and as it wants to [not]work.
This suggestion does not break anything, all systems and scripts will work exactly as before. Now the users who have to use hostnames and forcing IPv6 addresses, can say "/ping [:resolve6 google.com]" and get the functionality and results they need.
Regardless of workarounds MikroTik's apathetic approach to IPv6 lost MikroTik 2 full network refreshes on my side in December alone to Ubiquiti. At least they demonstrated that they are capable of developing IPv6 related features.
KidControl doesn’t work with IPv6
1. Continue the default behavior to only return one record, but provide an option full-answer=true|false to return the full answer.
The :resolve command is used for both debugging and scripting purposes and this change benefits both purposes. Since RouterOS has DNS server functionality, it's always frustrating to debug DNS-related issues when the router itself doesn't have a good DNS client. Currently, the only recourse is to use dig or nslookup from a client device and then inspect :ip dns cache on the router to see what happened. From a scripting perspective, it would be nice to be given all of the answers for a query for round-robin connections, health checks, etc.
2. Provide an option in :ip dns called client-behavior: prefer-v4|dual-stack
prefer-v4 preserves the legacy behavior and will return A record(s) if both A and AAAA are available. Since some users are undoubtedly relying on this quirk, this can remain the RouterOS default for several versions to give them time to migrate.
dual-stack follows RFC 8305 and attempts dual-stack resolution like a standard DNS client. If both address families are present and RouterOS has a configured IPv6 address it can use as a source, the AAAA record(s) are returned. After a sufficient amount of time, this should become the RouterOS default.
The fact that RouterOS unconditionally prefers IPv4 makes it ill-suited as a modern dual-stack client. I don't fully understand why the choice was made in the first place. Although not in my ask here (because of the amount of work that would be involved), I do hope that RouterOS 7 has a proper RFC-8305-compliant control plane for any connections the router makes.
Yes! ((Is this really still an issue?
Is MikroTik still not IPv6 ready?
routeros can't get nor prefix nor address via slaac... and therefore cant show itUff.
Do you guys know a way to display / show the current SLAAC IPv6 address?
I say'd about absent address because i can't found it anywhere... but agree - SLAAC (address) work, and address i found only in /tool quick sniff...Wrong, RouterOS can get address using SLAAC (/ipv6 settings set accept-router-advertisements=no/yes/yes-if-forwarding-disabled) and it currently doesn't show it anywhere. You can e.g. ping something and see it using Tools->Torch or logging rules.
I try'ed - it really work! - ddns work via ipv6 only connected router.I didn't try it, but maybe even DDNS would update hostname with it.
1 0.000000 2001:my_ip_address 2001:4860:4860::8888 DNS 142 Standard query 0x5da3 A ipv6.google.com
2 0.062202 2001:4860:4860::8888 2001:my_ip_address DNS 213 Standard query response 0x5da3 A ipv6.google.com CNAME ipv6.l.google.com SOA ns1.google.com
3 3.582657 2001:my_ip_address 2001:4860:4860::8888 DNS 142 Standard query 0x0f09 A ipv6.google.com
4 3.685863 2001:4860:4860::8888 2001:my_ip_address DNS 213 Standard query response 0x0f09 A ipv6.google.com CNAME ipv6.l.google.com SOA ns1.google.com
5 3.686434 2001:my_ip_address 2001:4860:4860::8888 DNS 144 Standard query 0x3dd9 AAAA ipv6.l.google.com
6 3.770671 2001:4860:4860::8888 2001:my_ip_address DNS 172 Standard query response 0x3dd9 AAAA ipv6.l.google.com AAAA 2a00:1450:4014:80e::200e
[user@MikroTik-RO] > ping ipv6.google.com
invalid value for argument address:
invalid value of mac-address, mac address required
invalid value for argument ipv6-address
failure: dns name exists, but no appropriate record
[user@MikroTik-RO] > ping [:resolve ipv6.google.com]
SEQ HOST SIZE TTL TIME STATUS
0 2a00:1450:4001:82a::200e 56 114 18ms794us echo reply
1 2a00:1450:4001:82a::200e 56 114 17ms54us echo reply
2 2a00:1450:4001:82a::200e 56 114 14ms693us echo reply
sent=3 received=3 packet-loss=0% min-rtt=14ms693us avg-rtt=16ms847us max-rtt=18ms794us