I found a post from 2 months ago stating MT does not fully support ipv6 and cannot hand out dns information over dhcp. Is this going to happen any time soon? I am beginning my journey with IP6 and it seems I may be at a stopping point without that. We can’t call all of our customers and ask them to manually enter these.
How is everyone else handling this?
It’s not exactly true. RouterOS can hand out DNS resolvers using both stateful (*1) and stateless (*2) DHCPv6. The main trouble is that it’s not yet as configurable as you might want. It will just look at resolvers in “/ip dns” and if there are some IPv6 ones, it will pass those to clients. If you can live with this, then it’s usable.
And anyway, it only really matters when you create IPv6-only network. If you have dual-stack, clients can simply use IPv4 resolvers and those can resolve IPv6-related records just fine.
–
(*1) Only as part of DHCPv6 PD, it can’t give out addresses yet.
(*2) Just add DHCPv6 server without pool to interface.
Now I’m discovering that MT can’t even hand out dhcp addresses yet. Is this going to happen any time soon as well? Seems like my journey into learning ipv6 is going to be very short lived unless I start playing around with other routers.
MikroTik, are you listening? ^^
That said, if your devices support it you can use SLAAC to give them an IPv6 address. That should keep you trucking for another hour or two.
They are strategically waiting for everything around IPv6 to settle and then they’ll implement whatever becomes most important, to avoid wasting time on dead ends. Ok, I’m just kidding. But the truth is, too many people want too many different things and they can’t add them all at the same time. And what seems critical to one user, is low priority for another. Well, lets hope they do have a plan. 
Back on topic, everything supports SLAAC, it’s the basic way to get IPv6 addresses, DHCPv6 is extra. So lack of the latter should not be a showstopper. It’s also possible to use external DHCPv6 server (I don’t say it’s always practical, but if you really need it…).
It’d be nice. It’d also be nice to hear what MikroTik is working on without watching RC release notes.
Also, it’s important to note that in MikroTik SLAAC w/the advertise-dns option it will simply distribute the IPv6 values in your /ip dns servers setting. You cannot give it the address of a resolver like DHCPv4. You also are unable to specify search domains. RFC6106 does not limit this to a pre-defined forwarder.
A low-hanging fruit clean-up of this feature would that would add a lot of polish would be to use additional values, like the PPP profile does, to allow those that need it to override the default behavior of the RDNSS feature to provide a better user experience.
/ipv6 nd interface=br1 advertise-dns=yes use-dns=local dns-search-list=my-first-domain.com,my-second-domain.com
^^ Like this, we could be allowed to enter a static value for use-dns or in honor of IPv6 and it’s lean towards auto-configuration it could also accept an interface name or keyword like “local” to indicate the IPv6 addresses assigned to br1. This would allow for graceful handling of a prefix change while still allowing us to direct DNS queries to the local resolver.
That is a bit strange, isn’t it? I would expect that when the /ip dns service is allowing remote requests, it would pass its
own IPv6 address to the clients. That is what you would normally do on IPv4 as well…
I agree, it should be configurable. It should be possible to enter addresses manually like with IPv4 DHCP. Plus some magic option to use router’s address, to work with dynamic prefixes received from upstream DHCPv6 server. But so far it’s just addresses from /ip dns.
I spoke with Janis Megis at MUM USA this year and he said essentially this very thing to me when I asked him whether they plan to implement any IPv6/IPv4 interworking features such as NAT64 stateless/stateful or helpful tools such as NAT-PT for those with dynamic prefixes / multi-ISP configurations. He replied that there are so many proposed solutions and interworking systems out there now that they do not want to spend effort implementing any of them only to have them be deprecated shortly thereafter when they could have been spending energy on something else like improving their routing engine’s core performance, etc.
As for XLAT464 (which I’ve been very interested in deploying, but is not possible using only Mikrotiks), he stated that I could just use 4-in-6 tunnels to cross an IPv6 only access/distribution layer. This has led me to discover DS-Lite (dual-stack lite) which would work just fine with Mikrotik as the CPE (B4 device) - now I’m looking into possible AFTR platforms to test with.
Fortunately for my organization, we have enough available IPv4 space to carry us for a while doing just simple native dual stack deployment, but it would be nice to start rolling out v6-only portions of our network to simplify things.
That’s very interesting. I’m going to have to lab this up in a moment to go see it in action. That’s encouraging at least, although I agree with you that they could polish up the advertise DNS option in SLAAC without a huge investment of effort, and it would go a long way to improving the usefulness of Mikrotik routers as IPv6 CPE.
I can totally get not wanting to get caught up in implementing adoption tech, that is a moving target and can be safely implemented by dedicated servers. This is probably for the best if you have any logging constraint for compliance when you NAT customers.
If MikroTik is hesitant to adopt new technologies I’d rather see them polish their existing implementation. Basically, look at a TP-Link with OpenWRT for the home model or CPE target.
Clean-up their SLAAC implementation (allow admin to set the DNS server and search list or correctly point them to the router itself)
DHCPv6 server implementation for the LAN (even if DHCPv6-PD server can be used to set options)
Clean-up DHCP and DNS synchronization, dnsmasq in OpenWRT makes this look easy. It shouldn’t require extra scripting and is a reason to use DHCPv6 over SLAAC in an environment or at least over the top
These are low hanging fruit and polish items that any developer should want to apply to their product. I’d also rather see MikroTik implementing more of the transition tech, with ISPs being a target market they are risk of losing out to other vendors. A linux box running jool could be a CHR w/a big fat license or some hardware box.
Well, I kind of agree with that. We seldomly have seen a bigger mess in IT than with the introduction of IPv6 and the many solutions for migration and tunneling that go alongside it.
And it has happened many times that once a new and great solution was in implementation in some places, a newer and even greater solution arrived.
However, it looks like things have stabilized a bit (if not at the “ok then let’s forget about the entire thing” point). As it is now, it would be possible to implement some features that would probably be useful to a large group of customers. Big question of course always remains what features to implement when there are limited developer resources to do it.
You and me want other things than the poor souls who are at a provider who gave them a single /64 or maybe even less and require workarounds for that.
At the moment, I am faced with having a second backup internet connection of the same capacity as the main one, and of course on IPv4 I have all the tools in RouterOS to just balance them when they both work (for the majority of the users, who connect to outside). In IPv6 there is not even policy routing let alone any way to balance the use, and no NAT to keep a fixed internal address independent of the line actually in use. For now I can only think of some script that switches from line 1 to line 2 when line 1 is down, so in effect for IPv6 we do not balance.
I would of course like to see “ipv6 route rule” and preferably also “ipv6 firewall nat” for this.
Others may have completely different wishes, like those IPv6-over-IPv4 and IPv4-over-IPv6 methods, which I don’t require at all because all providers I deal with offer both native IPv6 and IPv4, at least on the commercial offerings.
It appears to be working. In our guest network several computers have obtained the DNSv6 servers from the DHCPv6 server and are using them.
Before, I believed it was not working because I would think the DHCPv6 hands out the own DNS resolver’s address and I saw the firewall input rules
for port 53 stuck at zero count, but now that I added another rule for “forward new udp port 53” ahead of the “forward new” I see that indeed
DNS traffic is going to the DNSv6 servers we have in /ip dns. Of course without being cached, but who cares…
(to be sure that the MikroTik DNS resolver actually works with IPv6 clients I tried a dig with explicit @server and indeed it does)
Ok I seem to have everything working here. IPv6 is really confusing at first, but starting to make sense to me the more I play with it.
I have my main router setup to hand out prefixes via dhcp6. Main router is using link local addresses only, but handing out prefixes from a 32 that Arin gave us. My test client (my house), has dhcp6 client setup on wan port, then I created an IPv6 address on my lan port from the pool created by the dhcp client, which is a /64. Test client router (my house) is using link local address for default gateway. I also have googles IPv6 DNS listed in dns servers and all my computers are grabbing and using it. Seems fine.
Does all this sound like a proper setup?
Couple Questions
Neighbors, in my ipv6 neighborlist every device shows as stale. Even when traffic is being used. Is this normal?
what would be the point of a ipv6 dhcp server if this can be setup dynamically without one? Just record keeping maybe?
is there any advantage to putting an IP address on my WAN port or would link locals be the equivalent of routing with private ips?
Yes. Don’t know if it is optimal, but at least it is what I always observe.
- what would be the point of a ipv6 dhcp server if this can be setup dynamically without one? Just record keeping maybe?
I think most people install DHCPv6 because they also had DHCPv4 and did not yet study IPv6 before they start configuring their router.
- is there any advantage to putting an IP address on my WAN port or would link locals be the equivalent of routing with private ips?
You don’t need a globally routable IP address on your WAN port unless you want to use it to have the router provide services to
the internet (e.g. VPN tunnels over IPv6) and you do not want to use some arbitrary inside address for that.
Below is another reason for DHCP (q2) along w/an answer to q3.
Another big one for me is being able to assign an individual address to a CPE as part of the address assignment process. Like you’re finding out it can and will work with only link-local addressing. Some may view this method as lacking. Those link-local addresses will be the ones that show up in traceroute. This can very quickly complicate troubleshooting efforts. Additionally logging and tracking an individual user can become more difficult. While none of those constraints are insurmountable I think a lot of would find more comfort issuing an individual address to a CPE along with a prefix assignment.
Looking specifically to Time Warner, now Spectrum, here in the US. A very large cable provider. This is exactly how they issue prefixes.You get a global unicast WAN address along with a prefix up to a /56. It allows you to inject a route for the issued prefix that can be more clearly understood when looking at as part of the DHCP process.
I’ll leave with you some clarity, hopefully, on link-local addressing in IPv6. Link-local traffic cannot escape a subnet. In otherwords, a link-local address from your LAN cannot ping the link-local address somewhere within your ISP network. It however is used for when determining next-hop information, like what MAC address to send a packet to. This means with just link-local addressing and appropriate routing statements you can forward a packet along. It’s also why we saw support for link-local addresses in layer 3 gateway protocols first. Although it could be argued that HSRP and VRRP aren’t needed due to RAs it’s still a warm security blanket we wrap ourselves in. Especially for hosts that do forwarding. These won’t listen to RA messages and need to be told where to send packets. You are left with static routes that do checks (IP SLA or simple ping) or setting a dynamic routing protocol. HSRP or VRRP can be a useful too to provide a single next-hop address that is managed between the 2 upstream routers. Initially this was only supported with a link-local address. Commonly I’ve seen people use fe80::1. I believe HSRP now supports global unicast gateway addresses as well. You may find some devices, especially older ones, that will only allow you to enter a link-local address as the next-hop. This usually very odd to IPv6 new comers.
Long story short, I use global unicast where ever possible. For me it clarifies traffic flow when troubleshooting and that’s enough of a reason especially because I use non-64 bit prefixes on my point to point links so my address plans have never been in danger of address of exhaustion.
We have a large networking consisting of 18 routers. I setup OSPFv3 to get the networks working with IPv6 using the link-local addresses and it works fine. With IPv4 we used private addresses for OSPF because we didn’t have enough addresses to use public IP’s. It never created any issues for us other than the random tracert someone tried to do from outside in.
If I wanted to use routable IPv6 do you just place a /64 between the 2 routers or will subnetting smaller work? I’ve read that anything smaller than a /64 breaks things. Considering OSPFv3 is setup using ethernet ports instead of IP addresses will it choose the ports routable IP over the link-local if it has one? Or does that need to be specified?
Last question which is more of an observation really. My house currently has 51 internet devices. Everything from computers, to thermostats, rokus, wemo light switches, etc. I’m discovering that the only devices I own that are even grabbing IPv6 addresses are computers and phones. That leaves a TON of devices that appear to not be ready for this. Am I jumping into this too early? I know that dual stacked is the way to go, but we’re out of IPv4 and a dual stack would have to consist of customers sharing IPv4 addresses and natted together, but have their own prefix for IPv6. I suppose this will work since a thermostat could care less if it’s natted a couple times, but seems to me more of these devices should be ready by now.
The benefit of assigning IPv6 addresses via DHCPv6 is so any given device will always have a known address (if assigning persistent leases based on the DUID). Or even dynamic DHCPv6 addressing will let you know who had the address. Why? … so you can identify source of bad or malicious traffic, filtering / access controls, etc. SLAAC and ever changing “privacy address”, that disappear as quickly as they appeared, are a nightmare to manage. Only in a home network or very small business should these ever be allowed. Certainly never seen in large enterprise networks.
Even at home I run dnsmasq on ubuntu as a DHCPv6 server.
If it works for you and you’re able to troubleshoot effectively and customers don’t complain than I say go ham. Me personally, I give them a global address because that’s just how my brain works.
Historically I’ve used /126 addresses for PtP links, using a /64 is honestly just wasteful and planning an address plan for a network containing a large number of PtP links can become challenging if you are constantly tossing /64’s in for each PtP. Even with a /48 or larger network. I’ll need to do some additional testing but it looks like the IETF community is moving a /127 for PtP usage with the idea of implementing MUST rules to how packets are handled to solve traditional beaf with their use which is conflict with the Subnet Router Anycast address causing a forwarding loop. That said a /126 should still be valid as long as it is used similarly to a /30 and the first value (traditionally the network value) goes unused because that assumes the subnet router anycast address. Another important note is the IETF does not seem keen to mandate /64 everywhere but it will be require those that use prefixes smaller than that to be cognicent of the impacts of the specific address blocks that are normally restricted. https://tools.ietf.org/html/rfc6164 this will give you an example. I’ve also some hits that improper setting of u and g bits with a prefix smaller than /64 may cause issues but I haven’t seen any published work or implementation that has shown as affected.
I couldn’t agree more, it’s a chicken and egg problem. Some of the devices that would benefit tremendously from IPv6 have yet to implement it. This can be anything from the horrendously weak and often outdated SoC’s used in common IoT type products to just a lack of knowledge so the manufacturer disables it and prefers to use NAT over IPv4 to build a solution. The only devices left on my network that cannot successfully do IPv6 are my Roku’s. Sadly I made a significant investment in them a while back hardware wise and I’m not positioned to change them out for IPv6 supported devices like Chromecasts or Apple TVs but at some point I may. The important thing is that those incompatabilities are reported to the device manufacturers. Especially if you’re an ISP. To be honest I wouldn’t even talk to their tech support. I’d talk to a leader in the Sales Department. Hey Roku, I’m ISP XYZ, we love your product, we’d love to recommend to our xyzz subscribers but because IPv4 address depletion is real we are going IPv6 only. Your device doesn’t support it so we’ll be recommending to our customers that they buy Apple TVs and Chromecasts. You alone may not move the needle but as more and more ISPs report that feedback in their sales leaders will get anxious. That anxiousness will transfer to the development and engineering teams on it’s own and much more effectively.
The key here for me is not take the entire burden of the transition onto yourself. It’s not your responsibility to make every single technology stack work. It’s not out of the question to make a best effort to keep it working. At some point, someone somewhere is going to have to opt for IPv6 only connectivity to get a service working or the layers of NAT will continue to get unbearable. An alternative I’ve suggested before is make it a revenue stream in your business. IPv4 is easy, a single stack to administer. So is IPv6. For the customers that can make it work great, for those that can’t offer static IPv4 addresses at an upcharge or heck upcharge them to live behind a IPv4 CGN solution. Like my earlier example with sales guys, wallets make arguments short. You’ll continue to be able to provide services to your customers and you will continue to have options for them to stay connected to the legacy IPv4 Internet. Additionally, you’ll be compensated for the additional overhead of running the more complicated solution and they’ll be financially motivated to select IPv6 compatible products and services while badgering those devices that they need but are still IPv4 only to go IPv6 because they’re footing the bill monthly for the lack of compatibility.
This customer driven incentive to migrate away from IPv4 will aid in eventually being able to shut down transition technology in your own environment. Today, you may need to start with 10 boxes running NAT64 to handle the load. With an incentive to select IPv6 only products and come onto an IPv6 only service you will be able to hopefully continue to use the same 10 boxes as you grow or even better slowly decomission some of them as more and more customer requests are traversing IPv6 networks.
I watched an interesting talk at an IPv6 meetup this year by T-Mobile, the presenter said it is more interesting for him to watch which providers aren’t egressing their NAT64 box (by AS) than those that are. In addition watching the amount of the traffic being NAT’d to IPv4 vs native. Because critical streaming services are going IPv6 huge swathes of bandwidth can move over the IPv6 side compared to more general web traffic and things like EMAIL or VPN that traverses NAT64.
This echo’s my recommendation to all enterprises I consult in, get IPv6 provisioned at least into your Internet edge. Any external service that can be offered over IPv6 should, likely dual stacked. In particular I drive hard at getting customers to adopt IPv6 transport for their remote access VPNs. By not having to traverse a single NAT for those that can connect to it you can eliminate a huge percent of not connecting issues to the enterprise. In the case of a Cisco ASA it is horrendously easy to do. Even if the VPN still only actually moves IPv4 packets inside of it.
That’s IPv6 in real world, it has been like this since the beginning. Everyone is waiting for someone else and progress is slow. Why should manufacturers make IPv6-ready devices, when users don’t want them? Why should users want them, when ISPs don’t offer IPv6? Why should ISPs offer IPv6, when users don’t ask for it? Someone has to start. And since users are generally clueless, they don’t understand this stuff, it needs to be ISPs. So as an user, you may be too early. As an ISP, you’re already late.