Version Agnostic Services and IPv6 Gaps

What it is

Some RouterOS services work over either IP version without separate configuration, and a few features still work only over IPv4.

A version agnostic service is configured once and accepts both IPv4 and IPv6. You do not repeat its settings in an IPv6 menu. Such a service is found under the /ip menu even when it answers IPv6 clients.

The opposite case is a feature with no IPv6 support. For those you need a plan, because the feature will not serve IPv6 clients.

How it works

You learn which services are agnostic, then check what is missing for the features you need.

Services that handle both versions

The main examples are listed below.

DNS

The DNS service is one of the most important, because IPv6 addresses are long and are used through names. You configure it once under /ip dns.

/ip dns set servers=2001:db8:53::1 allow-remote-requests=yes
/ip dns static add name=server1.example.com type=AAAA address=2001:db8:1::10

The first command points the resolver at an IPv6 server. The second adds a static AAAA record. A DNS server can carry A and AAAA records over either transport, so the transport and the record type are independent.

If the router answers DNS queries for the LAN, the IPv6 firewall must allow the queries to reach it. The firewall is the part that is not shared, even when the service is.

Reverse DNS

A reverse lookup maps an IPv6 address back to a name. The address is written as 32 hex digits (nibbles) in reverse order, with a dot between each, under ip6.arpa. The record type is PTR.

The address 2001:db8:1::10 becomes:

0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

Your ISP normally delegates the reverse zone for your prefix, for example 1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa for 2001:db8:1::/48, to a DNS server you choose. PTR records go in that zone. Check whether the static table of your RouterOS version accepts PTR records before relying on it.

Management services

The services that you use to reach the router listen on IPv6 too. The /ip service menu controls which services are enabled and which source addresses may use them.

/ip service print
/ip service set ssh address=2001:db8:ff::/64

The address setting limits the sources that may connect. A list that holds only IPv4 prefixes does not admit IPv6 clients, so add an IPv6 prefix where IPv6 access is wanted, and check that your release accepts IPv6 prefixes there. The IPv6 firewall input chain gives a second layer of control.

NTP

Time synchronisation is another agnostic service. In RouterOS v7 the client takes IPv6 addresses or names in servers. A name works over IPv6 only if it resolves to an AAAA record.

/system ntp client set enabled=yes servers=2001:db8:123::123

If the router serves time to the LAN, enable /system ntp server and allow UDP port 123 in the IPv6 firewall input chain.

/ipv6 firewall filter add chain=input protocol=udp dst-port=123 action=accept

On RouterOS v6 the client menu uses primary-ntp and secondary-ntp, so check what address types your release accepts.

A rule for agnostic services

The service is shared, but the firewall and the addresses are not. Two things need checking for each service:

• The service must be enabled and its address limits must include the IPv6 clients.
• The IPv6 firewall must accept the traffic in the input or forward chain.

Features that are not available for IPv6

Some RouterOS features have lacked IPv6 support. The list changes with each release, so treat any list as a snapshot and check the documentation for your version.

Examples commonly listed as IPv4 only on RouterOS v6 are:

NAT is a related case. IPv6 gives every host a global address, so masquerade is rarely needed.

Some features exist for IPv6 but with fewer options than the IPv4 version. Compare the /ipv6 menu with its /ip counterpart to find the differences.

The Module 6 outline names more IPv4 only features:

• RADIUS integration: the RADIUS client of that era had only an IPv4 server address, so authentication and accounting could not run to an IPv6 server. Keep an IPv4 path to the RADIUS server in a dual stack design, and check your release.
• Policy routing: IPv6 had no routing marks or routing rules in that era, so traffic could not be steered by source or by a mangle mark. Use ordinary routes chosen by destination, or do the policy on a device that supports it. Check whether your release adds IPv6 mangle and rules.

How to check and plan around a gap

To find out if a feature supports IPv6:

1. Look for the feature under the /ipv6 menu.
2. Read the documentation for the exact RouterOS version in use.
3. Test the feature with an IPv6 client in a lab.

If a feature has no IPv6 support, there are three common plans.

Keep IPv4 running for that function and use dual stack. Place the function on another device that supports it. Or wait for a release that adds support.