IPv6 and DHCP and DNS

jmay · Sat Jun 17, 2017 12:32 am

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?

Sob · Sat Jun 17, 2017 2:32 am

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.

jmay · Mon Jun 19, 2017 8:00 pm

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.

idlemind · Mon Jun 19, 2017 10:20 pm

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.

Sob · Tue Jun 20, 2017 12:26 am

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...).

idlemind · Tue Jun 20, 2017 4:30 am

Well, lets hope they do have a plan.

It'd be nice. It'd also be nice to hear what MikroTik is working on without watching RC release notes.

idlemind · Tue Jun 20, 2017 4:29 pm

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.

pe1chl · Tue Jun 20, 2017 7:39 pm

It will just look at resolvers in "/ip dns" and if there are some IPv6 ones, it will pass those to clients.

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...

Sob · Wed Jun 21, 2017 12:05 am

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.

Wed Jun 21, 2017 12:24 am

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.

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.

RouterOS can hand out DNS resolvers using both stateful (*1) and stateless (*2) DHCPv6.

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.

idlemind · Wed Jun 21, 2017 1:11 am

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.

pe1chl · Wed Jun 21, 2017 11:46 am

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.
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

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.

pe1chl · Wed Jun 21, 2017 12:14 pm

RouterOS can hand out DNS resolvers using both stateful (*1) and stateless (*2) DHCPv6.
That's very interesting. I'm going to have to lab this up in a moment to go see it in action.

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)

jmay · Wed Jun 21, 2017 4:57 pm

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

1) Neighbors, in my ipv6 neighborlist every device shows as stale. Even when traffic is being used. Is this normal?

2) what would be the point of a ipv6 dhcp server if this can be setup dynamically without one? Just record keeping maybe?

3) 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?

pe1chl · Wed Jun 21, 2017 5:52 pm

1) Neighbors, in my ipv6 neighborlist every device shows as stale. Even when traffic is being used. Is this normal?

Yes. Don't know if it is optimal, but at least it is what I always observe.

2) 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.

3) 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.

idlemind · Wed Jun 21, 2017 5:53 pm

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

1) Neighbors, in my ipv6 neighborlist every device shows as stale. Even when traffic is being used. Is this normal?

It's not out of line, if you are monitoring it closely you should see some entries become reachable. I'm not sure what the default timer value is for MikroTik. They do support the reachable-timer value in the ipv6 nd settings. This likely just relates to the timer value advertised by RA. I'm not sure if it falls back into the RouterOS value, equivalent of an ARP cache timer in a way. At least a sub portion of it.

Side-note, you can check your IPv6 neighbor cache on Windows 10 with PowerShell. While we're on the topic it supports IPv4 and IPv6. Super cool little command-let. Who doesn't love PowerShell and it's handy filtering states:
Code: Select all
Get-NetNeighbor -AddressFamily IPv6 | Where-Object -Property State -NE Stale
Get-NetNeighbor -AddressFamily IPv6 | Where-Object -Property State -NE Reachable
2) what would be the point of a ipv6 dhcp server if this can be setup dynamically without one? Just record keeping maybe?

You hit the nail on the head. Record keeping is a key function, I translate this as DHCP to DNS integration. No one wants to type an IPv6 address into a web-browser, especially one generated through SLAAC. While we humans could manage to type a 4 octet IP address in this gets a little ridiculous with IPv6. Addiotionaly DHCPv6 is important to set client-side values, this appears to work for most PCs with the current MikroTik DHCPv6 implementation. It will be critical to test more extravagant options as IPv6 usage grows. Some common uses would be PXE booting, requiring the TFTP options. Alternatively CAPSMAN, or what I'm more familiar with, Cisco Wireless DHCP based discovery of a controller.

3) 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?

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.

jmay · Wed Jun 21, 2017 6:58 pm

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.

proximus · Wed Jun 21, 2017 7:00 pm

2) what would be the point of a ipv6 dhcp server if this can be setup dynamically without one? Just record keeping maybe?

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.

idlemind · Wed Jun 21, 2017 8:00 pm

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 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.

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?

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.

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.

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.

Sob · Wed Jun 21, 2017 8:30 pm

That leaves a TON of devices that appear to not be ready for this. Am I jumping into this too early?

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.

jmay · Wed Jun 21, 2017 8:38 pm

Thank you for everones responses! I do believe I am walking slowly on the right freeway now. A few days ago an IPv6 address looked like date stamp from the future, but thanks to this forum and lots of youtube videos I've got internet on a few devices.

Thats a good point about charging for IPv4 space. We already charge a fee for IPv4 statics so we could consider migrating customers to a dual stack network even if some of them are masquaraded on the IPv4 side. If a customer doesn't like it I could put them on a pure IPv4 network for a fee. I think I'll have to call a meeting about this one.

Thanks again.

jmay · Wed Jun 21, 2017 8:44 pm

So as an user, you may be too early. As an ISP, you're already late.

Believe me I know I'm late. In my defense I don't own the ISP, but I am asked to single handedly be the network admin, the manager, the customer complaint department, the tower crew leader, employee relations, and pyschiatrist. We have over 80 towers and the normal day to day routine just doesn't give me the time to do anything beyond new problems that show up on a daily basis. I finally talked the company into letting me spend a day a week at home to work on things for a while. I can get more done in a couple of hours in my home office than I can in a month at work.

Wed Jun 21, 2017 10:50 pm

Those link-local addresses will be the ones that show up in traceroute. This can very quickly complicate troubleshooting efforts.

This is incorrect.*

Link-local addresses must not be forwarded at layer 3 by routers. Therefore, no packet could be forwarded from a link-local interface address to any host that is not directly connected to the same layer 2 network.

When you traceroute across link-local-only hops, the various routers in the path will respond using their loopback addresses or the address of some other interface which has a global-scope IPv6 address on it. This can complicate troubleshooting (as you stated) if your topology contains multiple layer-3 links between the same pair of routers. The traceroute will show which routers the path traverses, but it will not give any indication of which actual link was chosen for your trace. On the other hand, when the links also have routable addressing on them, the trace will show those interface addresses. Obviously this can be more useful in troubleshooting as you suggested.

This is the reason I chose not to go with link-local-only addressing in my core topology.

Regarding customer access links, the vast majority of customers are single-homed so there's no "loss of information" by using link-local-only on the attachment circuits to CPE. Even if a CPE is assigned a single /64, applied to its LAN interface, this is sufficient to troubleshoot most customers because the customer's router will respond to pings, traceroutes, etc using its LAN interface's public address.

*edit: There is one case where I've seen a link-local address appear in a traceroute - after posting this, just for laughs I decided to see what would happen if I built a chain of routers which ONLY had link-local addresses except for the first and last ones in the chain. When I traced from router A to router Z, I got router B's link-local address as the first hop, then all stars (timeout) for each subsequent router in the chain until the Z router which responded with its global address. A and Z could communicate just fine, but only with each other or with their direct neighbors only. (this was using Cisco by the way - I can roll out a topology in GNS3 much more quickly than I can do with ROS)

idlemind · Thu Jun 22, 2017 12:25 am

This is incorrect.*

Link-local addresses must not be forwarded at layer 3 by routers. Therefore, no packet could be forwarded from a link-local interface address to any host that is not directly connected to the same layer 2 network.

When you traceroute across link-local-only hops, the various routers in the path will respond using their loopback addresses or the address of some other interface which has a global-scope IPv6 address on it. This can complicate troubleshooting (as you stated) if your topology contains multiple layer-3 links between the same pair of routers. The traceroute will show which routers the path traverses, but it will not give any indication of which actual link was chosen for your trace. On the other hand, when the links also have routable addressing on them, the trace will show those interface addresses. Obviously this can be more useful in troubleshooting as you suggested.

This is the reason I chose not to go with link-local-only addressing in my core topology.
***
*edit: There is one case where I've seen a link-local address appear in a traceroute - after posting this, just for laughs I decided to see what would happen if I built a chain of routers which ONLY had link-local addresses except for the first and last ones in the chain. When I traced from router A to router Z, I got router B's link-local address as the first hop, then all stars (timeout) for each subsequent router in the chain until the Z router which responded with its global address. A and Z could communicate just fine, but only with each other or with their direct neighbors only. (this was using Cisco by the way - I can roll out a topology in GNS3 much more quickly than I can do with ROS)

As always, zero, I'm but an apprentice. If I had thought it about too I would have come to the same conclusion about link-local's appearing in traceroute. I likely saw the condition you did which is the link-local for a router that has a direct attachment to another (1st hop type scenario) and my noodle of a brain lumped 'em all together.

Thu Jun 22, 2017 1:25 am

As always, zero, I'm but an apprentice. If I had thought it about too I would have come to the same conclusion about link-local's appearing in traceroute. I likely saw the condition you did which is the link-local for a router that has a direct attachment to another (1st hop type scenario) and my noodle of a brain lumped 'em all together.

Actually, your posts are pretty much always on-point, so I just thought I'd chime in because we all benefit from little tweaks to our knowledge/understanding of things.

FWIW, I wasn't expecting to see the fe80::2 reply on the first hop either, but it made sense when I saw it happen.
I was half-expecting my little experiment to have results like MPLS where the hops are hidden.

jmay · Fri Jun 23, 2017 12:01 am

Are any of you running an ISP? I'm wondering how you are handling all this.

I have a mix of canopy and ubiquiti for customer CPE's that are not going to be easy to implement IPv6 like MT CPE's. Ubnt only supports IPv6 via DHCPServer as far as I can tell and for the old canopys I would have to run them un-natted. (yikes!)

I figure my options would be to un-nat customers and let their routers take over, but then I risk broadcast storms and how would I even track whos getting what prefix? The other option would be another router that supports DHCPv6 fully which would be a pain considering we have multiple routers out there.

How are you handling all this in your ISP?

blackmesawireless · Fri Jun 23, 2017 12:34 am

Are any of you running an ISP? I'm wondering how you are handling all this.
How are you handling all this in your ISP?

We are just starting to test all this. I'm not only the owner, I'm also a client! So I've been testing dual-stack at my house via an HE.net tunnel at the core for more than six months. Our main upstream provider (community middle mile) is dragging their feet on v6 but we're turning up another upstream connection any day here, the fiber was run last week.

At the moment I am still a believer in 464xlat, I've been testing v6-only wifi SSIDs at home and the office and they seem to work just fine with OpenWRT on the router and jool/bind9/quagga at the core. Aside from a strange glitch where google's v6 DNS servers didn't have an entry for a domain (but the v4 servers did), I've had no problems. I added the v4 google dns servers to the forward list in bind and that problem has not reappeared.

For UBNT we have a problem, they don't support 464xlat (even though it should be trivial for them to add as it's a fork of OpenWRT), they do support several different IPv6 address management options. We normally run home users in router mode with the public on WLAN0 and 10.10.10.1 on LAN0, DMZing everything to the customer router on 10.10.10.2. This provides us some benefits including authentication of the radio not the router.

This gets really goofy with the v6 prefix setup becuase it wants to pull a /56 on the wan, and then delegate a smaller prefix to the lan. I don't really understand the desired behavior of the v6 options in AirOS5/6 and I've posted on their forum but so far radio silence. I get the feeling it's not really used. (Go search that forum for IPv6... crickets.)

This is a really interesting thread and I'm following along. I have the same problem with DHCP and DNS. I want to hand v6-only clients our DNS64 addresses (and ideally the 464xlat prefix too but we're using the well-known prefix for testing). Right now the only way to do that is to hand that out to all v6 clients and also for the router to have those servers in its rotation.

I'd like to hear more about ds-lite with Mikrotik since that's already supported well on a bunch of different routers. Mostly with any NAT I worry about Apple devices and game consoles complaining about double-natting, which gives us customer support headaches if it happens.

Fri Jun 23, 2017 1:04 am

There's a lot of thought and design decision that must go into the answer to all of your questions.

A few comments towards some things I read in your post though - IPv6 is going to be completely public (no NAT) when using RouterOS because it doesn't support any sort of NAT with IPv6 whatsoever (no nat64, no prefix translation, and most definitely no nat66 - the straight up counterpart to current IPv4 NAT44). Count on assigning at the very least a /64 to each customer, and a /60 to those who want multiple lan-side segments. I'm planning to make /60 the standard assignment per customer getting started on our roll-out.

Our IPv4 allocation is pretty much all done statically as we provision customers, so most likely we'll end up just doing the same with IPv6, but for dynamic assignment (by which I mean dynamically negotiated, but static in RADIUS - I'm NOT going to subject my customers to ever-changing addresses within their own networks) I'm most likely to use RADIUS-backed DHCPv6-PD (prefix delegation). It automatically activates the static route in our access routers and allows for more of a "one size fits all" configuration in the CPE.

For me, the biggest hurdles to overcome have been:
1) Deciding on an allocation scheme that scales well, aggregates well, isn't lavishly wasteful of space, and is easy to train employees on.
2) Deciding how to handle the dual-stack deployment - should we dual stack all the way to the customer or can we deploy a scalable solution that allows v6-only on our network and islands of V4 at the CPE and at the Internet border? I'd prefer the second to simplify our network, but it appears that unless I want to roll our own solution with Linux boxes, it's going to be an expensive proposition no matter which interworking tech we may choose. I'm currently looking into ds-lite which should be workable with Mikrotik CPE as the B4 devices. I'd prefer XLAT464 but Mikrotik has not shown any indication that they plan to implement NAT64 stateless any time soon (which would be required for a Mikrotik router to function as CPE)
3) getting hands-on experience with the protocol in a live envioronment to gain experience prior to going into production with it
4) getting used to the idea that I'm going to really give every customer these humongous allocations of 68 bits' worth of space (or more) just because "convention" is a /64 per LAN. (I've been an IPv4 miser ever since my career began in the 1990s) - This ties in with #1 because I was really wanting to just give each customer a /96... until I learned that not being /64 breaks stuff at the LAN level...

Trema · Fri Jun 23, 2017 1:44 am

I believe that handing out at least a /56 to each customer is recommended (source?). In the Netherlands the ISP's have agreed that they will follow this guideline. Some (XS4ALL, Solcon) even give /48's. Anyway, at least take a look here: http://www.internetsociety.org/deploy360/ipv6/.
Also interesting is the dhcpkit by Sander Steffann: "Its purpose is to provide a framework for DHCP services. It was written for ISPs to use in provisioning their customers according to their own business rules." I know that at least one Dutch ISP has implemented this software. https://github.com/sjm-steffann/dhcpkit

Sob · Fri Jun 23, 2017 2:56 am

Some on topic reading: https://sinog.si/docs/draft-IPv6pd-BCOP-v2.pdf

paulct · Fri Jun 23, 2017 10:53 am

We have decided on a /48 per customer regardless if its a big corporate or a small home user. It just makes things more simple.
e.g if one of your clients wants to subnet then a /56 is the minimum.

You could do - /56 for home users and /48 for corporate's - but why?
e.g a /32 allocation is 65536 /48's. I for one will not have that many P2P links or customers. Even if we do it will not be hard to get another allocation.

Everything is manual for the moment. Anyone have a script or such for Mikrotik's that takes a /64 from e.g a /48 and allocates it to the LAN side for SLAAC? Or is there a feature in Mikrotik that can do this?

Currently we are only running some IPv6 on our core and edge network. Hoping to roll it out soon to customers.

pe1chl · Fri Jun 23, 2017 11:02 am

4) getting used to the idea that I'm going to really give every customer these humongous allocations of 68 bits' worth of space (or more) just because "convention" is a /64 per LAN. (I've been an IPv4 miser ever since my career began in the 1990s) - This ties in with #1 because I was really wanting to just give each customer a /96... until I learned that not being /64 breaks stuff at the LAN level...

As already commented above, I would advise to allocate a /56 per customer when you don't want to give a /48. /60 should be enough, but it is not a recommendation.
Giving only a /64 to a customer is not at all a good idea, but you know that.

You probably have a /32 for your ISP (and you can get additional allocation up to /30 very easily).
Likely I would do something like this when I had a single /32:
- split it in 2x/34 and 1x/33
- use one /34 for internal networks and servers
- use one /34 for co-located customers
- use the /33 for connected customers

From a /33 you can allocate 32768 /48s or 8 million /56s. Select on your number of customers. As mentioned, you could easily get your /32 expanded to a /30
and get for 196608 additional connected customers with a /48. That is enough for many "smaller" ISPs. And when you are a larger ISP, getting additional
space is not a problem. Note that there are as many /32 networks in IPv6 as there are individual addresses in IPv4.

pe1chl · Fri Jun 23, 2017 11:09 am

Everything is manual for the moment. Anyone have a script or such for Mikrotik's that takes a /64 from e.g a /48 and allocates it to the LAN side for SLAAC? Or is there a feature in Mikrotik that can do this?

You can do that with DHCPv6-PD.
It is a service that allows the customer router to request a /64 from their /48 pool, and the MikroTik can then assign it to an interface.
When you have different internal interfaces, each gets a different address from the pool.
UNFORTUNATELY there is no way to direct the router to get some fixed prefix assigned to each interface, they just are assigned
in some "fixed" order that you can not directly influence. When you disable and re-enable an interface it will get a different
address until you reboot or release the client lease and it may get back to the initially assigned value. May.
Extremely annoying... but of course will be fixed in version 7 !!

/ipv6 dhcp-client
add add-default-route=yes interface=pppoe-xs4all-inet pool-name=xs4all-v6prefix request=prefix
/ipv6 address
add from-pool=xs4all-v6prefix interface=bridge-local
add from-pool=xs4all-v6prefix interface=bridge-public

blackmesawireless · Fri Jun 23, 2017 7:08 pm

After reading several books on the topic we have settled on a sparse allocation scheme. We were given a /36 by ARIN and based on the way our network is laid out we have split it into /44s with current infrastructure allocations evenly spaced throughout the /36. We are planning to allocate a /52 to each customer. In the future if we need more /52s on a given tower we can expand the /44 because there is empty space around it.

This gives us up to 256 'towers' or points of presence, with 256 clients per PoP. And again we can expand those /44s if needed.

By the way this is a really handy tool for sorting this all out:

http://subnettingpractice.com/ipv6_subnetting.html

rgrocery · Tue Jun 27, 2017 1:42 am

Hello, I am sorry to Hijack this thread but #ZeroByte would it be possible to hire you? We need help and you seem knowledgeable and trust worthy. Email: Josh@sommersmarket.com

jmay · Thu Jun 29, 2017 7:58 pm

Anyone play around with non MT routers? I'm testing with home based routers since our customers have them and for the life of me I cannot get IPv6 working on this netgear I purchased. I'm going to pick up another brand to see if it's something I'm doing wrong, but I'm wondering what kind of luck you guys have had with basic el cheapo routers. The netgear forums are full of posts about buggy software.

Mon Jul 03, 2017 3:27 am

Anyone play around with non MT routers? I'm testing with home based routers since our customers have them and for the life of me I cannot get IPv6 working on this netgear I purchased. I'm going to pick up another brand to see if it's something I'm doing wrong, but I'm wondering what kind of luck you guys have had with basic el cheapo routers. The netgear forums are full of posts about buggy software.

I've only messed with it on servers, end devices, on Cisco, and once on DD-WRT, but that build was community-modded to enable the support using scripts (no GUI access to IPv6 stuff) and while it worked just fine, I'd say that it was not representative of what modern SOHO gear can/can't do with IPv6.

From watching the forums, I'd say that one of the biggest hurdles end users face is the sheer number of ways that various ISPs choose to deliver IPv6 - many of these methods were blatantly indicating to me that the ISPs had no clue how to think in IPv6 and that they simply tried to do the same stuff as they did in v4, most eggregious of all is giving users a routed public /29 of IP space but only giving SLAAC-based access to v6 (no routed blocks of v6 space).

I think this is one of the biggest things that's kept the end-user market from settling into a groove where IPv6 is concerned. Personally, I'm connected to Comcast at home, and they use DHCPv6-PD to enable IPv6 to the home. By default, they hand you a single /64 but on their community, it was announced that you can include a prefix-hint to receive a /60 block which is what I do with my Mikrotik router. It works perfectly, and I've noticed that they've gotten more stable regarding WHAT prefix they give you. (earlier on, my /60 would change very frequently, which doesn't bother me personally, but I don't have any devices that having their addressing change would bother me - and I think that I'm in the minority of potential IPv6 adopters at home in that regard).

While I completely understand the group whose ethos can be described as "IPv6 NAT - not even once!" - I think having some IPv6 nat in the toolbox is going to be necessary to help end users work with a variety of delivery mechanisms until later down the road when the industry has gotten more standardized. This is especially true of 4G/LTE services which seem to expect you to hop on, use SLAAC to get your host ID from the general /64 on the airwaves, and go to town. This is fine and dandy for phones and tablets, but completely un-usable for routers without NAT66 capability. (Granted, the thought of NAT66 makes me cringe, but speaking pragmatically - how else is one supposed to get onto LTE w/o this if the carriers won't route blocks to you?)

janisk · Mon Jul 03, 2017 10:00 am

To chime in thins great discussion on IPv6:
First sorry for the "fixed in v7", but this is all we have at the moment.

Second more on point about IPv6 features in RouterOS:
*) Use CHR to test tings out with minimal investment (like hardware to run GNS3 or anything else capable running CHRs) actually runing the network will help understand certain things and differences between IPv6 and IPv4 networking.
*) DHCP client for IPv6 in the RouterOS is capable to get address and prefix if provided, so, you can have WAN IPv6 address if requried and prefix for the LAN (should it be called LAN anymore?)
*) DHCP-PD server is capable to give out prefixes of /64 or bigger as the /64 is the minimum prefix to be given out.
*) full DHCPv6 server becomes a necessity only if you are faced with prefixes smaller than /64 and below that threshold SLAAC stops wrorking.
*) use from-pool "/ipv6 address" feature when dealing with dynamic prefixes.
*) DUID is generated first time when it is required. And that is when DHCP-client wants to get the address - it willl use the MAC address of the first interface to generate one. To change it you have to completely reinstall the software.

pe1chl · Mon Jul 03, 2017 12:48 pm

To chime in thins great discussion on IPv6:
First sorry for the "fixed in v7", but this is all we have at the moment.

It would be great when at least some of the features of IPv4 that are available in the kernel for IPv6 are made available in 6.40rc.
Like:
- ipv6 route rule
- ipv6 firewall nat (prefix translation only, similar to netmap)
- ipv6 firewall mangle (addition of some actions like mark routing, set priority)

It should make IPv6 more useful e.g. in cases where multiple internet connections or dynamic IPv6 prefix on internet are present.
These features should not require a lot of design and implementation effort as they are the same as the similar features in
IPv4 and the underlying kernel features are the same as well.

jmay · Mon Jul 03, 2017 6:19 pm

We've been a wisp for more than a decade at this point so we have a mix of CPEs. We started out as one of the original Canopy users before migrating to various other platforms. We still have thousands of users using the old Canopy and the only way IPv6 is ever going to work with them is by bridging their module and sending IP's to the customers router, which they supply themselves. So I cannot start this until I can make an MT router successfully send prefixes to things like Belkin and DLink. So far I have not been able to make this work.

If our entire network was MT this would be easy, but thats not the case. We have 18 MT routers that serve DHCP to various parts of the network so adding another router for DHCP purposes does not sound attractive.

If version 7 is suppose to fix a lot of this, do we have any idea when that will be released? I'm no longer in a big hurry. I've learned that I'll have to dual stack anyways so running out of IPv4 is going to be a problem for us one way or another. The cops won't be happy the next time they try to track someone down but our customers are going to have to share IP's. I don't see a way around that without spending a small fortune to buy some more from a 3rd party.

Mon Jul 03, 2017 8:35 pm

So I cannot start this until I can make an MT router successfully send prefixes to things like Belkin and DLink. So far I have not been able to make this work.

The thing to check is whether those devices support receiving IPv6 prefixes via DHCPv6-PD. If they don't support that, then they're not going to work using that mechanism, no matter what Mikrotik does or doesn't implement.

You'll probably need to have a bit of a hybrid approach if you're going to support a wide array of 'BYOD' routers at customers' premises. If your access-layer is a shared broadcast domain at layer 2, (hopefully there's some client isolation going on at layer2) then you may want to assign a /64 of public addressing onto such segment(s) so that CPE which expects to get an address from SLAAC and then do NAT66 can work properly... (ick)

Obviously there's static routing as a possibility - in fact, I suggest that you test this out as a sort of "hello world" in your lab - so that you can at least see the protocol working at some basic level.

idlemind · Mon Jul 03, 2017 11:34 pm

https://tools.ietf.org/html/rfc7084#section-4.2

I love when super smart people already document the necessary tech.

It would appear this RFC requires the WAN side interfaces to act as host devices, this is precisely the reason by default RouterOS (and others) don't listen to RAs. Thankfully I think that can be changed, sadly though it appears to be a global setting in the current RouterOS versions. It's required that only the WAN side act as a host.

/ipv6 settings set accept-router-advertisements=yes

I've got a prefix delegation lab setup in hardware. It's a mixture of RouterOS and Cisco gear and is IPv6 only (the mixture is simply because it's what I have handy). My first test was the cheapest router at Target, a Belkin N150. It failed miserably. I'll be trying a Netgear next I think. I'll let you know how that goes. Hopefully I'll be able to produce a reference architecture and a list of off the shelf routers that can be used.

I'm not currently testing DS-Lite. I'm personally focusing on IPv6 only to the CPE to see where compatibility for that is simply because any method whether public or CGN'd IPv4 will work regardless with any hardware today and it will either use or ignore IPv6. Personally looking for IPv6 only to eliminate the need to manage any IPv4 to the CPE and return to single stack operations to customers soon as possible. Leaving larger NAT64 boxes upstream in place until the IPv4 Internet is pronounced dead.

Edit: Updates to Hardware Notes for IPv6-only to CPE designs

IPv6-only to CPE
Belkin N150 (Target) - Unable to get a working IPv6 connection at all. Likely will retest further options.
Netgear N300 (Target) - Did not work without minor change. Had to login to the router web-admin page and enable IPv6. I chose "auto" not to be confused with SLAAC auto-configuration and it used RA to set a WAN address and fetched a prefix (/56 - my pool size) and assigned a /64 to it's LAN side. DNS worked and it was able to browse known IPv4 only sites without a problem. Literally only had to enable IPv6 on the web-ui. I'm not sure why it's not enabled by default.

pe1chl · Tue Jul 04, 2017 11:01 am

The problem is: when you use RA to get an address and router on the WAN side, you still don't have an address to use on the LAN side.
You would normally use a mechanism like DHCP6-PD to get that, but there are providers that don't offer this and in fact give each user only a /64.
This is difficult to handle with the MikroTik as there is no form of NAT functionality. You would have to try tricks with bridging or static address/route.

idlemind · Wed Jul 05, 2017 8:03 am

The problem is: when you use RA to get an address and router on the WAN side, you still don't have an address to use on the LAN side.
You would normally use a mechanism like DHCP6-PD to get that, but there are providers that don't offer this and in fact give each user only a /64.
This is difficult to handle with the MikroTik as there is no form of NAT functionality. You would have to try tricks with bridging or static address/route.

Yup, the document states the need for prefix delegation paired with the customer device listening to RAs on the WAN interface.

I agree with you on the /64 allocation being stupid but it should still work. Even on a MikroTik CPE. The DHCPv6-PD client will grab the /64 and a single LAN bridge could be set to dynamically pull an address from that DHCP-PD. I just verified a /64 with prefix-lengths of 64 will issue that single /64 to an interface correctly. Personally I'd hope an ISP provides nothing less than a /60 per customer.

pe1chl · Wed Jul 05, 2017 10:51 am

Remember a bridge operates at layer 2 so it is shared between layer 3 protocols like IPv4 and IPv6.
When you configure bridging for IPv6, it will be difficult to still get routing for IPv4. Which you probably require, because IPv4 NAT is part of routing.

However, when you get only a single /64 you can sometimes put it on the LAN (statically) and use only a link-local address (FE80::...) on the link to the ISP.
Then you can still route. This can work when the link to the ISP is actually point-to-point, e.g. PPPoE.

idlemind · Wed Jul 05, 2017 5:21 pm

Remember a bridge operates at layer 2 so it is shared between layer 3 protocols like IPv4 and IPv6.
When you configure bridging for IPv6, it will be difficult to still get routing for IPv4. Which you probably require, because IPv4 NAT is part of routing.

However, when you get only a single /64 you can sometimes put it on the LAN (statically) and use only a link-local address (FE80::...) on the link to the ISP.
Then you can still route. This can work when the link to the ISP is actually point-to-point, e.g. PPPoE.

I'm afraid I don't follow, if the /64 is delegated using PD then it will be assigned to a pool not to your interface. Like you said the WAN interface will then use link-local addressing. It's only a problem when a single address is assigned using DHCPv6 address assignment out of a /64 to the WAN interface not when a /64 is delegated. That said, like I mentioned earlier I really would shy away from handing out anything less than a /60 to permit capable routers and users to setup differing networks locally. A common example could be a guest WiFi network which comes with firmware in TP-Link or Asus I can't remember which.

jmay · Tue Aug 08, 2017 11:17 pm

Quick followup question:

I figured out I can manually enter an Routers IPv6 IP as my DNS server on a computer and it works just fine as a DNS cache router. I can also add that same IP to the DNS servers list and the router will hand that IP out to my clients. However, the router then constantly queries itself for DNS requests. (which makes me laugh for some reason) I'm thinking I could add 2 DNS entries, one with itself and one as our main dns server, but is there a more elegant way of doing this?

105547111 · Tue Aug 08, 2017 11:44 pm

To chime in thins great discussion on IPv6:
First sorry for the "fixed in v7", but this is all we have at the moment.
It would be great when at least some of the features of IPv4 that are available in the kernel for IPv6 are made available in 6.40rc.
Like:
- ipv6 route rule
- ipv6 firewall nat (prefix translation only, similar to netmap)
- ipv6 firewall mangle (addition of some actions like mark routing, set priority)

It should make IPv6 more useful e.g. in cases where multiple internet connections or dynamic IPv6 prefix on internet are present.
These features should not require a lot of design and implementation effort as they are the same as the similar features in
IPv4 and the underlying kernel features are the same as well.

YES this is needed badly. We have 3 IPv6 routes and do not have the ability of routing certain traffic to particular routes. due to lack of routing-marks and ability to use routing-marks in ipv6 mangle to mark traffic

How hard is that to implement ? There's already in IPv6 mangle mark-connection and mark-packet, we need routing-mark there and in IPv6 routes.

Sob · Wed Aug 09, 2017 12:46 am

... I'm thinking I could add 2 DNS entries, one with itself and one as our main dns server, but is there a more elegant way of doing this?

I don't think there's any good way of doing this with current RouterOS.

You can easily stop router from asking itself, just reject (not drop) packets to <router>:53 in output chain. It will still try, but will know immediatelly that it should try other resolver(s). But this will only work if other resolvers are IPv4 ones. With IPv6 resolvers, router will pass those to clients and they will bypass router when asking them directly. You could use the same trick as before and reject direct access to other resolver(s) from clients and they would be forced to use the only working one, i.e. your router. But I don't think it's a nice solution.

jmay · Wed Aug 09, 2017 12:51 am

Ok, I may just keep my clients using an IPv4 DNS for a while. I like caching at my routers because the network is so large and spread out these days that many customers have a long path back to our 2 main servers.

Thanks to everyone in this thread btw! We have about a dozen customers testing IPv6 right now with great results!

idlemind · Tue Aug 22, 2017 7:13 pm

*) full DHCPv6 server becomes a necessity only if you are faced with prefixes smaller than /64 and below that threshold SLAAC stops wrorking.

@Janisk, your view of "DHCP is only for address assignment" is flawed. Grab the closest 2 people to you in the MikroTik office and collectively lift their heads out of the sand whilst you pull yours out. The acronym literally tells you it, Dynamic Host Configuration Protocol. It configures many other things like DNS servers, NTP servers or any other number of DHCP option reliant features. This is especially important when you look at your implementation of DNS server discovery in RA. It pulls the servers directly in /ip dns and basically ignores the local recursive resolver. Seriously laughable. Get over your "Not Invented Here" views and implement a proper IPv6 DHCP server and fire anyone else that is on the SLAAC only train in 2017.

*) use from-pool "/ipv6 address" feature when dealing with dynamic prefixes.

@Janisk, we'd love to except we still cannot reliably request (hint) the network bits to be given out. The simplest example would be to match the network bits to the VLAN ID, VLAN11 = 2001:db8:aaaa:aa11::1/64 instead of whatever it decides to be as the router boots up. This is compounded by the lack of a DHCPv6 server that effectively updates DNS to allow me to ping by name. This is a feature lack in IPv4 and IPv6 and is currently only solved with 3rd party scripts. An absolute embarrassment if you ask me. Include DNSMASQ as your engine and update your licensing if you are simply unable to code it yourselves.

If you can't handle the heat of IPv6 in real life just let us all know. We'll kindly switch to another vendor now. Remember, customers are your bosses and we speak with wallets which are either louder than your voice to your boss leaving you without a job or the company will go out of business leaving you all without jobs. Personally, my wallet is getting pretty sick of IPv6 being the red headed step child of RouterOS.

Tue Aug 22, 2017 11:47 pm

Now there's a Jerry McGuire moment.

Agree 100%.

acruhl · Thu Aug 24, 2017 12:20 am

Wow, how did I miss this one?

Random thoughts:

o MikroTik's motto is "routing the world". Given that, why not take the lead on IPv6 deployment issues from the ISPs perspective using advice from some obviously loyal users in this thread? When there is an opportunity to lead, take it. If you need investment, get it. What's the worst that can happen?

o When I was first trying IPv6 at home, I had my MikroTik set up wrong so I tried an Asus (Linux?) and it "worked". I saw no ability to do firewalling or even know how IPv6 traffic was being routed/forwarded so I decided "yikes" and put it away. Should have tested it more thoroughly and I may still at some point. The LAN got a /64 and did SLAAC and it worked, that's all I know.

o My company is "large" (not an ISP). They have an internet facing IPv6 presence, which is good. But internally we have nothing. I manage some large networks and we have a hacked together static IPv6 address assignment along with SLAAC for end users. From my company's global perspective, they've rightly decided that SLAAC is bad, and I agree, it's for home users and/or anarchists as far as I can tell. Hopefully they will come out with a direction on this soon. DHCPv6 internally is the way forward.

o Can someone give me some undeniable evidence that NAT with IPv6 is a good thing? I could see ISPs that provide modem/routers to customers moving to it in a hurry because obviously anyone who needs real internet connectivity is a business and should be charged accordingly. This seems like a bad idea to me. It would simplify their (ISP) lives greatly as far as routing but it breaks the notion of what the internet was always supposed to be. I think people will roll their eyes back in their head when they read this but I can see it happening.

o Someone mentioned IPv6 compatibility with devices. My Amazon Fire stick uses IPv6 for Netflix and Amazon video if I remember right. Netflix for sure. I haven't really trolled all of my devices to find out which other ones use it. Seems like a no-brainer for game consoles but anyways.

Thanks for the education. The information one gets from a post like this is so much different than what I study in books and for the typical exams. IPv6 in the real world is so much different.

pe1chl · Thu Aug 24, 2017 12:05 pm

o My company is "large" (not an ISP). They have an internet facing IPv6 presence, which is good. But internally we have nothing. I manage some large networks and we have a hacked together static IPv6 address assignment along with SLAAC for end users. From my company's global perspective, they've rightly decided that SLAAC is bad, and I agree, it's for home users and/or anarchists as far as I can tell. Hopefully they will come out with a direction on this soon. DHCPv6 internally is the way forward.

Well, this is just an example of the disparity with reality in the IPv6 development community... maybe they are anarchists.
There are many other examples, like the "everything has to communicate with everything" adagium (hence the large number of addresses "required"), and the fabricated deployment requirements like "it is surely required at the time everyone gets a mobile phone" (while in reality mobile networks are amongst te last to adopt IPv6).
They have overlooked the transformation of internet from the peer-to-peer network it originally was into a client-server structured network where all the users communicate only with a comparatively small number of services.

o Can someone give me some undeniable evidence that NAT with IPv6 is a good thing? I could see ISPs that provide modem/routers to customers moving to it in a hurry because obviously anyone who needs real internet connectivity is a business and should be charged accordingly. This seems like a bad idea to me. It would simplify their (ISP) lives greatly as far as routing but it breaks the notion of what the internet was always supposed to be. I think people will roll their eyes back in their head when they read this but I can see it happening.

There is another thread with a good discussion about IPv6 NAT.
There is no requirement for many-to-1 NAT as is usual in IPv4, but there is a requirement for 1:1 NAT ("prefix translation", only the network part of the address is translated).
This is useful e.g. when:
- your IPv6 address is dynamic and you want to use fixed addresses on your LAN
- you have several IPv6 internet connections and you want to do load-balancing and failover (for outgoing connections) similar to what is possible with IPv4 NAT.

acruhl · Thu Aug 24, 2017 5:19 pm

Yeah, I should have specified. 1 to many is not needed, prefix translation is. Companies will merge, and address spaces will need to be consolidated.

As far as SLAAC in a busniess setting, or what I'm doing specifically at work, I can't see it happening. It may work for general connectivity here and there. Each IP on the network where I am is a tracked asset and needs to be able to be identified by MAC, DNS, IP, RFID location, and whatever else they come up with. DHCPv6 is the right way to do it I think.

idlemind · Thu Aug 24, 2017 5:27 pm

Yup, the real answer is both should be provided whenever possible. SLAAC for address assignment works fine in almost all cases now. A lot of client operating systems now support DNS through RA as well but the ideal protocol for host configuration is DHCPv6. Being able to push out other supported options to clients that support them alone is a valid use case. Additionally, address assignment and linking a hostname to an IPv6 address with DNS to DHCP bindings (another much needed feature in RouterOS - look at DNSMASQ in my TP-Link on OpenWRT for $49.99).

Thu Aug 24, 2017 11:28 pm

My previous job was in the enterprise sector, and I can tell you that my boss would rather retire than allow SLAAC on the network. The IT department MUST know which device has which address at all times. Sure, the guest WiFi could use SLAAC, but that's the wild wild west network. The corporate network can't be all grab-n-growl, and oh by the way, if you want to register your hostname in DNS, then do so, but if not, that's okay too.... BZZZZT!

pe1chl · Thu Aug 24, 2017 11:33 pm

SLAAC was kind of acceptable until "Privacy Extensions" was added. Of course, even before that the chosen address based on the MAC was not really enforced.
Of course, when you want to run IPv6 on a business network you probably have a server where you can run DHCPv6 linked with DNS and maybe other services, and still route your traffic via a MikroTik router. A DHCP server linked to DNS on a router would be nice even for IPv4 at home, but it soon gets too limited in a corporate environment.

acruhl · Fri Aug 25, 2017 6:09 am

SLAAC was kind of acceptable until "Privacy Extensions" was added.

+1

I'm not really smart enough to be debating this among the rest of you, but I'm trying as hard as I can to learn this stuff.

I'm all for privacy but at some point I'm hoping to be able to trace an address back to a real person on networks I manage. Privacy extensions makes it really difficult. Maybe it's possible with extensive logging?

Doing something anonymously on my network is fine. Connecting to my network anonymously doesn't seem OK. Maybe I'm misguided on that one?

kamillo · Fri Aug 25, 2017 10:44 am

"Privacy extension" looks like invention for consumer end of the market not enterprise. In enterprise environment you can control your devices and disable "privacy extension".
But I agree with above comments. Proper DHCPv6 server implementation would be very welcome addition to RouterOS

pe1chl · Fri Aug 25, 2017 11:11 am

"Privacy extension" looks like invention for consumer end of the market not enterprise. In enterprise environment you can control your devices and disable "privacy extension".

Only when you have something like Group Policy in operation. There should have been an option in RA to disable it for a network, understood by all network stacks.
The RFC says:

Additionally, sites might wish to selectively enable or disable the
use of temporary addresses for some prefixes. For example, a site
might wish to disable temporary address generation for "Unique local"
[ULA] prefixes while still generating temporary addresses for all
other global prefixes. Another site might wish to enable temporary
address generation only for the prefixes 2001::/16 and 2002::/16,
while disabling it for all other prefixes. To support this behavior,
implementations SHOULD provide a way to enable and disable generation
of temporary addresses for specific prefix subranges. This per-
prefix setting SHOULD override the global settings on the node with
respect to the specified prefix subranges. Note that the pre-prefix
setting can be applied at any granularity, and not necessarily on a
per-subnet basis.

But then it does nothing to define such a mechanism in the protcol, it is apparently left to management settings of the device. Bad. Like so much in IPv6, no thought about practical usage.

kamillo · Fri Aug 25, 2017 11:32 am

The RFC (4941) part you are referring to uses world SHOULD so it is not compulsory to have that. Additionally the same RFC says (note world MUST):

Devices implementing this specification MUST provide a way for the
end user to explicitly enable or disable the use of temporary
addresses.

So event if there was something in RA to disable "privacy extension" on given prefix, according to above user MUST be able to disable/ enable "privacy extension" therefore any RA settings in regards to that would or could be ignored.

janisk · Mon Aug 28, 2017 2:43 pm

aren't you talking about these flags in RA configuration in RouterOS?

managed-address-configuration=no other-configuration=no

there are places where SLAAC is good and should be used. While as an example here - in a corporate network - DHCPv6 is a must. Deploying to end user, however, is IMHO a SLAAC space.

idlemind · Mon Aug 28, 2017 3:20 pm

aren't you talking about these flags in RA configuration in RouterOS?

managed-address-configuration=no other-configuration=no
there are places where SLAAC is good and should be used. While as an example here - in a corporate network - DHCPv6 is a must. Deploying to end user, however, is IMHO a SLAAC space.

Please explain what you mean by end-user. One of the largest ISP networks in the US, Charter, addresses my edge MikroTik with DHCPv6 address and prefix and not SLAAC.

Internally as an "end-user" with a TP-Link running OpenWRT on a default configuration it handed out addressing via DHCPv6 and updated local DNS to allow ping by name all while still allowing SLAAC for clients that only supported receiving an add address configuration in that fashion of course the DNS resolver update and ping by name function was lost.

Additionally, MikroTik's botched implementation of RFC8106 doesn't allow us to specify DNS servers. They simply regurgitate whatever is in /ip dns. I'd have to check but I don't think your implementation supports the domain search list options either.

Tue Aug 29, 2017 1:24 am

aren't you talking about these flags in RA configuration in RouterOS?

managed-address-configuration=no other-configuration=no
there are places where SLAAC is good and should be used. While as an example here - in a corporate network - DHCPv6 is a must. Deploying to end user, however, is IMHO a SLAAC space.

It would be nice to have the option to do something between "just use SLAAC" and "use an enterprise-class DHCP service"
Sure, SLAAC is just fine for the majority of home users who want to just plug and play - and only have one broadcast domain in their home. All that link-local discovery stuff will come to the rescue, but for anyone with anything more complicated than that, who wants to have specific assignments for home hosts, but don't want to run a dedicated DHCP+DNS system, it would be nice to have the same options in the IPv6 side of RouterOS that we have in the IPv4 side. For instance, I can have a device, say a printer, which is configured to use DHCP, but I make its lease static in the Mikrotik...

I can't do this in ROS IPv6. In fact, this is a more desirable function in v6 than it is in v4 because in IPv4, I'm 99.999999999% likely doing NAT, so my internal addressing will be constant. In IPv6, however, if my ISP (ahem - COMCAST - ahem) insists on DHCP-PD and will NOT make my /60 block a static assignment... then today's block won't necessarily be tomorrow's block.

This is a problem w/o per-host stateful DHCPv6 where I want a specific host address to be my printer.
W/o static addressing, then my printer is going to be 2001:db8:ba5e:cafe:0241:d3ff:fe41:cc09 (for instance). Let's say I don't want to have to remember all of that 0241:d3ff:fe41:cc09 part - I just want to make my printer be ::1000 - so it would be 2001:db8:ba5e:cafe::1000 - a much shorter thing to type and remember.

W/o stateful DHCPv6, this means I must go into the printer and configure it as a static IPv6 address. Then that night, the power goes out while I sleep, and the lease happens to expire, and when I wake up, my printer doesn't work. I find that my block is now 2001:db8:beef:face::/64 and that my printer's static IP configuration doesn't match, so I can't reach it anymore.

It would be nicer if I could make a static lease for the printer whose netblock was determined as coming from the interface's prefix, and the host-portion was static in the leases table.
That way, whenever my netblock changes overnight, my printer would be reconfigured to be 2001:db8:beef:face::1000 automatically.

Can't do that with SLAAC alone.

Of course, my print driver is still going to probably be pointing to 2001:db8:ba5e:cafe::1000 - which means that it would ALSO be nice if the Mikrotik DNS cache could insert local hostnames learned from the DHCP requests. So now, I can just set my printer as "myprinter.local" and set the DHCP server to create AAAA records for "hostname.local" where hostname is learned in the DHCPv6 request.

Tue Aug 29, 2017 1:34 am

"Privacy extension" looks like invention for consumer end of the market not enterprise. In enterprise environment you can control your devices and disable "privacy extension".
But I agree with above comments. Proper DHCPv6 server implementation would be very welcome addition to RouterOS

Privacy extension has everything to do with any network where SLAAC happens. If your host didn't use privacy extensions, then the final 64 bits of your IPv6 address would be unique to your device's MAC address no matter where it goes.

It would be more reliable than tracking cookies!

If your device's EUI64 host portion works out to be 02fc:21ff:fe40:12ac for instance.... then this is now your fingerprint on the entire Internet.
Take your device to the net cafe. Its IPv6 address would be netcafe:prefix:02fc:21ff:fe40:12ac
Take it to the airport. Its IPv6 address would be airport:prefix:02fc:21ff:fe40:12ac
Take it to your friend's house. It would become friends

prefix:02fc:21ff:fe40:12ac
See the trend?

So anywhere you go on the Internet, your traffic would be fingerprinted as being to/from your specific device, regardless of the routing prefix. That's why privacy extensions exist. It doesn't have to do with hiding from the local network administrator, who in theory can still see your MAC address on their own network, regardless of SLAAC - it's just more of a pain to track this in IPv6 when managed host configuration has been a standard thing for over 20 years now in IPv4.

You don't even need an enterprise network to disable privacy extensions. Just install a stateful DHCPv6 server for host addressing. Then in the router's RA messages, specify managed-address-configuration=yes (this means SLAAC is disallowed, use DHCP to learn your address). Of course the host could still theoretically do SLAAC anyway, or just static configure its IPv6 address, but if you also have anti-static address measures in place, then this would mean that you must use DHCPv6 - and managed address assignment won't follow EUI64 or privacy guidelines. It will just pick host addresses from the pool as it would with IPv4. You could even disable RA on your LAN, which would force devices to use DHCP.

Who is online