The ISP I use now have dual-stack IPv6/IPv4 connectivity, but I have a major problem using it in routerOS (RB751U-2HnD - routerOS version 6.4).

Here is what I have done to enable the IPv6 in my simple home network.

1. I run a DHCPv6-PD client on the PPPoE interface, and a random /64 was assigned and automatically put into a IPv6 address pool 'ipv6pool'.
2. I then advertise the /64 'ipv6pool' on the 'bridge-local' interface (via IPv6 ---> Addresses), and now all computers in the network are IPv6-capable, and working properly.
3. I can ping random IPv6 addresses out there (I used my IPv6-enabled US VPS for this), from both the computer and also from within WinBox.

The problem starts when I recycle the PPPoE connection, which will cause a new /64 to be assigned to me. The DHCPv6-PD client correctly retrieved the new /64, then correctly repopulate the 'ipv6pool' IPv6 address pool, and update the 'bridge-local' entry at IPv6 ---> Addresses. The computers in the network will then get new IPv6 addresses to reflect the new changes.

But at this time, none of the computers will be able to connect to the IPv6 Internet. I will not be able to ping my US VPS anymore, but I would be able to do so from within the WinBox application. If I want to restore the IPv6 connectivity in the computers within the network, I have to reboot the router to make it work again.

Is there any misconfiguration in my part here? Thanks.

Restarting the computer doesn't seem to work, after recycling the PPPoE connection. Damn, this is where I wish routerOS actually has a fully-featured DHCPv6 implementation.

How about the routes on both the computers and the MikroTik?

If you are talking about the IPv6 routes on the computer, there doesn't seem to be anything wrong with them. The only difference seen in the computers, after I recycle the PPPoE connection, is that there are new two entries in "/netsh interface ipv6 show route" command. The old depreciated routes are still there, but if I removed them, the connectivity problems will still exists.

And obviously, there should be no problem in routerOS' routing. The problem that plagues client computers when I recycle the PPPoE connection did not affect the router at all. For example, I can still ping my US VPS' IPv6 address and can read the routerOS manual.

Something must have gone wrong when routerOS advertised the new prefix to the computers.

I believe I am experiencing the same issue on my newly IPv6 configured RB2011UAS-RM. v6.4

I've been playing with IPv6 on the RB2011UAS for a little less than a week, and it's been working very well but today it just stopped.

My ISP also hands out a dynamic /64 IPv6 prefix for the PPPoE session and I get a static /56 IPv6 prefix for my LAN. My three IPv6 Win7 machines were working fine until today.

I've followed the excellent instructions here :-

http://into6.com.au/?p=214
http://into6.com.au/?p=244

I'll be following this thread with interest!!

Using this script allows me to force the stale IPv6 addresses in the adapter to be depreciated, keeping IPv6 connectivity alive without having to disable and enable the network interface.
My suggestion for Mikrotik is to force the depreciation of the older IPv6 address in the client's computer by sending a RA with prefered-lifetime and valid-lifetime of zero seconds for that stale prefix if routerOS detects that the prefix has changed. This would be valueable for those customers whose ISP only gives out dynamic IPv6 prefixes.

My suggestion for Mikrotik is to force the depreciation of the older IPv6 address in the client's computer by sending a RA with prefered-lifetime and valid-lifetime of zero seconds for that stale prefix if routerOS detects that the prefix has changed. This would be valueable for those customers whose ISP only gives out dynamic IPv6 prefixes.

This is, at least according to RFC6204 not optional. See my post here ... http://forum.mikrotik.com/viewtopic.php?f=2&t=73034