IPv6 no routing for clients

Recently, I tried to get IPv6 connectivity working, with mixed results. Our ISP gave us static IPv6 addresses:

IPv6 Default Gateway : 2A00:1234:5:D00::1/56
IPv6 Network:          2A00:1234:5:D00::/56

So I configured pool, firewall and addresses on LAN and WAN (specific firewall rules to make it easier to count packages):

/ipv6 pool
add name=pool1 prefix=2a00:1234:5:d00::/56 prefix-length=64
/ipv6 address
add address=2a00:1234:5:d00::/64 interface=wan eui-64=no from-pool=pool1 advertise=no
add address=2a00:1234:5:d01::/64 interface=lan eui-64=no from-pool=pool1 advertise=yes
/ipv6 route
add disabled=no distance=1 dst-address=::/0 gateway=2a00:1234:5:d00::1 routing-table=main scope=10 target-scope=30
/ipv6 firewall filter
add action=accept chain=forward in-interface=wan out-interface=lan
add action=accept chain=forward in-interface=lan out-interface=wan
add action=accept chain=forward
add action=accept chain=output out-interface=lan
add action=accept chain=output out-interface=wan
add action=accept chain=output
add action=accept chain=input in-interface=lan
add action=accept chain=input in-interface=wan
add action=accept chain=input

Pinging Google on the Mikrotik router works as expected:

/tool ping 2a00:1450:4001:80e::2003
  SEQ HOST                                     SIZE TTL TIME       STATUS                                                                                          
    0 2a00:1450:4001:80e::2003                   56 117 912us      echo reply                                                                                      
    1 2a00:1450:4001:80e::2003                   56 117 876us      echo reply                                                                                      
    2 2a00:1450:4001:80e::2003                   56 117 929us      echo reply                                                                                      
    3 2a00:1450:4001:80e::2003                   56 117 864us      echo reply                                                                                      
    sent=4 received=4 packet-loss=0% min-rtt=864us avg-rtt=895us max-rtt=929us

Advertising on LAN also works as expected. To make my life a bit easier, I disabled randomized and temporary addresses on Windows machines:

Set-NetIPv6Protocol -RandomizeIdentifiers Disabled
Set-NetIPv6Protocol -UseTemporaryAddresses Disabled

So a Windows machine I am testing on gets the following address for example:

   IPv6 Address. . . . . . . . . . . : 2a00:1234:5:d01:1a03:73ff:fe40:5f7a(Preferred)
   Link-local IPv6 Address . . . . . : fe80::1a03:73ff:fe40:5f7a%22(Preferred)

However, pinging any outside host like Google from that machine does not work. The firewall rules show that a packet is leaving the router (rule “forward lan to wan”), but no answer ever comes back, in particular no answer gets sent to the machine in the local network. Machines get IPv6 addresses, yet all that is ever sent are SYN packets and one-sided ICMP tries.

What am I missing? I don’t use DHCP server - I am fine for hosts to auto-configure state-less within the /64 subnets - we got 256 of them with the difference between /56 and /64. I also tried assigning some other addresses on the Mikrotik from different subnets, and pinging with them as the source address, and that also works fine. I want to make sure I am not simply to dumb to configure the router before I contact my ISP.

Device: CCR1036-8G-2S+, ROS 7.7rc1

Since ISP expects you to use /56, it probably means it expects ARP replies for the whole /56 prefix … since you configured /64 on WAN interface and another /64 on LAN interface, clients of LAN won’t reply to ARP requests sent from WAN interface. Which means you’d have to enable proxy ARP on WAN interface.

The more proper way of configuring IPv6 is something like this:

  1. obtain /56 prefix from ISP’s DHCP server using /ipv6 dhcp-client and store it in address pool.
    Since ISP gave you static prefix, you can make note of it by setting prefix-hint property to value given to you by ISP.
    I guess this sets routing on ISP’s routers (behind the scenes) … it then uses your router’s WAN link-local address for routing packets belonging to your prefix towards your router.
  2. set /ipv6 settings set accept-router-advertisements=yes
    Default value is yes-if-forwarding-disabled and since router has forwarding enabled, it rejects RAs. And accepting RAs is the universal way of configuring IPv6 routing (if routing protocols, such as BGP or OSPF, are not used).
  3. set LAN interface with IP address from pool (you’re already doing it)

It then all depends on step #1 above. If ISP does support handing out prefixes via DHCP, then the res should work just fine. At least it does on a couple of ISP I have experience with and use IPoE (as opposed to PPPoE where routing is slightly different due to tight control over PPP link, the IPv6 address manipulation is the same).

Router actually only needs global IPv6 address for it’s high-level stuff, such as connections to DNS servers (either public or LAN), connections to MT download servers, etc. Global IPv6 address is not used in routing.

Hi, and thanks for taking the time to answer. There is no DHCP on the WAN interface. Just out of curiosity, I set up DHCP client, and it keeps stuck on “Searching”. It’s not a typical Internet provider, but a data center/colocation, although our office is directly connected via Ethernet. So there is also no DSL, cable or other PPP involved. We’re literally directly plugged into their routers.

I was under the impression that the ISP allocated the 2a00:1234:5:d00::/56 and expects me to subnet it to LAN/DMZ/guest/etc in the form of one or more /64 nets.

I set accept-router-advertisements=yes although that doesn’t make a difference. I simply don’t get why I am getting an answer to my ping on the router, but not when the ping originates from an internal host, despite the ping request leaving the WAN interface. The lan-in/wan-out forward rule counts packets, and I can see them leaving with Torch and Package Sniffer, but the wan-in/lan-out forward rule remains at zero. For example, I see:

lan rx 2a00:1234:5:d01:1a03:73ff:fe40:5f7a -> 2a00:1450:4001:80e::2003
wan tx 2a00:1234:5:d01:1a03:73ff:fe40:5f7a -> 2a00:1450:4001:80e::2003

But then the WAN interface never gets a reply from the public server. Not even sure if the ISP router forwards the initial ping request packet. Or if it’s just the answer that doesn’t get forwarded.

I think your config is wrong, because provider doesnt allow you to use :d01: etc.

So, correct config must be like this

1. set for ISP wan interface adddress 2a00:1234:5:d00::2/56
2. set gateway 2a00:1234:5:d00::1
3. set address for lan 2a00:1234:5:d00:2::1/64 and allow adverstie.

after that ipv6 in your network will work as needed.

Thanks for your reply, I am literally open to any suggestion. I did this - after removing all old addresses:

/ipv6 address add address=2a00:1234:5:d00::2/56 interface=wan eui-64=no advertise=no
/ipv6 address add address=2a00:1234:5:d00:2::1/64 interface=lan eui-64=no advertise=yes

Ping from router works as expected. Disabled and enabled IPv6 on Windows machine, it then got the address 2a00:1234:5:d00:1a03:73ff:fe40:5f7a, put ping still does not work.

Also, I can configure the router WAN interface for example as 2a00:1234:5:d05::2/56 instead of 2a00:1234:5:d00::2/56, and I am still getting ping replies, on the router. Pretty sure I am allowed to use the full 2a00:1234:5:d00-dff::/64 networks either way. In fact, the router configured with 2a00:1234:5:dff::2/56 still pings fine. Same goes for 2a00:1234:5:dff::/56 as all-null for the host seems to be allowed in the IPv6 protocol, contrary to IPv4.

I’d call my ISP in a heartbeat, if only those damned ping replies wouldn’t consistently arrive on the router itself, but never the internal machines.

It’s the same principle as in IPv4 with regard to subnetting. For example: your “ISP” assigns you 192.168.64/22 with their router sitting at 192.168.64.1/22. You decide to set things lite his:

  • WAN interface: 192.168.64.2/24
  • LAN interface: 192.168.65.1/24 (and use the rest of 192.168.65.0/24 as DHCP pool)

So what happens: your LAN client (let’s say it’s got 192.168.65.100) sends IP packet towards internet. According to subnet mask and routing it knows it needs to use 192.168.65.1 as gateway. Your router receives that packet and it passes it further to ISP gateway. So far so good. When reply packet (targeting 192.168.65.100) arrives at ISP’s router, it sees that according to its configuration (192.168.64.0/22) it should be directly deliverable and starts ARP who has procedure to find out MAC address of device using 192.168.65.100. And since actual device is behind the router, it doesn’t see the ARP whohas packet. If router has proxy ARP configured, then router would answer with MAC address of WAN interface, ISP router would pass packet to MT and MT would then route the packet via LAN interface to end device.

So enabling proxy ARP is one solution. It’s kind of messy (ISP router will have plenty of ARP table entries, all with MAC address of your router’s WAN interface).
The other solution is to agree with your “ISP” to configure their router so that addresses, given to you, will actually be routed towards your router … which likely means your router will ahve WAN IPv6 address outside of assigned prefix. But you really should discuss options with your “ISP”.

As to why pinging from router itself works: similarly to description above, but this time router uses own WAN address (192.168.64.2 /24) and when ISP’s router tries to deliver return packet, it asks for MAC address of device using address 192.168.64.2 /22 (which happens to be more or less the same as 192.168.64.2 /24 from subnetting point of view) and this time router replies with own WAN interface MAC address without any tricks (because that’s what IP devices normally do).

Your getting ping replies because that ip in your network \ your router. You can set any ipv6 address and always will got ping reply and RA will work. But if provider dont allow your ips - they will not work.
And ping from external ipv6 can be not avilable.

IPv6 addreses assigned manually or with Adversting sometimes must be updated at provider side, so them can be not avilable for first 10-30 minutes after setup.
In my case, i have manually set ip6 addres for DVR, and this address become accessible from internet only after 30 minutes.

And dont forget about windows firewall, win10-11 firewall block icmp requests by default, so ping wil not work till u enable it or disable firewall

I really don’t understand either post. I got a /56 network from my ISP, that leaves me with 256 /64 nets. I configured one /64 for WAN, one /64 for internal. Both the router and internal machines have addresses that still lie within the /56 network that my ISP gave me. What am I missing here?

Re: ARP/proxy ARP - I am well aware, and currently doing some tricks with it in IPv4 to connect DMZ machines that directly have their public IPs configured for convenience (as opposed to private IPs for DMZ machines and then doing address mapping), as we currently only have a single IPv4 (32 addresses) network, but like to have a router/firewall in front of it. Before that, we actually had a transfer net (basically a 4-addresses-net with only one gateway and one usable address), but it seems easier to use proxy ARP. Anyway, ARP doesn’t exist as such for IPv6, as I understand it, as it is all done with ND.

Regarding the pings, I am not pinging my own router - I am pinging a public server, so that only works as long as I put in valid address configuration and route/gateway. Maybe I wasn’t clear on that. I can see the right packets leaving the Mikrotik on the WAN interface, and replies coming back from Google.

Regarding the pings, I am not pinging my own router - I am pinging a public server, so that only works as long as I put in valid address configuration and route/gateway. Maybe I wasn’t clear on that. I can see the right packets leaving the Mikrotik on the WAN interface, and replies coming back from Google.


Try to find soruce of problem. Ask your provider wich networks is routed truth your address
If you got 2a00:1234:5:d00::/56 network, provider also must give you a gateway and routed ip address.
Usually gateway is 2a00:1234:5:d00::1, and routed address is 2a00:1234:5:d00::2, 
this means that all packets from your network and to your network will be pushed truth 2a00:1234:5:d00::2 on a provider side.

If you set for your interface 2a00:1234:5:d00::3 address, but at provider side is routed 2a00:1234:5:d00::2, - will be not possible connect to your network from internet, because provider route packets to 2a00:1234:5:d00::2, and this addres doesnt exist. 
With incorrect configuration you will be able only ping external ips from router, but dont be have incoming traffic to other devices.

i think you must request your provider to route a network for your internal network use behind your router

Yes. It appears the ISP has attached the /56 subnet directly to their end of the link, rather than routing it via a /64. Whilst it can be worked around with ND proxy or unnumbered links on equipment which supports it (Mikrotik don’t), it is really the wrong way to do it outside some datacentre/enterprise setups. It unfortunately crops up frequently, e.g. this thread https://forums.thinkbroadband.com/fibre/t/4689781-leased-line-ipv6-problem-with-unifi-udm-pro.html

Ideally your ISP would be following guidelines such as https://www.ripe.net/publications/docs/ripe-690 section 4.1, or similar.

I contacted the ISP, and one thing that isn’t necessary when communicating with our ISP is anonymization of the IP addresses (which I obviously did here “1234:5”), and one issue already was me transposing two digits on the LAN address anyway (45 vs 54). Although fixing that didn’t fix the issue, and I am sure this was a result of me trying a lot of variations on WAN/LAN addressing. I’ll make sure to update this post when a solution has been reached. Again, thanks for all the help provided so far.

It doesn’t help that the Mikrotik Winbox interface is as buggy as it is. I already removed the address prefix from the pool, as I also encountered the “IPv6 prefix increment on every edit” problem where the prefix would always increase by one whenever I looked the wrong way at the address GUI just when doing static address assignment. Also dynamic ND prefixes would get duplicated in the list. As far as I can tell right now, most stuff has to be done on CLI.

The ISP found an error with their own routing, and by their own words “assigned their router 2A00:1234:5:D00::1/125”, which to me looks basically like a transfer net that only includes their router, and our router’s WAN address, and now they route everything for 2A00:1234:5:D00::/56 to 2A00:1234:5:D00::0. Anyway, traffic in both directions works fine now, all d00-dff subnets are usable, and that is supposed to be how it works either way. Thanks for all the responses, although I see I am not the only one that still struggles to understand IPv6. Basically the initial provision information they gave me lacked information about a dedicated router address, and their router lies within the local address prefix they gave me. With my DSL at home for example, I get one external IP for my router, and then a completely different /56 prefix for internal usage.

Anyway, thanks!