Are you guys for real? IPv4 reserves are almost depleted worldwide and we still don't have proper IPv6 dynamic routing in RouterOS?

OSPFv3 does not work when using VLAN on the same interface (apparently somebody forgot link-local addresses are, well, link local...)
RIPng is, well, RIP... And even if I run RIPng to distribute the loopbacks, BGP can't resolve recursive routes using link-local addresses.

What am I supposed to do?
Run RIPng in my whole network?
Add static routes for all loopbacks in all links?


Meanwhile 6.12 is fresh out:
*) updated timezone information;
*) www - added support for HTTP byte ranges;
*) lte - provide signal strength using snmp and make 'info once' work in console;

Are you guys for real? IPv4 reserves are almost depleted worldwide and we still don't have proper IPv6 dynamic routing in RouterOS?

OSPFv3 does not work when using VLAN on the same interface (apparently somebody forgot link-local addresses are, well, link local...)
RIPng is, well, RIP... And even if I run RIPng to distribute the loopbacks, BGP can't resolve recursive routes using link-local addresses.

OSPFv3 is supposed to use link-local addresses. What's wrong with that?

OSPFv3 gets confused when running on more than one VLAN with the same underlying physical ethernet interface - same MAC address, same link-local IPv6 address in different VLAN interfaces. This is a valid setup, different VLANs are different links after all (despite sharing the same MAC address), I do this often when I have a managed switch near the router - use just one gigabit port as a trunk with lots of VLANs between router and switch, most routerboards (before CCR) probably can't handle much more than gigabit of total real world traffic anyway.

As for proper IPv6 support, another thing lacking is Delegated-IPv6-Prefix RADIUS attribute for a dual-stack PPPoE server. All my customers have static IPv4 addresses, and I'd like to give them static IPv6 prefixes as well, for both the PPPoE link itself (Framed-IPv6-Prefix - this works) and delegated prefix for use behind the customer's router. Currently IPv6 PD over PPPoE only works with dynamic pools. If that feature won't be added anytime soon, I'm considering moving to accel-ppp on x86 Linux boxes as PPPoE servers.

That's why link local addresses are suffixed with %interface. Sounds like you need proper ipv6 training. Ospfv3 is working fine in production for me on vlan interfaces. It works exactly as other devices work with vlan interfaces.

There is a bug in OSPFv3, RIPng, BGP for years I guess. Please see:

http://forum.mikrotik.com/viewtopic.php?f=2&t=77371

We are working to solve these problems.

That's why link local addresses are suffixed with %interface. Sounds like you need proper ipv6 training. Ospfv3 is working fine in production for me on vlan interfaces. It works exactly as other devices work with vlan interfaces.

Well, more IPv6 training is certainly good, but I've already got 4 stars of IPv6 RIPEness so probably know a little bit... The issue is, something in the code ignores these %interface suffixes and only looks at addresses. I see someone else here has just confirmed the bug still present in 6.15 - I'm not the only one seeing it. And I haven't found a way to manually change link-local addresses, to make them different for each VLAN as a workaround. BTW, other vendors have such bugs too, interesting things like http://kb.juniper.net/InfoCenter/index? ... id=KB22439 can be found by google "ipv6 link local vlan".

I was more focused on the point that you were implying we shouldn't be using link local. When that's exactly what they are for. You could have an ospfv3 network spanning 50 nodes and only have global addresses at the ends. Thing of beauty.