ipv6 - unable to reach beyond mikrotik.

RouterOS General
1

Probably the most beaten up question here, however anything i’ve tried is unsuccessful. My setup : RB1100 with latest OS. ISP → ether6->RB1100->ether1 → Clients.
ISP gw = X:X:X::100:1
mikrotik ether6 = X:X:X::100:8
mikrotik ether1 = X:X:X::102::/64

The clients are getting ipv6 through RA, and are able to ping both interfaces of mikrotik, however they are unable to ping ISP gw. Mikrotik is able to ping the world and lan.

/ipv6 address
add address=X:X:X:100::8 interface=ether6
add address=X:X:X:102:: interface=ether1
/ipv6 route
add distance=1 gateway=X:X:X:100::1




[admin@tik1] /ipv6> neighbor print
Flags: R - router
 0 R address=fe80::4e4e:35ff:fe1b:dc41 interface=ether6 mac-address=4C:4E:35:1B:DC:41 status="stale"
 1 R address=X:X:X:100::1 interface=ether6 mac-address=4C:4E:35:1B:DC:41 status="stale"
 2   address=fe80::80f6:cace:7679:e156 interface=ether1 mac-address=C0:7C:D1:FC:DC:DE status="stale"
 3   address=fe80::185:cb1:debe:f4f4 interface=ether1 mac-address=10:78:D2:F2:D8:31 status="stale"
 4   address=fe80::adbd:6768:6d4b:aade interface=ether1 mac-address=D0:27:88:B2:19:7A status="stale"
 5   address=fe80::c84:e3ce:ff5a:67a9 interface=ether1 mac-address=40:98:AD:24:C5:CB status="stale"




[admin@tik1] /ipv6> route print
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable
 #      DST-ADDRESS              GATEWAY                  DISTANCE
 0 A S  ::/0                     X:X:X:100::1             1
 1 ADC  X:X:X:100::/64    ether6                          0
 2 ADC  X:X:X:102::/64    ether1                          0
2

Do you have any rules in the firewall? Maybe traffic gets blocked there.

3 
[admin@tik1] /ipv6> firewall filter print
Flags: X - disabled, I - invalid, D - dynamic
4

Has your ISP any route to your IPv6 prefix?

5

It does, i can traceroute fully to mikrotik’s wan “X:X:X::100:8” from digital ocean droplet.
The issue is that local clients cannot even ping the ISP’s gateway, while mikrotik can. It seems that mikrotik doesn’t forward anything ipv6 related outside.

6

No, you are doing wrong.
You have to traceroute to the IP on the LAN side of the mikrotik (not the WAN address)

7

What exactly am i doing wrong?
If i can reach to the ISP gw, it means the routing is setup on ISP site. The issue of me not reaching to the LAN site and back is what i am trying to solve. This configuration is entirely on mikrotik

8

You wrote you can’t reach the ISP gw from clients.
So, maybe, clients know how to send ping to the ISP gw, but the ISP gw doesn’t know ( = doesn’t have the route) where to send the reply.

So, maybe you should ping from Digital Ocean to you mikrotik LAN IP address, to verify my sentence.

Do you need more info?

9

Correct, the ISPgw isn’t aware of the LAN addresses. I cannot reach LAN port from the outside world.

Shouldn’t ND take care of announcing the neighbors to the ISPgw, as well as to the LAN? What am i missing? ND is configured as default.

10

Stop and consider basic routing (regardless of IPv4 or IPv6, the rules are the same).

Your ISP’s router must know that the next hop to reach X:X:X:102::/64. They must have a route in their router which states that the next hop to reach that destination (your LAN) is X:X:X:100::8. If they have no such route, then packets for your LAN’s network will not be routed to your router, which is one very likely reason that the LAN hosts cannot reach the ISP gateway or beyond. Even if your router is configured properly with the default GW, WAN address, etc, that will only guarantee delivery of your hosts’ outbound packets. For the Internet’s replies to these packets to be able to reach you, the entire internet must have routes pointing towards your ISP, which must have a route pointing to your router.

The way to test this:

  1. ping your WAN address from somewhere on the IPv6-enabled Internet (ping to X:X:X:100::8)
    (it sounds like you’ve done this)
  2. ping your router’s LAN address from somewhere on the internet. . . (ping to X:X:X:102::1 - if that’s the address assigned to ether1)
    If this works, then the routing is okay
    If it doesn’t work, then do some traceroutes…
  3. traceroute to X:X:X:100::8 - which should work. If it does, note the hops taken and then do a traceroute to X:X:X:102::2 - ::2 obviously won’t work unless you assign a host to ::2, but that’s not the point. When tracing to ::2, your router should show up in traceroutes as 100::8, whereas if you trace to 102::, it may not)

So if traceroute to X:X:X:100::8 works, but X:X:X:102::2 fails anywhere before 100:8, then note the address of the last hop with a successful reply. If this is the same as the last hop before X:X:X:100::8, then your router has a problem. If it’s any other router in the chain, then there’s a routing problem and you should call your ISP. Also, there’s a chance that the last hop will be your ISP’s router (the next-to-last hop in the trace to X:X:X:100::8), but that it replies with !H - which means unreachable. This would also indicate a routing problem.

Why would it? Does ARP cause routes to enter the routing table? Of course not. ND is essentially the same as ARP, so that’s not going to advertise routing to your ISP.

The ISP must have some sort of route pointing X:X:X:102::/64 via X:X:X:100::8 or via your Mikrotik’s link-local address (FE80::something)
Since I don’t know the mechanism where you received your addressing, I don’t know if this should be automated or if it’s been statically configured - but something’s not correct.

11

Correct, it does ping.

  1. ping your router’s LAN address from somewhere on the internet. . . (ping to X:X:X:102::1 - if that’s the address assigned to ether1)
    If this works, then the routing is okay
    If it doesn’t work, then do some traceroutes…

It doesn’t ping

  1. traceroute to X:X:X> :100:> :8 - which should work. If it does, note the hops taken and then do a traceroute to X:X:X:102::2 - ::2 obviously won’t work unless you assign a host to ::2, but that’s not the point. When tracing to ::2, your router should show up in traceroutes as 100::8, whereas if you trace to 102::, it may not)

So if traceroute to X:X:X> :100:> :8 works, but X:X:X:102::2 fails anywhere before 100:8, then note the address of the last hop with a successful reply. If this is the same as the last hop before X:X:X> :100:> :8, then your router has a problem. If it’s any other router in the chain, then there’s a routing problem and you should call your ISP. Also, there’s a chance that the last hop will be your ISP’s router (the next-to-last hop in the trace to X:X:X> :100:> :8), but that it replies with !H - which means unreachable. This would also indicate a routing problem.

traceroute6 to 100::8 –

11  X:X:Y:4000::12 (X:X:Y:4000::12)  111.297 ms  229.955 ms  140.161 ms
12  X:X:X:100::8 (X:X:X:100::8)  138.579 ms  111.668 ms  115.016 ms

traceroute6 to 102::2 –

11  X:X:Y:4000::12 (X:X:Y:4000::12)  116.016 ms  193.914 ms  160.188 ms
12  X:X:Y:4000::12 (X:X:Y:4000::12)  3235.98 ms !H  3299.79 ms !H  3271.96 ms !H

The X:X:Y:4000::12/126 is the WAN port of the ISP’s network termination box (essentially a router).
X:X:X:100::1 is LAN port of the ISP’s network termination box.

Per ISP docs X:X:X:100::/56 is essentially statically assigned to us. that brings us to :
X:X:X:0100::0002 - first usable
X:X:X:01ff:ffff:ffff:ffff:fffe - last usable.

12

Your traceroute shows exactly that the ISP router has no routes to you for your LAN addresses.

This makes zero sense. Here’s what it means: It means they’ve dropped your entire allocation onto their interface with you as a /56. (or at least that’s how I interpret your post). This is a bad configuration if true, or bad documentation if it’s not accurate about how they’re configured.

First things first, in IPv6, every network is expected to be a /64, so if they’ve numbered their interface with X:X:X:100::1/56, then they need to go back to IPv6 school on this alone. This means that 100% of your /56 is expected to be directly attached to the ISP router at layer 2 - i.e. no routers or anything on your side. Only a big honkin’ switch with up to 55-bazillion ports on it for hosts.

Secondly, even if they DID use /64 on their end, they would need to have some sort of route to the rest of your /56 via your router’s address. Did they not specify what address that should be? How did you decide to make your WAN address be ::8? Did they instruct this or did you just choose it for some reason? Apparently they did not give you a specific address to use if they said you can “just use anything you want from X:X:X:0100::2 .. X:X:X:01ff:ffff:ffff:ffff:fffe” This shows a complete lack of understanding of network-layer design on their part… unless your device is supposed to somehow proxy ND replies for the entire bazillions of addresses in a /56 - which would certainly fill up their router’s neighbor cache anyway. . . Or perhaps you’re supposed to use X:X:X:0100::2 as your router’s WAN interface and that’s what they’ve routed your /56 at. Double-check the documentation they gave you for such a piece of information. If they specify an address for your router to use on the WAN interface, then using it will be your fix.

But if they didn’t say “use X:X:X:100::2/64 as your router’s WAN address, and then feel free to assign anything from X:X:X:101:: through X:X:X:1ff:: to any router in your network” - then they’re not routing your block to you - they’re expecting to “arp” it to you. Which is silly.

And even the above solution (use X:X:X:100::/64 from your space as the attachment circuit and let you use the rest of the /56 for yourself) is sub-optimal IMO.

There should be some other range of addresses (not within your /56) used on the attachment circuit (your WAN), and they should route your /56 to you in its entirety via that attachment circuit.
The attachment circuit need not even have public IPv6 addresses on it at all - but it could be a /126, or even a /64 - but it should NOT come from your block. It should come from a specific range of IPv6 addresses in the ISP’s space designated for the purpose of attachment circuit addressing.

e.g. they should use 2001:db8:beef:cafe:1111:2222:3333:1000/126 as the attachment circuit with their address being …3333:1001/126 and your being …3333:1002/126
Your default GW = …3333:1001 and they route X:X:X:100::/56 via …3333:1002

… or they could use link-local addressing:
our router will be fe80::1 - please inform us of your router’s link-local addrss so that we may route your /56 to you. (or use dhcpv6-pd)

13

The documentation from ISP is sparse at best. I did verify that entire /56 range is allocated by assigning static ipv6 to the computer, connected directly to the ISP’s port:
i could reach X:X:X:100::2, X:X:X:101::1, X:X:X:102::1, X:X:X:103::1, X:X:X:1ff::fff0 from outside world. I had ndpd running on that ubuntu box.
What i deduce from probing around is following current network structure:

ISP -> X:X:Y:4000::12/126 (gi1) -> ONT -> X:X:X:100:1/56 (gi2) -> X:X:X:100:2/56 (ether6)-> RB1100 -> X:X:X:102::1/64 (ether1)

With this i can reach following from outside world:
X:X:Y:4000::12, X:X:X:100:1, X:X:X:100:2.
I cannot reach
X:X:X:102::1
To experiment, i’ve set up the following : radvd, ndpd, shorewall6 and net.ipv6.conf.all.forwarding=1 in ubuntu16.04 lts with the same addresses and ranges. It worked out without any issue, i was able to ping both WAN and LAN ports, as well as test laptop behind the ubuntu box @ some random X:X:X:102… address.
How can i bring the mikrotik to work in same manner?

14

Yes, you are right it isn’t optimal, but it is a viable solution for RIPE:
https://www.ripe.net/publications/docs/ripe-690/#4-1-4---64-prefix-out-of-the-ipv6-prefix-assigned-to-the-end-user

15

I found the same publication yesterday and was about to reply. However the topic of this issue is not to determine if ISP is right or wrong at allocating /56, but how to solve the problem at hand.
While on ubuntu box the default GW is set to the X:X:X:100:1/56, and “net.ipv6.conf.all.forwarding” is enabled, i have properly functional setup. I need to recreate the same in mikrotik.

16

This is probably long shot but can you check what you have in your mikrotik device in ipv6 settings.
There is setting called “ip-forward”, this should be set to yes.

https://wiki.mikrotik.com/wiki/Manual:IPv6/Settings

17

An horrible solution could be bridging/switching all interfaces on the mikrotik.
I suspect ubuntu do some ND proxy, but it is a weird solution, because you can have two different host with the same IPv6 address on the two side, LAN and WAN. With WAN-attached device preferred over the other one.

18

That was the first thing i checked :

[admin@tik1] /ipv6 settings> print
                       forward: yes
              accept-redirects: yes-if-forwarding-disabled
  accept-router-advertisements: yes-if-forwarding-disabled
          max-neighbor-entries: 8192
19

I would never consider bridge as a solution for the issue. However your post prompted me to check ubuntu setup throughly, and here is what i’ve found :
There is indeed ND proxy running on WAN interface that announces neighbors to the ONT side - https://github.com/npd6/npd6.
After some tcpdump analysis i found out, that the main thing it does - it advertises itself as router with ipv6 X:X:X:102::1 towards the ONT, thus providing the ONT with routing info to the X:X:X:102::/64.

Now my question is - how can i implement the same (RA to WAN port with LAN ipv6) on mikrotik?

20

i’ve narrowed the problem down to the ND configuration.
Essentially i have to define LAN prefix advertisement to WAN port under ND:

/ipv6 nd prefix
add autonomous=no interface=ether6 on-link=yes prefix=X:X:X:102::/64

However! In order for ONT to start routing to that subnet i have to set icmpv6.nd.flag.r to 1 (Router). Unfortunately the only two flags i can manipulate under ND are : L (on-link) and A (autonomous) …

@MikroTIK support : How can i implement this?