I would like to put more information into the IPv6 router advertisement packets: several DNS servers (and especially the IP of the router itself) into the rdnss field, several domain names into the dnssl field etc. Where do I edit and add those fields?

Currently you can't, it's not much configurable yet. DNS servers are simply taken from "/ip dns", but you don't want to add router's own address there.

You can combine it with DHCPv6. If you add server without pool, it will function in stateless mode and only provide info (you'll have to enable "Other Configuration" in "/ipv6 nd" for clients to use it). There you can add any option you like.

7.1beta has support for DNS in RA, until then use DHCPv6 option 23

You can combine it with DHCPv6. If you add server without pool, it will function in stateless mode and only provide info (you'll have to enable "Other Configuration" in "/ipv6 nd" for clients to use it). There you can add any option you like.

Can you kindly provide an example, with 2 DNS servers?

@vas: viewtopic.php?p=831091#p831091

DNS servers are simply taken from "/ip dns", but you don't want to add router's own address there.

Sure I don't want to, but putting the router's own IPv6 address into router advertisements (if a DNS server is enabled on the router of course) would be a good idea, don't you think?

@vas: viewtopic.php?p=831091#p831091

Can I both have DHCPv6 server enabled and keep advertise-dns=yes in "/ipv6 nd"? Is this a supported configuration?

RouterOS does it a bit odd.

If "Advertise DNS" flag is enabled in ND, it will advertise all/any IPv6 addresses set in the IP>DNS fields, whereby the client devices would directly be communicating with said addresses bypassing RouterOS's stub resolver completely. If the flag is disabled, the client devices will end up using the stub resolver on RouterOS.

You can confirm this with connection tracking, packet sniffing etc. Or simply look for "IPv6 DNS" in your client devices.

If the "Advertise DNS" flag is disabled, the client devices will end up using the stub resolver on RouterOS.

How would they know to use it?

If the "Advertise DNS" flag is disabled, the client devices will end up using the stub resolver on RouterOS.

How would they know to use it?

What do you mean "how"? If the flag is disabled, client devices will automatically fall back to the IPv4 DNS address that was originally advertised with DHCP, so that would be the Router's IP address unless you use PiHole like I do or some other DNSSinkhole.

Flag enabled = Direct IPv6 to IPv6 (public internet) for the DNS queries based on any/all IPv6 addresses inside IP>DNS.
Flag disabled = fallback to native IPv4 DNS "server" which can be the router's IP or some other public or local IPv4 address that you've configured on IP>DNS/IP>DHCP Server.

If the "Advertise DNS" flag is disabled, the client devices will end up using the stub resolver on RouterOS.

How would they know to use it?

What do you mean "how"? If the flag is disabled, client devices will automatically fall back to the IPv4 DNS address that was originally advertised with DHCP [...]

Ah, I thought you meant "will end up using the stub resolver on RouterOS over IPv6", so I was surprised how they would learn it.

If the "Advertise DNS" flag is disabled, the client devices will end up using the stub resolver on RouterOS.

How would they know to use it?

What do you mean "how"? If the flag is disabled, client devices will automatically fall back to the IPv4 DNS address that was originally advertised with DHCP [...]

Ah, I thought you meant "will end up using the stub resolver on RouterOS over IPv6", so I was surprised how they would learn it.

I see.

Yeah, so really, there is no problem with RouterOS's approach to IPv6 DNS, you can use the stub resolver, or you can use direct public resolvers on a per-client basis or even like I do... Simply re-direct to a DNSSinkhole and use a custom stub resolver/DNS forwarded/recursive DNS server.

Yeah, so really, there is no problem with RouterOS's approach to IPv6 DNS, you can use the stub resolver, or you can use direct public resolvers on a per-client basis

Well, if the clients are IPv6 only, there will be no fallback to IPv4 DNS for them.

or even like I do... Simply re-direct to a DNSSinkhole and use a custom stub resolver/DNS forwarded/recursive DNS server.

I hate the practice of intercepting or modifying clients' DNS traffic. It's basically an attack. I hope this practice will die off naturally as soon as more domains and hosts adopt DNSSEC (or DoH, whichever first).

Yeah, so really, there is no problem with RouterOS's approach to IPv6 DNS, you can use the stub resolver, or you can use direct public resolvers on a per-client basis

Well, if the clients are IPv6 only, there will be no fallback to IPv4 DNS for them.

or even like I do... Simply re-direct to a DNSSinkhole and use a custom stub resolver/DNS forwarded/recursive DNS server.

I hate the practice of intercepting or modifying clients' DNS traffic. It's basically an attack. I hope this practice will die off naturally as soon as more domains and hosts adopt DNSSEC (or DoH, whichever first).

I fail to understand why some people choose to use IPv6 for internal networking, stick with IPv4 for internal networking (which includes the DNS stub resolver), I mean IPv6 was created to restore the end to end principle and not as an alternative to IPv4 internal networking.

It depends on the practice use/objective. What I do is run a Pi-Hole instance for filtering/blocking ads/malware domains, which is a DNS Sinkhole, now for the actual DNS queries, all of them are redirected from the client to Pi-Hole and then from Pi-Hole(DNS forwarder) to dnscrypt-proxy (DNS stub resolver) and then finally DoH on Cloudflare.

I fail to understand why some people choose to use IPv6 for internal networking, stick with IPv4 for internal networking (which includes the DNS stub resolver), I mean IPv6 was created to restore the end to end principle and not as an alternative to IPv4 internal networking.

You got the right idea. Using IPv6 for internal networking has exactly this purpose: to restore the end to end principle. Not all protocols work well through NAT, and some require ugly kludges to work through NAT (like SIP).

It depends on the practice use/objective. What I do is run a Pi-Hole instance for filtering/blocking ads/malware domains, which is a DNS Sinkhole, now for the actual DNS queries, all of them are redirected from the client to Pi-Hole and then from Pi-Hole(DNS forwarder) to dnscrypt-proxy (DNS stub resolver) and then finally DoH on Cloudflare.

Sure, I also have to use SkyDNS to filter sites in a classroom because traffic filtering for minors is required by Russian law, but it does not prevent me from hating this practice.

I fail to understand why some people choose to use IPv6 for internal networking, stick with IPv4 for internal networking (which includes the DNS stub resolver), I mean IPv6 was created to restore the end to end principle and not as an alternative to IPv4 internal networking.

You got the right idea. Using IPv6 for internal networking has exactly this purpose: to restore the end to end principle. Not all protocols work well through NAT, and some require ugly kludges to work through NAT (like SIP).

It depends on the practice use/objective. What I do is run a Pi-Hole instance for filtering/blocking ads/malware domains, which is a DNS Sinkhole, now for the actual DNS queries, all of them are redirected from the client to Pi-Hole and then from Pi-Hole(DNS forwarder) to dnscrypt-proxy (DNS stub resolver) and then finally DoH on Cloudflare.

Sure, I also have to use SkyDNS to filter sites in a classroom because traffic filtering for minors is required by Russian law, but it does not prevent me from hating this practice.

What? IPv6 was designed with SLAAC in mind, there's absolutely no NAT or ugly hacks needed with a proper prefix delegation from the upstream provider. Unless you have an upstream provider like mine who blocks ICMPv6 and breaks MTU along with a garbage single /64 prefix.

DNS for IPv6 should be handled either with your idea of the public to public query or an IPv4 stub resolver, even then, ALL public IPv4 DNS resolvers can resolve AAAA queries.

What? IPv6 was designed with SLAAC in mind, there's absolutely no NAT or ugly hacks needed with a proper prefix delegation from the upstream provider. Unless you have an upstream provider like mine who blocks ICMPv6 and breaks MTU along with a garbage single /64 prefix.

What "what"? :-) You said you fail to understand why some people choose to use IPv6 for internal networking (your words?). I explained that some people choose to use IPv6 for internal networking to avoid NAT and its ugly hacks, because IPv6 restores the end to end principle. What is it that you don't agree with?

DNS for IPv6 should be handled either with your idea of the public to public query or an IPv4 stub resolver,

Why not an IPv6 caching resolver in the router?

What? IPv6 was designed with SLAAC in mind, there's absolutely no NAT or ugly hacks needed with a proper prefix delegation from the upstream provider. Unless you have an upstream provider like mine who blocks ICMPv6 and breaks MTU along with a garbage single /64 prefix.

What "what"? :-) You said you fail to understand why some people choose to use IPv6 for internal networking (your words?). I explained that some people choose to use IPv6 for internal networking to avoid NAT and its ugly hacks, because IPv6 restores the end to end principle. What is it that you don't agree with?

DNS for IPv6 should be handled either with your idea of the public to public query or an IPv4 stub resolver,

Why not an IPv6 caching resolver in the router?

IPv6 internal networking = Killing SLAAC as you implied with your "IPv6 only clients", why wouldn't they have IPv4 internal addresses aka RFC1918? Dude with IPv6 we have SLAAC, we use IPv4 for INTERNAL use. IPv6 with SLAAC will automatically delegate publicly routable prefixes to each individual client. Where in the hell does NAT come into the picture with native IPv6 SLAAC?

IPv6 caching resolver in RouterOS is already possible with "Advertise DNS" set to off, how many times do I need to say this?

Few points:

- IPv6 is supposed to eventually replace IPv4, so IPv6-only networks make sense. Only when you do it now, you may be a little bit too ahead. Most of the internet is still IPv4-only, so you need NAT64 + DNS64, which is not exactly nice (mainly the DNS64 part). That said, it's not wrong, you can build clean IPv6-only internal network like this.

- With RouterOS v7 you can freely configure DNS for both DHCPv6 and RA. But you probably don't want v7 in production yet. RouterOS v6 can do it only for DHCPv6.

- Whether DHCPv6 is enough depends on clients. Android is known for boycotting it for addresses, but I'm not sure if it applies also to additional info (when network has "Other Configuration" in ND).

- While it would be possible (for v6) to put router's own address in IP->DNS, and it would advertise it, it's probably not good idea. I assume that router would be sending queries to itself and it wouldn't work well. Perhaps if you used only IPv4 upstream resolvers (in order to not give any other IPv6 resolvers to clients) and if you'd block queries to itself using firewall, it could work, but it wouldn't be nice solution.

IPv6 internal networking = Killing SLAAC as you implied with your "IPv6 only clients",

What? I'm afraid you don't understand what you are talking about. Or maybe your definition of "internal" is unconventional.

why wouldn't they have IPv4 internal addresses aka RFC1918? Dude with IPv6 we have SLAAC, we use IPv4 for INTERNAL use.

Please name a reason why they need IPv4 at all for "internal" use, or define "internal use".

IPv6 with SLAAC will automatically delegate publicly routable prefixes to each individual client.

Yes, global prefixes and addresses. Nobody says you cannot use them internally.

Where in the hell does NAT come into the picture with native IPv6 SLAAC?

It comes into picture when you keep IPv4 RFC1918 addresses for some reason, and they start using them for accessing the public Internet.

IPv6 caching resolver in RouterOS is already possible with "Advertise DNS" set to off, how many times do I need to say this?

It seems that not all Android clients honour DHCPv6, but I need to investigate this more.

Putting the router itself into IP->DNS is a bad idea -

I expect so. Who is suggesting such a strange thing?

My suggestion was different. If a DNS server is running on the router, the router should choose one of its own IPv6 interfaces and put its address into RA rdnss field. Maybe the IPv6 address of the router's interface closest to the client. This should be of course a feature of RouterOS.

Few points:

- IPv6 is supposed to eventually replace IPv4, so IPv6-only networks make sense. Only when you do it now, you may be a little bit too ahead. Most of the internet is still IPv4-only, so you need NAT64 + DNS64, which is not exactly nice (mainly the DNS64 part). That said, it's not wrong, you can build clean IPv6-only internal network like this.

Thank you for confirming this.

DNS64 probably breaks DNSSEC which is not nice. But it's a price to pay for the present.

- Whether DHCPv6 is enough depends on clients. Android is known for boycotting it for addresses, but I'm not sure if it applies also to additional info (when network has "Other Configuration" in ND).

I tried DHCPv6 at home and the results are mixed. I need more testing. Maybe I misconfigured something but some Android devices were not learning the IPv6 DNS address.

- While it would be possible (for v6) to put router's own address in IP->DNS, and it would advertise it, it's probably not good idea.

It would be a good idea however to automatically put one of the router's own IPv6 addresses into RAs rdnss field (provided that a DNS server on the router is up and running). It could be a feature of RouterOS. I think it does something similar with IPv4 DHCP server.

I agree with you, but as it is now, you can't do much with v6, but at least v7 shows that things are slowly improving (it's not fully automatic, but you can make it so with script). Unfortunately, IPv6 is not the higgest priority for MikroTik, so it may take a while before you're fully satisfied.