Community discussions

MikroTik App
 
User avatar
vas
just joined
Topic Author
Posts: 24
Joined: Mon Jan 04, 2021 5:35 am
Location: Tomsk, Russia
Contact:

Putting more information into router advertisement packets?

Sat Jan 09, 2021 7:12 am

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?
 
Sob
Forum Guru
Forum Guru
Posts: 6499
Joined: Mon Apr 20, 2009 9:11 pm

Re: Putting more information into router advertisement packets?

Sat Jan 09, 2021 6:31 pm

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.
Excessive quoting is useless and annoying. If you use it, please consider if you could do without it.
 
nescafe2002
Forum Veteran
Forum Veteran
Posts: 737
Joined: Tue Aug 11, 2015 12:46 pm
Location: Netherlands

Re: Putting more information into router advertisement packets?

Sat Jan 09, 2021 6:57 pm

7.1beta has support for DNS in RA, until then use DHCPv6 option 23
 
User avatar
vas
just joined
Topic Author
Posts: 24
Joined: Mon Jan 04, 2021 5:35 am
Location: Tomsk, Russia
Contact:

Re: Putting more information into router advertisement packets?

Sat Jan 09, 2021 7:42 pm

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?
 
mducharme
Trainer
Trainer
Posts: 1128
Joined: Tue Jul 19, 2016 6:45 pm

Re: Putting more information into router advertisement packets?

Sat Jan 09, 2021 7:49 pm

7.1beta has support for DNS in RA, until then use DHCPv6 option 23
Glad to see they finally implemented that, but it is missing the DNS search list option.
 
Sob
Forum Guru
Forum Guru
Posts: 6499
Joined: Mon Apr 20, 2009 9:11 pm

Re: Putting more information into router advertisement packets?

Sat Jan 09, 2021 8:24 pm

Excessive quoting is useless and annoying. If you use it, please consider if you could do without it.
 
User avatar
vas
just joined
Topic Author
Posts: 24
Joined: Mon Jan 04, 2021 5:35 am
Location: Tomsk, Russia
Contact:

Re: Putting more information into router advertisement packets?

Sun Jan 10, 2021 7:58 am

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?
 
User avatar
vas
just joined
Topic Author
Posts: 24
Joined: Mon Jan 04, 2021 5:35 am
Location: Tomsk, Russia
Contact:

Re: Putting more information into router advertisement packets?

Sun Jan 10, 2021 9:53 am

Can I both have DHCPv6 server enabled and keep advertise-dns=yes in "/ipv6 nd"? Is this a supported configuration?
 
DarkNate
Member Candidate
Member Candidate
Posts: 273
Joined: Fri Jun 26, 2020 4:37 pm

Re: Putting more information into router advertisement packets?

Sun Jan 10, 2021 10:35 am

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.
 
User avatar
vas
just joined
Topic Author
Posts: 24
Joined: Mon Jan 04, 2021 5:35 am
Location: Tomsk, Russia
Contact:

Re: Putting more information into router advertisement packets?

Sun Jan 10, 2021 10:47 am

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?
 
DarkNate
Member Candidate
Member Candidate
Posts: 273
Joined: Fri Jun 26, 2020 4:37 pm

Re: Putting more information into router advertisement packets?

Sun Jan 10, 2021 11:14 am

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.
 
User avatar
vas
just joined
Topic Author
Posts: 24
Joined: Mon Jan 04, 2021 5:35 am
Location: Tomsk, Russia
Contact:

Re: Putting more information into router advertisement packets?

Sun Jan 10, 2021 11:30 am

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.
 
DarkNate
Member Candidate
Member Candidate
Posts: 273
Joined: Fri Jun 26, 2020 4:37 pm

Re: Putting more information into router advertisement packets?

Sun Jan 10, 2021 2:56 pm

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.
 
User avatar
vas
just joined
Topic Author
Posts: 24
Joined: Mon Jan 04, 2021 5:35 am
Location: Tomsk, Russia
Contact:

Re: Putting more information into router advertisement packets?

Sun Jan 10, 2021 4:03 pm

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).
 
DarkNate
Member Candidate
Member Candidate
Posts: 273
Joined: Fri Jun 26, 2020 4:37 pm

Re: Putting more information into router advertisement packets?

Sun Jan 10, 2021 4:10 pm

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.
 
User avatar
vas
just joined
Topic Author
Posts: 24
Joined: Mon Jan 04, 2021 5:35 am
Location: Tomsk, Russia
Contact:

Re: Putting more information into router advertisement packets?

Sun Jan 10, 2021 4:32 pm

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.
 
DarkNate
Member Candidate
Member Candidate
Posts: 273
Joined: Fri Jun 26, 2020 4:37 pm

Re: Putting more information into router advertisement packets?

Sun Jan 10, 2021 4:42 pm

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.
 
User avatar
vas
just joined
Topic Author
Posts: 24
Joined: Mon Jan 04, 2021 5:35 am
Location: Tomsk, Russia
Contact:

Re: Putting more information into router advertisement packets?

Sun Jan 10, 2021 5:03 pm

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?
 
DarkNate
Member Candidate
Member Candidate
Posts: 273
Joined: Fri Jun 26, 2020 4:37 pm

Re: Putting more information into router advertisement packets?

Sun Jan 10, 2021 5:58 pm

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?
 
Sob
Forum Guru
Forum Guru
Posts: 6499
Joined: Mon Apr 20, 2009 9:11 pm

Re: Putting more information into router advertisement packets?

Sun Jan 10, 2021 6:37 pm

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.
Excessive quoting is useless and annoying. If you use it, please consider if you could do without it.
 
mducharme
Trainer
Trainer
Posts: 1128
Joined: Tue Jul 19, 2016 6:45 pm

Re: Putting more information into router advertisement packets?

Mon Jan 11, 2021 3:28 am

Putting the router itself into IP->DNS is a bad idea - we tried it to see what would happen and it broke things.

For the routers that we provide to our retail customers, we hand out the DNS via DHCPv6 options. To avoid the problem of the customer prefix from changing affecting the DNS IP to hand to the clients, our standard configuration has a loopback bridge with the IPv6 address fd00::1 applied (i.e. using ULA for the purpose). That way even if the customer prefix changes, the DNSv6 won't be broken. This use of ULA does go against the RFC which stipulates that ULA prefixes should be randomly selected from the range, but for our purposes (home users) we bent this rule a little. It is a lot easier and more reliable than having to create a script to change the DHCPv6 options whenever the prefix changes.

I'm looking forward to v7 and having the ability to customize the RDNSS advertisements. Most likely, I will just continue to use our current mechanism of the fd00::1 loopback but put it in the RDNSS.
 
User avatar
vas
just joined
Topic Author
Posts: 24
Joined: Mon Jan 04, 2021 5:35 am
Location: Tomsk, Russia
Contact:

Re: Putting more information into router advertisement packets?

Mon Jan 11, 2021 5:23 am

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.
 
User avatar
vas
just joined
Topic Author
Posts: 24
Joined: Mon Jan 04, 2021 5:35 am
Location: Tomsk, Russia
Contact:

Re: Putting more information into router advertisement packets?

Mon Jan 11, 2021 5:30 am

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.
 
User avatar
vas
just joined
Topic Author
Posts: 24
Joined: Mon Jan 04, 2021 5:35 am
Location: Tomsk, Russia
Contact:

Re: Putting more information into router advertisement packets?

Mon Jan 11, 2021 5:41 am

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.
 
Sob
Forum Guru
Forum Guru
Posts: 6499
Joined: Mon Apr 20, 2009 9:11 pm

Re: Putting more information into router advertisement packets?

Mon Jan 11, 2021 10:38 pm

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.
Excessive quoting is useless and annoying. If you use it, please consider if you could do without it.

Who is online

Users browsing this forum: No registered users and 80 guests