Unreachable IPv6 ping from localhost

diasdm · Tue Mar 19, 2024 4:34 am

From my HAP AX3, when I try to ping an IPv6 only domain, it seems the router cannot reach the target.

[@MikroTik] > ping [:resolve checkipv6.dedyn.io]
  SEQ HOST                                     SIZE TTL TIME       STATUS
    0 2a01:4f8:10a:1044:deec:642:ac10:80                           timeout
    1 2a01:4f8:10a:1044:deec:642:ac10:80                           timeout
    2 2a01:4f8:10a:1044:deec:642:ac10:80                           timeout
    3 2804::pub:ipv6  					    	104  64 89ms653us  address unreachable

I thought it was a firewall rule, but it is accepting ICMP packets.

[@MikroTik] > ipv6/firewall/filter/print
 2    ;;; defconf: accept ICMPv6
      chain=input action=accept protocol=icmpv6 log=no log-prefix=""

Clients are capable of pinging the IPv6 domain with no issues.

PS > ping checkipv6.dedyn.io
Answer from 2a01:4f8:10a:1044:deec:642:ac10:80: time=238ms
Answer from 2a01:4f8:10a:1044:deec:642:ac10:80: time=238ms
Answer from 2a01:4f8:10a:1044:deec:642:ac10:80: time=238ms
Answer from 2a01:4f8:10a:1044:deec:642:ac10:80: time=239ms

I can't find the problem. Any idea of why IPv6 pings are not reachable from the router itself?

diasdm · Tue Apr 23, 2024 2:45 am

It is receiving a public IPv6.

[@MikroTik] > ipv6/dhcp-client/export
/ipv6 dhcp-client
add add-default-route=yes interface=ether1_WAN pool-name=WAN_IPv6_Pool request=address use-peer-dns=no

[@MikroTik] > ipv6/dhcp-client/print
# INTERFACE   STATUS  REQUEST  ADDRESS
0 ether1_WAN  bound   address  2804:X:X:X:X:X:X:X, 23h59m57s

It appears that the default route is set accordingly.

[@MikroTik] > ipv6/route/print
    DST-ADDRESS               GATEWAY      DISTANCE
DAd ::/0                      ether1_WAN          1
DAc ::1/128                   lo                  0
DAc 2804:X:X:X:X:X:X:X/128    ether1_WAN          0
DAc fd08:192:168:8::/64       bridge_LAN          0
DAc fd09:192:168:9::/64       bridge_WiFi         0
DAc fe80::%ether1_WAN/64      ether1_WAN          0
DAc fe80::%bridge_LAN/64      bridge_LAN          0
DAc fe80::%bridge_WiFi/64     bridge_WiFi         0

However, when I try to ping any remote IPv6 address, it is unreachable.

[@MikroTik] [ping]> ping 2800:3f0:4004:803::200e
  SEQ HOST                                     SIZE TTL TIME       STATUS
    0 2800:3f0:4004:803::200e                                      timeout
    1 2800:3f0:4004:803::200e                                      timeout
    2 2800:3f0:4004:803::200e                                      timeout
    3 2804:X:X:X:X:X:X:X                        104  64 80ms661us  address unreachable
    4 2800:3f0:4004:803::200e                                      timeout
    5 2800:3f0:4004:803::200e                                      timeout
    sent=6 received=0 packet-loss=100%

I have not found any firewall rule that might be dropping IPv6 packets.

[@MikroTik] > ipv6/firewall/filter/export
/ipv6 firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMPv6" protocol=icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" port=33434-33534 protocol=udp
add action=accept chain=input comment="defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=udp src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=ipsec-esp
add action=accept chain=input comment="defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=input comment="defconf: drop everything else not coming from LAN" in-interface-list=LAN
add action=accept chain=forward comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=icmpv6
add action=accept chain=forward comment="defconf: accept HIP" protocol=139
add action=accept chain=forward comment="defconf: accept IKE" dst-port=500,4500 protocol=udp
add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=ipsec-ah
add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=ipsec-esp
add action=accept chain=forward comment="defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=forward comment="defconf: drop everything else not coming from LAN" in-interface-list=!LAN

Any thoughts on this matter?

mkx · Tue Apr 23, 2024 9:18 am

You're doing IPv6 addressing wrong. Your router doesn't really need GUA (global) address on WAN port. However you do need a prefix to make enabling IPv6 on your LAN subnets possible. So instead of your DHCPv6 client config you should use something like this:

/ipv6/dhcp-client
add interface=ether1_WAN pool-name=WAN_IPv6_Pool request=prefix use-peer-dns=no pool-prefix-length=64 prefix-hint=::/56
/ipv6/address
add address=::1 from-pool=WAN_IPv6_Pool  interface=bridge_LAN
add address=::1 from-pool=WAN_IPv6_Pool  interface=bridge_WiFi

(note: the construct "address= from-pool=" will come up with different addresses for different interfaces, pool will hand out different addresses each time it's asked even though the construct looks like it'll end up with same IPv6 address)

Next: routing info in IPv6 is supposed to be derived from Router Advertisements (RAs). The DHCPv6 client option add-default-route=yes is MT's work around and tries to set default route to DHCPv6 server's IPV6 address (or, as seen in your case, to interface ... which is wrong for point-to-multipoint interfaces). So instead you should configure your router like this:

/ipv6 settings
set accept-router-advertisements=yes

This should make your router to receive RAs from your ISP ...

diasdm · Thu Apr 25, 2024 4:32 am

After some testing, I've realized that the IPv6 default route wasn't set up properly.
The default gateway should be set dynamically by the DHCP client for the WAN interface.

The "add-default-route" option is set to "yes", but the route was not being added after a reboot.
By simply re-enabling the DHCP client, the dynamic default gateway was set up as the ISP's next-hop link-local.

[@MikroTik] [rout]> ipv6/route/print
    DST-ADDRESS        GATEWAY                              DISTANCE
DAd ::/0               fe80::662:73ff:fee4:a419%ether1_WAN         1

The "accept-router-advertisements=yes" option did not solve the issue, so I returned it to its default.
Then, I changed the request option for the DHCP client: "request=address,prefix", and, finally, the correct default route was added.
That seems to solve the problem.

But the question remains...
Even when the "add-default-route" option is set to "yes", why would the DHCP client not add the correct IPv6 default route if it only requests an address and not a prefix?

mkx · Thu Apr 25, 2024 11:24 pm

Even when the "add-default-route" option is set to "yes", why would the DHCP client not add the correct IPv6 default route if it only requests an address and not a prefix?

Because DHCPv6 protocol doesn't support passing routing information to client. And it doesn't matter if client requests address or prefix.

So whatever ROS does when add-default-route is enabled is just guess-work by ROS since whatever it comes up with is not configured by ISP. ROS may guess correctly but it may also fail miserably.

There's another thing to it: upstream router eventually has to know where to forward traffic for delegated prefix. And that info is only available from DHCPv6 server. Client's WAN IPv6 address can be ULA (which is constructed from interface's MAC address and that is information which DHCPv6 server does know because it's needed for unicast communication, used in later stages of DHCPv6 handshake). Client's WAN IPv6 address can also be GUA (for routing that's technically not required) and if DHCPv6 client requests both address and prefix in single handshake, then DHCPv6 server can hand out both at the same time and are thus linked to the same device.

Note that this part only makes possible to properly route packets in direction from internet towards client LAN. To route traffic in the opposite direction, client gateway has to know what should be next hop. As I already wrote, this information is available from RAs (but reception of them has to be enabled). But one can also set the before mentioned DHCPv6 client option and ROS then sets default gateway to address of DHCPv6 server. It seems that MT is not the only vendor to do it, so many ISPs somehow tolerate such misuse of their DHCPv6 server. If clients accept at least ICMPv6 Neighbor Redirect messages, then the poor DHCPv6 servers are not hammered too much by misdirected traffic.

diasdm · Fri Apr 26, 2024 1:14 am

To route traffic in the opposite direction, client gateway has to know what should be next hop. As I already wrote, this information is available from RAs (but reception of them has to be enabled).

Because DHCPv6 protocol doesn't support passing routing information to client. And it doesn't matter if client requests address or prefix.
So whatever ROS does when add-default-route is enabled is just guess-work by ROS since whatever it comes up with is not configured by ISP. ROS may guess correctly but it may also fail miserably.

So, you're saying that the "add-default-route" option doesn't matter. ROS takes the DHCPv6 info and just guesses the gateway from the DHCPv6 server.
RA is the one that provides the next-hop information. Right?
Still, after a reboot, it will only add a proper default route if the DHCPv6 request has the "prefix" option set.

As I understand it, the IPv6 settings are set not to accept RAs since "forward" is set to "yes".

[@MikroTik] > ipv6/settings/print 
                  disable-ipv6: no
                       forward: yes
              accept-redirects: yes-if-forwarding-disabled
  accept-router-advertisements: yes-if-forwarding-disabled
          max-neighbor-entries: 14336

However, if I go back to my initial configuration where "request=address", and set "accept-router-advertisements=yes", ROS does not add the correct default route after a reboot.

and if DHCPv6 client requests both address and prefix in single handshake, then DHCPv6 server can hand out both at the same time and are thus linked to the same device.

Yes, I guess that is what I ended up doing with "request=address,prefix".

diasdm · Fri Apr 26, 2024 2:06 am

After all this testing, I settled on these options:

IPv6 DHCP client - "add-default-route=yes" and "request=address,prefix"
IPv6 Settings - "accept-router-advertisements: yes"

[@MikroTik] [prin]> ipv6/route/print
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, d - DHCP, g - SLAAC; + - ECMP
     DST-ADDRESS               GATEWAY                              DISTANCE
DAd+ ::/0                      fe80::662:73ff:fee4:a419%ether1_WAN         1
DAg+ ::/0                      fe80::662:73ff:fee4:a419%ether1_WAN         1
DAc  ::1/128                   lo                                          0
DAc  2804:pub:prefix::/64      ether1_WAN                                  0
DAc  2804:pub:add/128          ether1_WAN                                  0
DAc  fd08:192:168:8::/64       bridge_LAN                                  0
DAc  fd09:192:168:9::/64       bridge_WiFi                                 0
DAc  fe80::%ether1_WAN/64      ether1_WAN                                  0
DAc  fe80::%bridge_LAN/64      bridge_LAN                                  0
DAc  fe80::%bridge_WiFi/64     bridge_WiFi                                 0

This way we see that there is a SLAAC (g) and a DHCP (d) route, which are identical.
Only when the the DHCP route is set with the next-hop does the routing actually work.

mkx · Fri Apr 26, 2024 8:20 am

This way we see that there is a SLAAC (g) and a DHCP (d) route, which are identical.
Only when the the DHCP route is set with the next-hop does the routing actually work.

IMO when having two identical routes, either should work (and flags don't matter, they are metadata not routing information). It's good to see that "DHCPv6 client default route mock-up" ends up with correct setting in your case. So, if using that DHCPv6 client option works for you, keep on using it.

There's another thing to be aware of: RAs are in principle broadcast "occasionally", and time interval between occurrences can be minutes. Device can, when getting interface UP, ask for RA to be sent (out of usual intervals) to get necessary information sooner. But if it doesn't (or if router ignores request), then it can take a while before IPv6 connectivity gets established. So when configuring IPv6 things, sometimes one has to wait a while to see, if settings have any effect or not.

Unreachable IPv6 ping from localhost

Unreachable IPv6 ping from localhost

Re: Unreachable IPv6 ping from localhost

Re: Unreachable IPv6 ping from localhost

Re: Unreachable IPv6 ping from localhost

Re: Unreachable IPv6 ping from localhost

Re: Unreachable IPv6 ping from localhost

Re: Unreachable IPv6 ping from localhost

Re: Unreachable IPv6 ping from localhost

Who is online