Almost there. Last issue. Everything works fine. For IPv4 the server is reachable by configuring NAT, firewall and the DNS A-record at my hosting provider.
For IPv6 struggling with changing prefix. My Internet provider gives me me a /56 IPv6 prefix. That allows me 256 sub nets of /64. At my hosting provider I configure the DNS AAAA for IPv6. All is well. Now the sub net of my RB750GR3 changes suddenly at the bridge level over the 256 sub nets.
My internet provider does not change the prefix of my IPv6 address (nor my IPv4 address) as long as I keep the same equipment. For IPv4 this works fine.
A good idea is a fixed IPv6 address for my webserver. Then everything is fine. How to solve this?
One thing is to make sure prefix used on server’s subnet is fixed. Next thing is to make server static IPv6 address from tge right IPv6 subnet.
Post the config, parts /ipv6 address, /ipv6 route and /ipv6 dhcp-client (or whatever method is used by ISP to dekegate you tge prefix).
I wish IPV6 was as simple and easy as IPV4! 
Actually it’s not that complicated either … it’s different than IPv4 indeed so one has to learn a few things anew.
I am looking forward to you holding my hand going through it. 
Thanks for your response.
Not sure if writing addresses here may harm me. Therefore Iput xxxx:xxxx as the first two block's.
Anyway the fixed part in the prefix is xxxx:xxxx:5c08:78xx/56
[cees08913bcf@MikroTik_RB750GR3] > ipv6 address print
Flags: D - DYNAMIC; G, L - LINK-LOCAL
Columns: ADDRESS, FROM-POOL, INTERFACE, ADVERTISE
ADDRESS FROM-POOL INTERFACE ADVERTISE
0 G 2001:xxxx:xxxx:7805:de2c:6eff:fe56:8f52/64 pool-ipv6 bridge-prive yes
1 G 2001:xxxx:xxxx:7809:2cc8:1bff:fee1:6e2c/64 pool-ipv6 bridge-gast yes
2 DL fe80::de2c:6eff:fe56:8f51/64 ether1 no
3 DG xxxx:xxxx:5c00:0:bd1d:1dba:e002:f609/64 ether1 no
4 DL fe80::de2c:6eff:fe56:8f52/64 bridge-prive no
5 DL fe80::2cc8:1bff:fee1:6e2c/64 bridge-gast no
[cees08913bcf@MikroTik_RB750GR3] > ipv6 route print
Flags: D - DYNAMIC; A - ACTIVE; c, d, y - COPY; + - ECMP
Columns: DST-ADDRESS, GATEWAY, DISTANCE
DST-ADDRESS GATEWAY DISTANCE
DAd+ ::/0 fe80::229:c2ff:fe01:b819%ether1 1
DAd+ ::/0 fe80::229:c2ff:fe01:b819%ether1 1
DAc xxxx:xxxx:5c00::/64 ether1 0
DAd xxxx:xxxx:5c08:7800::/56 1
DAc xxxx:xxxx:5c08:7805::/64 bridge-prive 0
DAc xxxx:xxxx:5c08:7809::/64 bridge-gast 0
DAc fe80::%ether1/64 ether1 0
DAc fe80::%bridge-prive/64 bridge-prive 0
DAc fe80::%bridge-gast/64 bridge-gast 0
[cees08913bcf@MikroTik_RB750GR3] > ipv6 dhcp-client print
Columns: INTERFACE, STATUS, REQUEST, PREFIX, ADDRESS
INTERFACE STATUS REQUEST PREFIX ADDRESS
0 ether1 bound address xxxx:xxxx:5c08:7800::/56, 1w3d16h19m57s xxxx:xxxx:5c00:0:bd1d:1dba:e002:f609, 1w3d16h19m57s
prefix
Thank you, Hope this helps.
I was hoping to see output of export command … print shows running config but there are number of ways to get there …
Worst part for me about IPv6 is that the IP addresses themselves are not easy to read or memorize. The simplicity of IPv4 address numbering and subnetting is part of what makes networking logical and fun for me. I actually see this as a major design flaw of IPv6, so much so that I don’t think IPv6 will ever defeat IPv4 in mainstream networks. Something else will come along before that can ever happen. Just my prediction (but I hope I am right). It’s unfortunate that IPv4 quantities are so finite/limited because apart from that, I see no reason to have an entirely new IP numbering standard. TL;DR? IPv6 sucks.
Problem with current RouterOS is that when you do:
/ipv6 address
add address=::1/64 from-pool=mypool interface=LAN1
add address=::1/64 from-pool=mypool interface=LAN2
...
selected addresses/prefixes don’t stick to interfaces. If next time interfaces happen to initialize in different order, prefixes will be different, even if prefix in pool didn’t change. Solution would be if RouterOS accepted hints, e.g. addresses like ::1:0:0:0:1/64, ::2:0:0:0:1/64. They could be combined with prefix, and you’d always get xxxx:xxxx:xxxx:xx01::1/64 and xxxx:xxxx:xxxx:xx02::1/64. Unfortunately, it’s currently not supported.
Solution/workaround for now is to assign addresses (semi-)manually. If you’re sure that prefix doesn’t change, just use manual config. If you know that it might change, use DHCPv6 lease script to update addresses. Check this one for inspiration. If you know that your prefix is not changing regularly and you just need to make sure that prefixes on interfaces survive reboots, it can be simplified (none of “/ipv6 nd prefix” stuff would be needed).
@anav: All the basics (addresses, netmasks, routes, firewall, …) are the same as in IPv4, only addresses are a bit longer. If you’re interested and create new thread like “I want to be friends with IPv6, but I don’t know how”, there’s good chance that someone will give you some pointers.
@fragtion: From all the things you may not like about IPv6, you chose the one that objectively can’t be much different. IPv4 is nice and simple, just four numbers 0-255. But that’s also the reason why it doesn’t have enough addresses. If you want more addresses, you must have either more numbers, bigger numbers, or both. It would be pointless to add just few addresses, e.g. fifth number 0-255, because if wouldn’t be enough. And even this one number would require to change all software, because old software wouldn’t understand it. So when you have to change everything anyway, you might as well add enough addresses to last forever.
The choice was 128 bits, which as 0-255 numbers would be sixteen of them. And addresses like 213.54.234.65.123.75.76.34.8.34.234.64.125.65.78.123 wouldn’t be great. Or you put two bytes together and go with eight 0-65535, so 54242.123.54346.2345.1.54324.34563.4234. Not great either. So the end result is this, but in hexadecimal form. You could say that 128 bits is too much. But even if you cut it in half, it’s still too long compared to IPv4. And going even lower defeats the original purpose.
Actually it is supported (or was around 6.45 when I was trying it), but the problem is that ROS only combines full “double octets” (including leading zeroes). Which is fine if prefix in pool is /48 (or shorter, but you can’t use whole prefix space this way) and you can then assign addresses in form ::1:0:0:0:1/64 (and the /48 prefix is prepended instead of leading colon). But if prefix is /56 or /64, ROS can’t combine exactly the prefix-length bits from prefix with the suffix set in address assignment command, ignoring leading bits as needed. To make it working regardless prefix length it should first perform (prefix AND “subnet mask”), then (postfix AND “negated subnet mask”) and only then OR them together.
But in essence the only way of doing it is the @sob way of static config. I’m usually combining the proper way and the static way … static for subnet with servers (things that need DNS records) and properly dynamic for subnets where IP addresses don’t matter (e.g. guest WiFi).
I found your old posts (1, 2) when I was looking for “address pool error: bad preferred prefix! (1)” and “address pool error: bad preferred prefix length! (1)” I’m getting, which is the same you had. Only thing that does sort of work is e.g. address=::2:0:0:0:1/64 with pool’s prefix-length=60, it keeps the “2”, but it also changes mask to /60, so it’s useless when I need to assign /64s to interfaces. I played with different prefix sizes in pool, but so far I didn’t find anything usable (aside from default sequential assignment, but the result there is “random”).
My experience is that when you add addresses to several interfaces (add address=::1 from-pool=poolname interface=bridge1) the addresses are picked from the pool in sequence of creation in ipv6->addresses and it is the same after every boot.
However, when adding/removing them (without removing all) there can be different subnet numbers.
Sorry for my misunderstanding:
/ipv6 address
add address=::de2c:6eff:fe56:8f52 eui-64=yes from-pool=pool-ipv6 interface=bridge-prive
add address=::2cc8:1bff:fee1:6e2c eui-64=yes from-pool=pool-ipv6 interface=bridge-gast
/ipv6 dhcp-client
add add-default-route=yes interface=ether1 pool-name=pool-ipv6 request=address,prefix use-peer-dns=no
There is no “/ipv6 route add route” in my configuration I am afraid…
Now what is your issue? With that config you should have static network addresses on each of these bridges.
Assuming you use SLAAC to send the info to the server, and you have disabled “privacy extensions” in the server (so it gets an address with …:xxxx:yyff:fezz:zzzz/64 just like your router) its address should be static.
As to the LAN addresses changing, what @sob wrote fully explains it.
The DHCPv6 and routing settings can be improved:
- setting add-default-route=yes on DHCPv6 client is not correct … this option sets DHCPv6 server’s address as default gateway which might work or it might not. IPv6 comes with ND mechanism, where routers announce their presence by sending out RAs (Routing Advertisements). Ideally every device should be using that information … and that includes routers for select interfaces (i.e. WAN interface). Unfortunately Mikrotik has global setting /ipv6 settings accept-router-advertisements, default calue effectively disables the feature. If you’re sure LAN devices won’t mess with this mechanism, set the option to yes, router will pick up default gateway from ISP’s RAs in a few seconds.
The problem with current ROS versions is that routes, accepted via RAs, are not shown so it’s hard to check it. - you most probably don’t have to request address (prefix would do), Mikrotik doesn’t need public IPv6 address on WAN interface
@pe1chl: OP’s settings don’t ensure that same /64 prefix is used on same subnet after router reboots (given that prefix delegated by ISP doesn’t change). It doesn’t happen often, but it can happen. Currently the only way to prevent it from happening is to set static IPv6 address to LAN interfaces, but that can break things in case when delegated prefix changes.
It is like I wrote above: it does not ensure it, in theory it might go wrong, but in practice it works right. That is, the local networks get a subnet address out of the obtained pool in the sequence they have been added (and which is the sequence they are listed when exporting /ipv6 address).
They only time it assigns another address is when you remove/disable one of the addresses and then add it back.
Try to re-read opening post of this thread with special attention to second paragraph. I believe it describes what’s bothering @OP and it’s what you claim it can happen but only in certain conditions. While I don’t know which of conditions you describe are affecting @OP, I’m just explaining that current ROS implementation sucks (as has been right from the start) and a possible workaround (which is not ideal).
Mind that even leaving server to self-construct IPv6 address (and hope it will come up with exactly the same every time) is also leaving room for failures … it would be really great if some points of uncertainty could be removed from landscape.
Well, as long as the “privacy extensions” are disabled in the server, so it will form the local part of the address from its MAC-address, it will come up with the same address every time until the ethernet card is changed.
OF COURSE you can set a static local part when you like that, details depending on the particular OS, which we do not know about.
I agree that it would be nice when it would be possible to specify a subnet number in each address assigned from a pool, but in practice it has not caused problems for me in 3 different setups (both at home and on two networks at work). The assignments from pool are always made in the order of their appearence in /ipv6 address. Maybe we need to find out in what cases that doesn’t work that way.
But, “randomly changing IPv6 address” usually is caused by “privacy extensions”, not by the router, in my experience.
There’s one possible problem with bridges I found. If bridge has default config that takes MAC address from one of ports, it can change as ports are added, removed, disabled or enabled. And when it happens, it triggers prefix change and it gets new one every time. It can be prevented by manually setting admin-mac=xx:xx:xx:xx:xx:xx for bridge.
It seems that this whole thing will need to be reworked eventually, because it’s quite limited. It’s not just this inability to select 100% stable prefixes (at least within received prefix from ISP). Another example is if I get e.g. /56 from ISP, I want router to assign few local /64s and also delegate few /60s to other routers. But if DHCPv6 client created only one pool with one prefix-length, it doesn’t seem possible to take both /64s and /60s from it.