I have been using Mikrotik for many years and I do not want to change it. I am very pleased with these devices. I have my own set of settings that I have been using for a long time.
Now that I have changed internet provider (Germany), this is the first time I have encountered IPv6 DS Lite. I’m a total beginner here, and I have no idea how to set this up.
I’m using currently RB5009UG+S+IN.
All of the information I have from the provider is:
PPP user: *****
PPP password: *****
VLAN ID data: 40
IP protocol: IPv6 DS Lite
AFTR address: aftr.prod.m-online.net
I would ask all good people who are willing to help me in this, step by step. I would be very grateful.
Once you have a working IPv6 connection it should be possible to use an IPIPv6 tunnel to connect with the AFTR, and as the ISP provides a DNS name something like:
/interface ipipv6 add name=dslite1 remote-address=aftr.prod.m-online.net
/ip address add address=192.0.0.2/29 interface=dslite1
/ip route add gateway=192.0.0.1
From the specifications you should not apply NAT, and for best practice apply suitable firewall rules.
I’m not aware of a cut-and-paste example. There are also various reported issues with IPv6 Router Advertisments and DHCPv6 Prefix Discovery over PPPoE connections using RouterOS v7, hopefully fixed in the recently released v7.2.
For IPv6 it should be a case of something based on the following which is for RouterOS v6:
disable or renove the IPv4 DHCP client on ether1
accepting router advertisments
/ipv6 settings
set accept-router-advertisements=yes
adding a VLAN interface on the WAN port
/interface vlan
add interface=ether1 name=vlan40-ether1 vlan-id=40
adding a PPPoE client on the VLAN interface
/interface pppoe-client
add add-default-route=yes allow=chap disabled=no interface=vlan40-ether1 name=pppoe-out1 password=XXXXXXXX use-peer-dns=yes user=XXXXXXXX
adding the PPPoE client interface to the WAN interface list
/interface list member
add interface=pppoe-out1 list=WAN
adding a DHCPv6 client to the PPPoE client interface requesting a prefix only, NOT adding a default gateway, and typically rapid commit
/ipv6 dhcp-client
add add-default-route=no interface=pppoe-out1 pool-name=pool-pd request=prefix use-peer-dns=yes
adding an IPv6 address from the DHCPv6 pool to the local LAN
/ipv6 address
add address=::1 from-pool=pool-pd interface=bridge
That should give you IPv6 connectivity, you should be able to successfully ping an address, e.g. 2a00:1450:4009:818::2003, from both the Mikrotik and a client attached to the LAN. Then add the IPIPv6 tunnel setup and disable the IPv4 NAT rule, the firewall rules may need a little tweaking.
It looks like this snippet here is still valid and works on the latest stable release (ROS 7.11.2 at the time of writing). However, I can’t seem to extract the name of the AFTR that my ISP should provide. So before I ask them, wouldn’t something like
:put ($options->"64")
spit out the advertised AFTR when run in the script attached to the DHCP client? According to RFC 6334, this should be an FQDN, but in my case the above doesn’t resemble that. Thanks in advance!
The :put command outputs data to the console, you could use :log instead.
Are you requesting the option? According to the specifications servers should not send the OPTION_AFTR_NAME unless specifically requested, so
/ipv6 dhcp-client option
add code=6 name=OPTION_ORO value=0x0040
The rather sparse documentation doesn’t make it clear if any other Option Request Options from the client, e.g. DNS servers, are combined with or overwritten so you may have to capture packets to check.
It also isn’t clear if the Mikrotik will translate the reply which uses DNS label formatting - the FQDN string aftr.example.com would be returned as the following bytes/characters
<0x04> a f t r <0x07> e x a m p l e <0x03> c o m <0x00>
Okay, I was of course using :log for testing as the script isn’t executed interactively. Maybe writing :put was a stupid idea … Anyway, it looks like the option is provided without an explicit request, but at least ROS only displays a flat string without any special characters. Copying the text from the log into a text editor shows some special characters, so that could actually be the AFTR FQDN.
Thanks for your help so far. Much appreciated! I’ll update my firewall rules now and see if the tunnel works. Quite confusingly, the status in the tunnel interface never seems to show “link up” or “link down”.
So it seems that for some reason or other the IPIPv6 tunnel does not come up - at least I can only ping the router’s IP address for that tunnel endpoint - not the “other side”. And as I mentioned above: There is no sign of anything connecting (or failing to do so) for the tunnel interface. However, I can ping6 the AFTR, so that’s working. Any idea how to debug this? TIA!
EDIT: FWIW, the tunnel I configured shows
not invalid - not running - not slave - not passthrough
which is not really helpful.
Okay, I got it running now. Very special thanks to tdw!
What was the solution?
For once: Removing the keepalive config actually helped. ROS still put the default values back in, but a second later, I could see “running”. Nice!
Next up was the routing config, and for that I was somewhat on the wrong track, assuming that the tunnel consists of two numbered endpoints and I had to use the remote endpoint as a gateway. However, turns out that’s not required. All you need to do is assign it an arbitrary IPv4 address and configure this as a default gateway to 0.0.0.0/0. Voila! In other words something like:
Glad you have got it working. As the AFTR server name appears to be unchanging for the ISP you also do not have to bother with parsing the DHCPv6 option 64 reply and updating the ipipv6 remote address.
Yep, so far I spared myself the hassle of setting the AFTR name with every new connection as it really seems to be static, so why bother.
Anyway, after running for two days now, I find that the performance on IPv4 is somewhat mixed, and I am wondering whether this has to do with the CGN (the AFTR) that my ISP is running or something else. To be precise, before the switch to DS Lite, I would pretty much max-out my Gbit link to the ONT. Now I only get around 750 Mbit/s which seems a little on the low side. Upstream I do reach the advertised 300 Mbit/s, so I am wondering whether anything (my RB5009 or the ISP’s CGN) is bottlenecking the connection here.
Besides discussing with my ISP, I wanted to ask for second opinions here and am happy to read yours. TIA!
Difficult to say - you can check CPU utilisation on your device, but it is often not possible to check what the ISP is doing.
Most likely is fragmented packets - the default MTU for Mikrotik ipipv6 tunnels appears to be 1460 (i.e. 1500 - size of an IPv6 header), if your IPv6 WAN is less than 1500 this would cause fragmentation. It can be difficult to debug exactly where fragmentation is occurring (inside or outside the tunnel) without resorting to capturing and analysing packets.
CPU utilization seems to be around 5 % when really hammering the line with some speed test, so that is probably not likely the issue. PPPoE MTU is set to 1492 (automatically), and the ipipv6 tunnel’s MTU is set to 1452, so that looks good to me.
However, after some more days using this setup, it appears that not only is the maximum speed lower than before, there are actually several websites that will simply not load anything or take a loooooong time (and multiple attempts) loading. I seem to recall that this would happen with too large an MTU, but even lowering the MTU on the tunnel to something like 1300 did not change anything.
Again, I have picked this up with my ISP, but I wanted to gather thoughts from here in order to better prepare myself. Also, the ISP’s technical skills do not really seem to be going very deep. Seems to me like Huawei have installed everything for them and now they’re stuck operating the system without proper knowledge let alone experience in this sort of thing. Anyway, my suspicion is that the CGN is simply wrongly configured and/or overloaded, but then again I have zero experience with this setup so want to be sure I’m not missing anything obvious.
Pages not loading or taking a long time to load does suggest MTU / fragment handling / PMTU discovery issues.
The default clamp-tcp-mss=yes on the tunnel interface should fix this, which does suggest an issue with their gateway. You could try setting dont-fragment=yes which would drop packets where the payload is too large, it may help with PMTU discovery. You could also try some explicit firewall rules to both examine TCP MSS and/or force it to 1412 [1500 - 8 (PPPoE) - 40 (IPv6 header) - 20 (IPv4 header) - 20 (TCP header)]
TCP MSS Clamping is enabled on the tunnel already, so chances are that something is not working as it should.
Trying a simple ping with DF bit set seems to behave as expected i. e. responses are received unless packets become too large for the calculated MTU. Of course that doesn’t guarantee that TCP MSS is set appropriately, but at least the MTU part seems fine.
