My new provider is only offering DS-Lite (provider NAT IPv4 and /56 IPv6 prefix) so I have to deal with IPv6 now. To be honest I've always tried to avoid IPv6 because it's so much more complex than IPv4 to me.

The goal: Get a global IPv6 address for my server to make it available from outside. For IPv4 reachability I'll later on use a VPS with fixed public IPv4 address that forwards traffic to my IPv6 address.

Testing scenario: RB4011 with FW 7.1.3. Linux Mint 20 desktop pc in VLAN "MGMT_VLAN" with Dual-Stack configured running a simple webserver.

The problem: The PC is only getting a link local fe80 address. Somehow neither SLAAC nor DHCPv6 are working. Btw. also treid with Win10. Same result.

What I tried so far:
- Create DHCPv6 Client on WAN interface with "Rapid Commit" and "Request prefix" checked) to get the prefix from my provider
- Assigned an IPv6 address to the VLAN (currently MGMT as my desktop is in that VLAN) and checked "Advertise"
- Activated Neighbor Discovery on VLAN

The router successfully got the prefix from the ISP. From what I understood with these configuration steps my PC should already get the prefix via SLAAC and choose an address from the pool autonomously. Am I wrong? I'd prefer using SLAAC (stateless configuration) over DHCPv6 (stateful configuration). Is this a good idea for my scenario? Did I miss something?

Strange thing: Neighbor Discovery Prefixes show an invalid entry for my bridge. Should I be worried?

One more thing: Somehow setting ::1 as the IP address on the router made more sense to me. But that fails with the message that address with prefix length different from 64 can't be advertised.

Providing the configuration rather than a few screenshots would be better.

Firstly you need you an globally unique address on the WAN port and a default route so the router itself can access the internet.

As the WAN connection appears to be IPoE the correct method to obtain the default route is to use received router advertisments (RA) which unfortunately are not displayed by RouterOS, as discussed in other forum posts. The default IPv6 settings include forward=yes and accept-router-advertisements=yes-if-forwarding-disabled, so as you are forwarding you need to set accept-router-advertisements=yes.

The DHCPv6 client should typically request both an address and prefix, unless the ISP is using one of the prefix addresses for the WAN.

If the ND entry is showing invalid something is wrong with the configuration. What size pool are you receiving? The subnet address should not be all zeros, this is a reserved address. You can use ::1, or similar, if you want a specific fixed address, otherwise use the EUI64 option to generate an address automatically from the interface MAC address.

Mikrotik only provide prefix delegation in their DHCPv6 server, it cannot assign addresses so you have to use SLAAC unless you have something else providing a DHCPv6 service for your LAN devices

Few things:

- Prefix on bridge1 must come from somewhere, it has D flag, so it's dynamic, probably from another address on bridge1.
- You can use ::1, but you need to enter ::1/64.
- You shouldn't need public address on WAN, link-local is enough. And even if it wasn't, it wouldn't influence whether LAN devices get addresses or not.

I'd try:
to see if router tries to send something. Lower RA Interval in ND, so you don't have to wait for too long to see it. Another way is packet sniffer on client to see what's going on there.

Just a quick update...Thanks for your help so far. I made some changes in the configuration like you suggested and already get an IP on my PC and could ping the router.
I'll do some more tests and come back with my configuration and probably more questions tomorrow

The main difference seems to be where the IP address is assigned to.
After adding an EUI64 address on the MGMT_VLAN interface with Advertise checked the PCs received the prefix and got an IP. Pinging the router from the PCs is possible that way. But pinging external IPv6 addresses is not possible at all. Not from the router itself nor from any PC.

As soon as the interface which the IP is assigned to is switched from MGMT_VLAN to WAN(aka ether1) is is possible to ping external IP addresses from the router itself. But then the PCs don't get a global IP anymore.

Btw: The invalid something message in Neighbor Discovery Prefixes was displayed because the IP with "Advertise" checked on was assigned to ether1(WAN). That is probably not a good idea. It disappears as soon as Advertise is deactivated or the interface is switched to the MGMT_VLAN.


@Sob you said public address on WAN isn't required, link-local is enough. Not really sure I got the point. Let's say the public IP is now assigned to the MGMT_VLAN interface. PCs and router can talk to each other. How do packets get routed to the internet when ether1 doesn't have public IP?

The default firewall rules drop forwarded traffic arriving through any interfaces not in the LAN interface list.

Routing is hop-by-hop so routes via link-local addresses are fine, if you check the routes on your PC the default route (::0) will be to the link-local address of the Mikrotik interface. The router itself can't access the internet without a GUA.

Edit: With accept-router-advertisements=yes receiving a Router Advertisment containing prefix information (they all should) and the autonomous address-configuration flag set the WAN interface will automatically be assigned a GUA formed from the prefix and EUI-64 address generated from the interface MAC address, in just the same way non-router endpoints such as PCs would. Note this RA prefix is not the same as that obtained through DHCPv6 prefix delegation.

If not using RAs from the ISP (e.g. using PPPoE WAN connection with add-default-route=yes and static IPv6 addresses) having no GUA on the WAN interface appears to be OK as the first/lowest GUA assigned to the internal LAN(s) is used as the source address (using RouterOS 6, the behaviour with 7 may be different).

You are right. On my PC the default gateway is the fe80 address of the Mikrotik.
"****:****:*****:*****" -> My global prefix.

(base) joka@joka:~$ ip -6 route show
::1 dev lo proto kernel metric 256 pref medium
****:****:*****:*****::/64 dev enp37s0 proto ra metric 100 pref medium
fe80::/64 dev enp37s0 proto kernel metric 100 pref medium
fe80::/64 dev enp37s0.99 proto kernel metric 256 pref medium
fe80::/64 dev br-6f4d730824f1 proto kernel metric 256 pref medium
fe80::/64 dev docker0 proto kernel metric 256 pref medium
fe80::/64 dev vethb82a368 proto kernel metric 256 pref medium
fe80::/64 dev veth5889563 proto kernel metric 256 pref medium
fe80::/64 dev veth8dc7791 proto kernel metric 256 pref medium
default via fe80::de2c:6eff:fe18:caa dev enp37s0 proto ra metric 20100 pref medium

When trying to ping the external server from my PC it says "destination not reachable". Mikrotik log shows:

DROP IPv6 input: in:MGMT_VLAN out:(unknown 0), src-mac 96:ea:2a:f1:50:79, proto ICMP (type 135, code 0), ****:****:*****:*****6bb0:904:d467->ff02::1:ff18:caa, len 32

This looks more like my PC has sent the ping from its GUA to the GUA address of the Mikrotik on the MGMT_VLAN.

These different IPs per device still don't make sense to me. So the theory would be like this: You can sent a packet to an external GUA from the PC with the link-local address (LLA, fe80:something) to the LLA of the Mikrotik and it will forward it to the external GUA?! And then then the system with the external GUA will see the GUA of the PC as the source address, send the packet with destination PC GUA to the Mikrotik which will forward it to my PC via LLA?


But even communicating via LLA seems to be failing so far.
Mikrotik is showing fe80::de2c:6eff:fe18:caa/64 as LLA on the MGMT_VLAN.

The PC's NIC has

inet6 fe80:e92c:55cf:1315/64 scope link noprefixroute
valid_lft forever preferred_lft forever

When trying to ping Mikrotik's LLA from the PC the result is "The argument is invalid"
(

base) joka@joka:~$ ping -6 fe80::de2c:6eff:fe18:caa
PING fe80::de2c:6eff:fe18:caa(fe80::de2c:6eff:fe18:caa) 56 Datenbytes
ping: sendmsg: Das Argument ist ungültig
ping: sendmsg: Das Argument ist ungültig
^C
--- fe80::de2c:6eff:fe18:caa ping-Statistik ---
2 Pakete übertragen, 0 empfangen, 100% Paketverlust, Zeit 1015ms

Btw: The LLA of the Mikrotik seems to be the same for all VLANs. Totally lost

****:****:*****:*****::/64 dev enp37s0 proto ra metric 100 pref medium
fe80::/64 dev enp37s0 proto kernel metric 100 pref medium
fe80::/64 dev enp37s0.99 proto kernel metric 256 pref medium
default via fe80::de2c:6eff:fe18:caa dev enp37s0 proto ra metric 20100 pref medium

So this PC is picking up RAs from the mikrotik on the base interface, nothing on VLAN 99.

When trying to ping the external server from my PC it says "destination not reachable". Mikrotik log shows:
DROP IPv6 input: in:MGMT_VLAN out:(unknown 0), src-mac 96:ea:2a:f1:50:79, proto ICMP (type 135, code 0), ****:****:*****:*****6bb0:904:d467->ff02::1:ff18:caa, len 32

This looks more like my PC has sent the ping from its GUA to the GUA address of the Mikrotik on the MGMT_VLAN.

No that is a NS (Neighbour Solicitation) message arriving on the MGMT_VLAN interface destined for the Mikrotik itself. Do not block any IPv6 ICMP packets unless you understand the implications.

These different IPs per device still don't make sense to me. So the theory would be like this: You can sent a packet to an external GUA from the PC with the link-local address (LLA, fe80:something) to the LLA of the Mikrotik and it will forward it to the external GUA?! And then then the system with the external GUA will see the GUA of the PC as the source address, send the packet with destination PC GUA to the Mikrotik which will forward it to my PC via LLA?

No. The PC uses a GUA as the source address, the packet is sent to fe80::de2c:6eff:fe18:caa through the enp37s0 interface (from default via fe80::de2c:6eff:fe18:caa dev enp37s0).

A device can have many GUAs, and especially when privacy extensions are used - with EUI-64 addresses formed from a MAC address you have the possibility to track that MAC address. Devices can generate multiple temporary addresses for outbound connections to overcome this.

But even communicating via LLA seems to be failing so far.
Mikrotik is showing fe80::de2c:6eff:fe18:caa/64 as LLA on the MGMT_VLAN.

When trying to ping Mikrotik's LLA from the PC the result is "The argument is invalid"

Btw: The LLA of the Mikrotik seems to be the same for all VLANs. Totally lost

Link-local addresses are not unique, they have to be qualified with the interface. As an analogy if you had several appartment blocks then saying 'deliver this to number 7' is impossible,you have to say 'deliver this to number 7 in block X'. So
ping -6 fe80::de2c:6eff:fe18:caa%enp37s0
and
ping -6 fe80::de2c:6eff:fe18:caa%enp37s0.99
will send packets out of different interfaces.

Ah thanks for the clarification. Pinging the fe80 with %enp37s0 is working as expected.

From my PC I can now ping the fe80 address of my router. The router's ip within the /56 prefix that I've attached to my VLAN interface and the public IP address (outside the /56 prefix) that the provider assigned to the router.

What's still not working is pinging external IPs from my PC.
I tried to traceroute the external IP and it stops after the first hop. The first hop is the IP of my router within the /56 prefix that I've assigned to the VLAN interface. I would have expected the first hop to be the fe80 address of my router. Am I wrong here?

(base) joka@joka:~$ traceroute6 2a02:2e0:3fe302:0:0:0
traceroute zu 2a02:2e0:3fe302:0:0:0 (2a02:2e0:3fe302::) von ***MyPublicPrefix***:e118:547:f12a:8a33, 30 hops max, 24 byte packets
1 ***MyPublicPrefix***:de2c:6eff:fe18:caa (***MyPublicPrefix***:de2c:6eff:fe18:caa) 0,2665 ms 0,2236 ms 0,2248 ms
2 *^C

The drop rules of the IPv6 firewall have a log. I don't see any logs of the drop rule while pinging.

IPv6 isn't just IPv4 with larger addresses, some of the underlying mechanisms are different.

The outbound packet from PC to Mikrotik is sent to the default gateway, which in this case the the Mikrotik link-local address via a specific interface.
As the first traceroute packet will have a TTL of 1, and would become zero when routed on the next hop, the Mikrotik will form a TTL exceeded reply to the source address ***MyPublicPrefix***:e118:547:f12a:8a33, and as it has a directly attached interface with a GUA ***MyPublicPrefix***:de2c:6eff:fe18:caa will use that as the source address of the reply.

If you can ping external sites from the Mikrotik itself then it could be firewall rules. Otherwise if your provider uses one of the /56 provided by PD for the WAN this will break routing if the /64 used by the WAN and your LAN happen to be the same, see https://www.ripe.net/publications/docs/ ... -user-cpe- for a description of the issues.

As there some annoyances with how Mikrotik assign IPv6 addresses from a pool, in particular you can not specify a hint as to which of the delegated prefixes to use on a specific interface, as discussed in other forum posts. If you have been assigned static IPv6 addresses you could set them manually on your LAN interfaces, you may still have to request the prefix even if you do not use it as some ISPs only route to requested prefixes.

If all you have in forward chain (which is where packets passing through router go) is single drop rule, then guess where packets from PC to internet go... or better not go.

Oh man sure..I didn't have a log on the forward drop rule. After adding accept to forward between MGMT_VLAN and WAN pinging the external system is working.
Tbh I don't feel confident with the rules yet. I'll probably be carefull with opening stuff on the firewall until I learned more

But thanks for your help. I learned a lot about IPv6 this weekend. But still a long way to go

It's mostly the same as with IPv4, main difference is that you can skip NAT.

It varies. Not having NAT is good, the literal IP format takes some getting used to, but some of the under-the-hood stuff is quite different - Neighbour Discovery replacing ARP and IPv4 Router Discovery / Router Redirect, requiring multicast, DHCPv6 not having any concept of gateways....

Now I meant firewall, the rest has more differences, but if you're able to undestand IPv4, you'll be able to understand IPv6 too.