Does anyone know if Mikrotik routers are compliant with RFC - Basic Requirements for IPv6 Customer Edge Routers (https://tools.ietf.org/html/rfc7084)?

I am doing preliminary work on a procurement and from my initial look it looks like Mikrotik is not? I would need a formal result, but not necessarily 100% if it was documented.

I'm not that up to speed on what exactly IPv6 "standards" are, but I have some (possibly naive?) opinions on using it as a residential end customer

That RFC document is about 4 1/2 years old now and I would suggest that stuff has changed.

For example, using a tunneling service to get IPv6 over IPv4 is nearly a non starter if it's still the case that video streaming services are detecting the tunnel and preventing traffic from reaching the customer endpoint. This was true for me as early as about 6 months ago.

I realize that streaming video isn't the "only" thing people would use their internet connection for, but it would probably be a large part of it, especially in rural areas.

This leaves us with dual stack, which is pretty solid and requires the end customer's ISP to support IPv6 natively. This should be increasingly common these days.

As a customer device, MikroTik does dual stack and DHCPv6 pretty well in my experience. Using it as a provider device for IPv6 seems to be hit or miss depending on what functionality is needed.

There are RFCs much older than 4 1/2 years, which are still valid, so that doesn't mean anything. Tunnels alone are not indication of anything either, it depends where they are connected to. Third-party services may have some problem, that's true. But tunnels mentioned in this RFC are meant for ISPs (and both are listed as optional, so it's not completely wrong that RouterOS doesn't support them). First, 6rd is not supported by RouterOS directly, and looks like it will become obsolete before MikroTik adds support. Even though it's basically just 6to4 with different configuration, so automatic support should be really easy to add. The other one (DS-Lite), will hopefully get added in the future (it's for IPv4 in IPv6-only networks).

As for the requirements, I'm not sure about exact details, but a lot (or even most) of them look like they should be possible to configure in RouterOS. One that's clearly not there (there was a thread about it just few days ago) is the one about changing prefixes, where router must advertise the previous one with zero lifetime, current RouterOS doesn't do that.

I agree that there are older RFCs, what I'm saying is residential support still isn't standardized from what I can tell. So you have to look at what direction actual implementations are taking rather than trusting a 4 1/2 year old RFC.

As for DS lite, the IPv4 space could actually start growing again soon, if it isn't already, as forward thinking ISPs start to make it obsolete. It seems like the world is right on the edge of large scale native IPv6 deployment to me. Certainly the mobile world is charging ahead in this regard. 5G could affect how residential service is deployed on a large scale when it becomes widespread.

Maybe this isn't relevant to the original post. But I think it's not productive to sit here today and try to look at something 4 or 5 years old and decide if it's relevant going forward for IPv6 deployment.

I don't believe that anyone will return any IPv4 addresses they have now. I wouldn't. Not until they are completely obsolete, and that will be many years from now.

And the other way to look at such few years old document is that everything in it should now be already supported for years (unless some if it turned out to be clearly dead end) and it's bad if it isn't.

If you knew that the addresses were worth more today than tomorrow, you might.

For example:

https://www.networkworld.com/article/31 ... buyer.html

There are many private companies that hold class A networks. I work for one of them. Combinations of NAT, IPv6, 464xlat and other schemes could mean that selling large blocks of public IPv4 addresses is viable and even profitable.

I realize this is getting off topic. But I really believe that IPv6 rollout will bring lots of change. Hopefully this whole one to many NAT mentality will change for good.

I wrote about returning them (for free), selling is completely different matter. If the price is right, and I'd knew that I wouldn't miss them, then why not. But I'd be really careful, seeing how today IPv6 is still viewed by so many people as something exotic.

I don't believe that anyone will return any IPv4 addresses they have now. I wouldn't. Not until they are completely obsolete, and that will be many years from now.

Are you sure you actually "own" any IPv4 address, i.e. you are in the position to (not) return it?
Most users do not own the IPv4 addresses they use, even when they are statically assigned to them.

For example, using a tunneling service to get IPv6 over IPv4 is nearly a non starter if it's still the case that video streaming services are detecting the tunnel and preventing traffic from reaching the customer endpoint.

Those streaming services do not detect (or want to detect) the tunnel as-is, but only because it can be used to spoof your actual location.
So when you get a HE tunnel it may be blocked by the streaming service who have simply blocked the entire network(s) that HE use to route their tunnel subscribers.
Tunneling techniques that are used to route IPv6 between subscribers and their own ISP, e.g. to overcome limitations of the subscriber network, are unlikely to be blocked by streaming services.

You got me. I can't return much myself, I'm not an ISP, university or any similar subject. I could just return public IPv4 addresses I have at home to ISP, and then there are few other places (companies) where I have a say about these things, but that's it.

But if I was ISP, got "my" addresses from RIR, and decided that I don't need them anymore, I could return them back. I'm under impression that it's how it should work, and that selling addresses to someone else should be actually against the rules. But I admit that I'm not watching these things very closely.