Multihomed ipv6 host

Suppose, we have two 6to4 tunnels to different tunnel brokers with different prefixes on the bridge interface. Two static 2000::/3 routes to each tunnel. In Mikrotik v6 we have no ipv6 NAT. But we can adjust a preferred-lifetime property of these prefixes to a little value. May be 1min or what you want. When the prefix become disabled a corresponding host ipv6 address could not make new connection. Script:

:local prefix1 2xxx:xxxx:xxxx:xxxx::/64;
:local prefix2 2axx:xxxx:xxxx:xxxx ::/64;
:local int1 sit1;
:local int2 sit2;

:if ([/interface 6to4 find  where running and name=$int1])
  do={/ipv6 nd prefix enable [find prefix=$prefix1];/ipv6 nd prefix disable [find prefix=$prefix2]}
else={:if ([/interface 6to4 find  where running and name=$int2])
  do={/ipv6 nd prefix disable [find prefix=$prefix1];/ipv6 nd prefix enable [find prefix=$prefix2]}}

But still some questions about Mikrotik 6to4 interface running state. How adequate is this property?
And btw ipv6 NAT would be better in this case.

Do you enable the “Check Gateway” (ping) feature of your 2000::/3 routes? Do you think you can check the presence of a route in your script, instead of interface state?

Yes, it’s enabled. Presence of a route is a very connected thing with the interface state, as far as I tried it in the Mikrotik. I enable and disable and vise versa an ipv4 address of the tunnel far end by IP Firewall. No clear for me why and when interface state is changed. With Hurricane Electric tunnel enabling option keep alive works better (not ideal so), but with the other provider this option turns tunnel into the not running state.

Have you been able to figure out how the keepalive feature on sit* interfaces works under the hood? The 6in4 protocol (RFC4213) does not seem to define any keepalive mechanisms.

I can only guess. I think the same like in IPIP tunnel: “Tunnel keepalive parameter sets the time interval in which the tunnel running flag will remain even if the remote end of tunnel goes down. If configured time,retries fail, interface running flag is removed. Parameters are written in following format: KeepaliveInterval,KeepaliveRetries where KeepaliveInterval is time interval and KeepaliveRetries - number of retry attempts. By default keepalive is set to 10 seconds and 10 retries.”
https://wiki.mikrotik.com/wiki/Manual:Interface/IPIP

But when it’s enabled with NTS ISP the 6to4 tunnel state turns to not running.

I have read this page already. It does not specify what kind of keepalive packets the MikroTik is sending/expecting to/from the remote side.

It’s probably because NTS does not respond to MikroTik’s keepalives whatever they are? Or does not respond in the way MikroTik expects.

Hi, just a side note - shortening IPv6 prefix preferred/valid lifetime to a very short value can be a problem on a wifi. IPv6 Router advertisements are send as multicast and they are easily lost, especially when clients use power save feature (on linux you can check with iw dev wlan0 get power_save). Then you can get issues on clients with IPv6, because preferred lifetime expire (and are not refreshed because of lost Router advertisement messages).
However, if you are on wired Ethernet, you should be safe.

Ok. I do this solution for a home network. Two, not so critical, 6to4 tunnels. I adjusted 10 min preferred lifetime. Win 10 Laptop works normal via Wifi with this time. For production networks I would be prefer IPv6-to-IPv6 Network Prefix Translation.

For production networks I would prefer BGP in this case.

Do you mean to obtain Provider Independent ip v6 addresses and AS?

I do. I don’t know however if it has become easier or harder to obtain a PI block as compared to IPv4. If you have to become a LIR to get your own block of addresses (de facto the only way in the IPv4 world), it’s not a feasible way for small companies.

Mikrotik keepalive packets:
sit1.png

OMG, what is it? Can you please expand the IPv6 header?

Only nulls. And I didn’t find any replies.
ipv6.png

Very odd. Who will reply to such packets? There should be a “Next Header” and some other important fields.

Some times the HE tunnel falls into not running state too, with keep alive enabled. But in most time HE is running with keep alive enabled unlike the NTS case. So, somehow it works. We can dig it deeper. But I don’t see a reason.

An official comment from the MikroTik team is due here. What kind of packets they use as keepalive, why, what RFC it is, or is it something proprietary etc etc. I agree that there is no use guessing but it would be good to have first hand knowledge.