When I enable forward=yes - all IPv6 stops working.

The provider (Vultr) only supports IPv6 via ND.

# nov/17/2016 19:01:45 by RouterOS 6.38rc25
# software id =
#
/ipv6 settings
set accept-redirects=no accept-router-advertisements=yes forward=no max-neighbor-entries=8192
/ipv6 nd
set [ find default=yes ] advertise-dns=no advertise-mac-address=yes disabled=yes hop-limit=unspecified interface=all \
managed-address-configuration=no mtu=unspecified other-configuration=no ra-delay=3s ra-interval=3m20s-10m ra-lifetime=30m \
reachable-time=unspecified retransmit-interval=unspecified
add advertise-dns=no advertise-mac-address=yes disabled=no hop-limit=unspecified interface=ether1 managed-address-configuration=no \
mtu=unspecified other-configuration=no ra-delay=3s ra-interval=3m20s-10m ra-lifetime=30m reachable-time=unspecified \
retransmit-interval=unspecified
add advertise-dns=yes advertise-mac-address=yes disabled=no hop-limit=64 interface=ether2 managed-address-configuration=yes mtu=\
unspecified other-configuration=yes ra-delay=3s ra-interval=3m20s-10m ra-lifetime=30m reachable-time=unspecified \
retransmit-interval=unspecified
/ipv6 nd prefix default
set autonomous=yes preferred-lifetime=1w valid-lifetime=4w2d

That is correct, IPv6 routing is mutually exclusive with address assignment using ND.
This would not be possible anyway, because ND can only assign a network at the provider-facing interface,
so you would not have a second network for your LAN interface. And RouterOS does not support IPv6 NAT.

IPv6 routing is mutually exclusive with address assignment using ND

Is that specific to RouterOS?

I'm not getting my address via ND - just the route

I have CentOS boxes that get IPv6 connectivity on an interface with ND, and then route other v6 subnets to other interfaces. I'm just trying to reproduce that here.

If that's the case - shouldn't the option accept-router-advertisements=yes not exist?

IPv6 routing is mutually exclusive with address assignment using ND

Is that specific to RouterOS?

No

I have CentOS boxes that get IPv6 connectivity on an interface with ND, and then route other v6 subnets to other interfaces. I'm just trying to reproduce that here.

My experience is that once you enable forwarding on a Linux box, stateless autoconfigure is turned off.
Maybe it is possible to forcefully override that, but it is not the normal mode of operation.
When you get IPv6 via ND, how do you get the "other subnets" that you want to route and how do you assign their addresses to the other interfaces?
Normal way to do this is to use DHCPv6 PD, tell that to your provider.
At least if they do support multiple subnets, it would not surprise me when the next thing you find out is that you get only a single /64 from them!

We use BGP to advertise the /64's that we get assigned for the other subnets.

I'm just confused around why the option accept-router-advertisements=yes if the router won't use ND to get it's routing path when forwarding is on. There is a specific option for this scenario "yes-if-forwarding-disabled".

There is only one difference between a working IPv6 configuration and something that doesn't work. forward=yes It seems like something strange is going on. Enabling forwarding shouldn't completely break IPv6

The below does not work:

# nov/17/2016 19:41:41 by RouterOS 6.38rc25
# software id =
#
/ipv6 dhcp-server
add address-pool=pool_private disabled=no interface=ether2 lease-time=3d name=server_private preference=255 rapid-commit=yes
/ipv6 pool
add name=pool_private prefix=2001:19f0:6001:635::/64 prefix-length=64
/ipv6 address
add address=2001:19f0:6001:165:5400:ff:fe3f:e1d0/64 advertise=yes disabled=no eui-64=no from-pool="" interface=ether1
add address=2001:19f0:6001:635::ffff/64 advertise=yes disabled=no eui-64=no from-pool="" interface=ether2
/ipv6 nd
set [ find default=yes ] advertise-dns=no advertise-mac-address=yes disabled=yes hop-limit=unspecified interface=all \
managed-address-configuration=no mtu=unspecified other-configuration=no ra-delay=3s ra-interval=3m20s-10m ra-lifetime=30m \
reachable-time=unspecified retransmit-interval=unspecified
add advertise-dns=no advertise-mac-address=yes disabled=no hop-limit=unspecified interface=ether1 managed-address-configuration=no mtu=\
unspecified other-configuration=no ra-delay=3s ra-interval=3m20s-10m ra-lifetime=30m reachable-time=unspecified \
retransmit-interval=unspecified
add advertise-dns=yes advertise-mac-address=yes disabled=no hop-limit=64 interface=ether2 managed-address-configuration=yes mtu=\
unspecified other-configuration=yes ra-delay=3s ra-interval=3m20s-10m ra-lifetime=30m reachable-time=unspecified \
retransmit-interval=unspecified
/ipv6 nd prefix default
set autonomous=yes preferred-lifetime=1w valid-lifetime=4w2d
/ipv6 settings
set accept-redirects=no accept-router-advertisements=yes forward=yes max-neighbor-entries=8192

And the below works:

# nov/17/2016 19:43:34 by RouterOS 6.38rc25
# software id =
#
/ipv6 dhcp-server
add address-pool=pool_private disabled=no interface=ether2 lease-time=3d name=server_private preference=255 rapid-commit=yes
/ipv6 pool
add name=pool_private prefix=2001:19f0:6001:635::/64 prefix-length=64
/ipv6 address
add address=2001:19f0:6001:165:5400:ff:fe3f:e1d0/64 advertise=yes disabled=no eui-64=no from-pool="" interface=ether1
add address=2001:19f0:6001:635::ffff/64 advertise=yes disabled=no eui-64=no from-pool="" interface=ether2
/ipv6 nd
set [ find default=yes ] advertise-dns=no advertise-mac-address=yes disabled=yes hop-limit=unspecified interface=all \
managed-address-configuration=no mtu=unspecified other-configuration=no ra-delay=3s ra-interval=3m20s-10m ra-lifetime=30m \
reachable-time=unspecified retransmit-interval=unspecified
add advertise-dns=no advertise-mac-address=yes disabled=no hop-limit=unspecified interface=ether1 managed-address-configuration=no mtu=\
unspecified other-configuration=no ra-delay=3s ra-interval=3m20s-10m ra-lifetime=30m reachable-time=unspecified \
retransmit-interval=unspecified
add advertise-dns=yes advertise-mac-address=yes disabled=no hop-limit=64 interface=ether2 managed-address-configuration=yes mtu=\
unspecified other-configuration=yes ra-delay=3s ra-interval=3m20s-10m ra-lifetime=30m reachable-time=unspecified \
retransmit-interval=unspecified
/ipv6 nd prefix default
set autonomous=yes preferred-lifetime=1w valid-lifetime=4w2d
/ipv6 settings
set accept-redirects=no accept-router-advertisements=yes forward=no max-neighbor-entries=8192

I think the accept-router-advertisements option is buggy. I did quick test with latest CHR 6.38rc31 and it behaves like it's stuck on accept-router-advertisements=yes-if-forwarding-disabled, even though it shows something different.

Router didn't get address with this config, even though unconditional "yes" was used for the option: But it did get it with this one, even though I told it not to:

When I enable forward=yes - all IPv6 stops working.

The provider (Vultr) only supports IPv6 via ND.

Have a look here:

https://www.kernel.org/doc/Documentatio ... sysctl.txt

accept_ra - INTEGER
Accept Router Advertisements; autoconfigure using them.

It also determines whether or not to transmit Router
Solicitations. If and only if the functional setting is to
accept Router Advertisements, Router Solicitations will be
transmitted.

Possible values are:
0 Do not accept Router Advertisements.
1 Accept Router Advertisements if forwarding is disabled.
2 Overrule forwarding behaviour. Accept Router Advertisements
even if forwarding is enabled.

I think the accept-router-advertisements option is buggy

Is that the consensus? I also think there is some bug / issue at play when setting forward=yes that prevents the router seeking and honouring ND routes.

Can anybody think of a workaround, I can only get routes via ND - Vultr will not tell me what my next hop is and they insist their network can't support statically assigning the next hop.

It's just my observation from quick test, but if you can confirm the same behaviour, then it's probably a bug, and you should write to support to get it fixed. Unless we completely misunderstood something. There isn't much detailed info in manual, but listed options look very clear and self-explanatory:

- no - never accept RA
- yes - always accept RA
- yes-if-forwarding-disabled - accept RA when forwarding is disabled, otherwise don't

But is seems to ignore first two options when set.

seems to ignore first two options when set.

I've just spun up another clean CHR - accept-router-advertisements can not be changed. It is permanently set to "yes-if-forwarding-disabled".

Setting it to other options is reflected in the export, but the setting is not honored by the device. Rebooting the device makes no difference.

I've tried reaching out to support - but they are unresponsive.

(Also exists in RouterOS 6.37.1)

Can anybody think of a way around this? (Apart from a static IPv6 route - which Vultr don't support).

I can't use IPv6 without using ND for routing, it appears there is a routeros bug not allowing the setting to be changed, and I can't get a response out of support.

You could consider bridging instead of routing

Or just be patient. It might take few days before you get response from support. Even more before you get useful response. But if you describe everything in an easy to understand way, step by step instructions, pictures, ... it will be sorted out eventually. One way or another. So either fixed or you'll join others in anticipating of ROSv7.

It might take few days before you get response from support.

I don't know if he had sent the mail to support some time earlier, but his original post on this thread was sent
late in the evening Latvian time and he complained he did not get a response at the end of the night on the
next day. Not reasonable to expect a response in that time.

It's been over a week, and I've not had a response at all from support.

The forum post was made well after the initial support ticket. I think responding after one-to-two days is poor. Not responding after a week to a bug report - is something else.

To return to the topic / reason for the post - Can anybody think of a way to resolve this without having to rely on an unresponsive Mikrotik team?

Put the IPv6 Settings back to default.
What is the output of:
/ipv6 route> print
/ipv6 nd prefix> print
/ipv6 address> print

Can anybody think of a way to resolve this without having to rely on an unresponsive Mikrotik team?

You could consider talking to your ISP as they are using a nonstandard and unreasonable IPv6 setup.

I've tried asking Vultr to not use ND for routing. But they insist that there is no other way for them to do it.

@proximus - The exports are in this thread. They have all the changes from default. I've confirmed several times (as have others) on clean CHR images that the issue exists.
Was there something specific you wanted to check?

And does the address of their router (and your default gateway) change at all? Wouldn't it work (as a short-term solution, before you get anything from MikroTik) to look what current one is and set it as static?

Btw, looking at your previous config exports, if ether1 is WAN, I don't think you want advertise=yes there.

I don't know their first hop, or at least I can't see how to find it out.
It's hidden in a trace, and nothing appears in the routing table - it just 'works'
There's also nothing that appears in the neighbours table.

Yeah, current RouterOS with its "it's there but you can't see it" approach does not make it easy. Maybe connect something else for a while and have a look what the gateway is?

OK, maybe something useful, but most of it is already stated in this thread:
* changes that are made by accepting configuration from the RA are not shown anywhere in the RouterOS. (yes this is a known problem of the RouterOS, it will not be fixed anytime soon as that is not primary function of the router to act as an end-user node in IPv6 network)
* if they insist on ND you will get the address on your router - it will not help you in __ANY WAY__ to get IPv6 working on your local network behind the router. ND cannot do that.
* you have to accept redirects too and set the default gateway to prefixes anycast address. ND should take care of getting your packets to the internet via redirects.


If you want globally routable IPv6 addresses on your local network you have to get the prefix from your ISP and you have to get that prefix routed via your router. For this, you have to have DHCP-PD client configured on your router. You need the IPv6 prefix. And if you want to use SLAAC (read automatical configuration via RA etc. on your local network), you have to get /64 prefix at least.

If you want globally routable IPv6 addresses on your local network you have to get the prefix from your ISP and you have to get that prefix routed via your router. For this, you have to have DHCP-PD client configured on your router. You need the IPv6 prefix.

I fully agree with that. Unfortunately it appears Vultr is doing things differently. It is always hard to blame ISP's of
bad IPv6 rollout because this whole rollout process has been so badly thought out in IPv6 design and therefore
has been changed so often.
But I still recommend asking them for DHCPv6-PD.

Totally disagree, IPv6 specification is very thoroughly thought out. Basic things have not changed from 1998 when initial specifications were established. Yes, there are some changes to fix some broken stuff or stuff that does not work as expected.

Go and read this:
https://www.ripe.net/publications/docs/ripe-552

partiualry interesting are RFCs that they list that is used to make this document: here section 8. References - newest one is 10 years old.

Totally disagree, IPv6 specification is very thoroughly thought out. Basic things have not changed from 1998 when initial specifications were established. Yes, there are some changes to fix some broken stuff or stuff that does not work as expected.

Yet there is still no working way of setting things like a DNS server in a local network... One party uses method 1 (RA with later extensions) the other uses method 2 (DHCPv6)...
I know that the past years the standards are sort of constant, but what happened in the first 10+ years has made its definite mark.
It is not only within IPv6 but also the interoperability and migration from IPv4. I lost sight on how many different tunneling and translation method have been devised because nobody thought about this in the initial design.

recommendations on how to implement IPv6 in your existing Ipv4 network from RIPE has not changed ever. And that is - use dual stack. DNS address distribution via RA is also very old and a lot of devices support that. Except MS Windows, that requires DNS via DHCP-INFORM.

Both methods are available in the RouterOS. One can be configured directly, the other is workaround provided via DHCP-PD server.

I have configured both methods on a MikroTik router that serves a large number of visitors on a WiFi network,
a mix of the wellknown smartphones and some laptops. The DNS server sees exactly zero hits on its IPv6
address (counter on the IPv6 port 53 input rules remains firmly at zero), all the requests are made over IPv4.
But there is quite some IPv6 traffic, mainly to Google and Facebook.

So for now I count these solutions as "not working".

I need some advice on how to interface with Mikrotik support - I can't get a response out of them anymore - they are ignoring my emails.

The issue that has been outlined here, and in my (many) emails with them has been misunderstood. To my mind - it is very simple.

There is a bug in RouterOS.

The IPv6 option "accept-router-advertisements" is stuck permanently on "yes-if-forwarding-disabled".
Regardless of the setting value - the router is always set to yes-if-forwarding-disabled

We are NOT using SLAAC for IP assignment. We have multiple /64's that we need to route, and we use BGP to advertise those routes.
The "edge" router has a fixed address in a /64 range assigned to ether1.
The same "edge" router uses RA to find the next IPv6 hop.

Clients connect to an OpenVPN server on the edge router. The router then routes their IPv6 ranges to them over their OpenVPN link.

The problem:
Nobody at Mikrotik will take the time to understand that this is a RouterOS bug, instead repeatedly lecturing me about IPv6, addressing and routing.
There is nothing strange about what is being done here - we have CentOS boxes handling it for the moment because it's been over a month with no help from Mikrotik.
I'm waiting on a quote to change everything over to pfSense - but have been using Mikrotik hardware and RouterOS for a very very long time - I'd much rather stick with it and resolve this issue.

Does anybody have any advice on how to re-start the conversation with Mikrotik to get this issue resolved?

What's new in 6.38rc52 (2016-Dec-21 10:44):
*) ipv6 - fixed "accept-router-advertisements" behaviour;

Hey - did the OP find a solution to this? I to have an account with Vultr and trying to get IPv6 working..

Yes, after considerable finger pointing from Mikrotik - it turned out to be an issue with their implementation.
Now that the current firmware (the RC at least) has the fix - there are no problems with IPv6 in this situation.

HOWEVER - It should be noted that Vultr IPv6 is blacklisted at Google (Their entire ASN) So, trying to use Vultr for IPv6 Internet access - is somewhat of a waste given Google is such a big part of the Internet. Vultr could not care less about resolving the issue - they are blocked because they happily host servers attacking Google and breaching Google's terms of service.