Hi,

I've managed to configure a pptp interface between RB750's however as it doesn't appear as secure as ipsec I decided to setup firewall rules to only allow pptp from the 2nd RB750. With pptp it created the link-local addresses automatically and I could simply add ipv6 routes with

/ipv6 route add address=######/48 gateway=%<pptp-####>


Now I'm trying to setup l2tp/ipsec for my mobile devices, and I can't get it to work with IPv6. Looking at http://forum.mikrotik.com/viewtopic.php?f=13&t=52503 I thought at first it was a problem on the client end. (I have no problems with IPv4 from my phone it gets a dhcp address from the vpn-pool without a problem)

However, I've just noticed my l2tp interface doesn't have a link-local address, and there's no way it will route IPv6 without an interface address!

I've even tried setting up a dhcpv6 pool but that didn't work. I've pasted as much as I think is relevant of my config into a pastebin http://pastebin.com/fMF370px with the sensitive data replaced by #s.

The pastebin is from a time when the dhcpv6 was not used, so here is another output showing an attempt using dhcpv6

[admin@MikroTik] > /ppp profile print detail
Flags: * - default
...

1 name="vpn" local-address=172.16.1.254 remote-address=vpn-pool
remote-ipv6-prefix-pool=vpn dhcpv6-pd-pool=vpn use-ipv6=yes
use-mpls=default use-compression=default use-vj-compression=default
use-encryption=default only-one=no change-tcp-mss=yes
dns-server=192.168.177.7,192.168.177.11

What I am doing wrong on the Mikrotik end? and how do I ensure that the l2tp interface gets a link-local address?

Thanks,
Banjo

Thanks to Linitx support I've managed to change my configuration from a routed setup to a bridged setup, so I should be able to use the link-local address of the bridge (perhaps as its not really bridged but arp-proxy).

I've changed the ppp profile to use local-address=<private-lan-ip> and remote-address to the same dhcp pool as my private lan, then added arp-proxy to the bridge interface.

However, I still can't get my Android phone (Samsung Galaxy S3) to request an IPv6 prefix and build its ownaddress or even grab an IPv6 address from the dhcpv6 pool.

I can create a l2tp-###### interface using /interface l2tp-server add name=l2tp-##### user=##### but it still doesn't show up in the output of /ipv6 address print with a link-local address. If I create it an IPv6 address on the private lan prefix then the routing table says its unreachable ....

[admin@MikroTik] > /ipv6 address print detail
0 G address=#############::1/64 interface=internal-lan
actual-interface=internal-lan eui-64=no advertise=yes

8 DL address=fe80::20c:42ff:fec4:8e0c/64 interface=internal-lan
actual-interface=internal-lan eui-64=no advertise=no

9 G address=#############::2/64 interface=l2tp-###### actual-interface=l2tp-######
eui-64=no advertise=yes

[admin@MikroTik] > /ipv6 dhcp-server binding print detail
Flags: X - disabled, D - dynamic

[admin@MikroTik] > /ipv6 route print detail
Flags: X - disabled, A - active, D - dynamic,

3 ADC dst-address=###############::/64 gateway=internal-lan,l2tp-#######
gateway-status=internal-lan reachable,l2tp-####### unreachable distance=0
scope=10

Can anyone help with how to get the ipv6 bridged over the l2tp link?

Hello,

The thing is that Mikrotik elects a link-local address for an L2TP itnerface only after the interface has dialled-in. In other words, only when the interface is in Running state does it get a link-local address. The global address added to that interface gets unreachable when the interface is down, but becomes available when it dialls back in. The issue I am seeing here is that Mikrotik uses a rather narrow pool when selecting a link-local address for the interface, and so fe80::7/64 is common to see across many Mikrotiks. I have not seen the router to choose two same such addresses with its interfaces, but when you run an L2TP hub with IPv6 enabled this becomes an issue, since RIPng which I use gets confused if it sees two identical link-local addresses (e.g. Client1 and Client3 have both fe80::7/64 as their L2TP link-local endpoint address) on different interfaces.

when using LL addresses you have to use address+ interface where this LL address should be reachable on.

janisk: this is all true when you want to ping the LL address or when you display the main routing table, where you can see the RIPng routes' described by by the 'll%interface' pair, but the RIPng's routing table (/routing ripng route print) has its routes' gateways decribed only be the LL value. There seems to be no issue with 6to4 interfaces, but as soon as the L2TP, IPv6-and-RIPng-enabled hub starts seeing two identical LL addresses (take the fe80::7/64 from my last post) on two different L2TP client interfaces connecting from two different places, it starts to swapping the received prefix/es entry for the duplicate LL addresses it finds. Consider the example:

1 hub, 4 clients:

Hub's L2TP static interfaces:
hub1: fe80::a/64
hub2: fe80::b/64
hub3: fe80::c/64
hub4: fe80::d/64

Clients' interfaces:
cl1: fe80::1/64, advertises 2001:1::/64
cl2: fe80::2/64, advertises 2001:2::/64
cl3: fe80::3/64, advertises 2001:3::/64
cl4: fe80::3/64, advertises 2001:4::/64

Normally, you would expect the hub to see the routes more or less like this:

2001:1::/64 via fe80::1/64
2001:2::/64 via fe80::2/64
2001:3::/64 via fe80::3/64%hub3
2001:4::/64 via fe80::3/64%hub4

But it is not so. The first two entries for client 1 and 2 will be working fine, but because client 3 and 4 have the same LL address on their part (the fe80::3/64), the hub will swap the learned prefix for the given LL address as soon as new RIPng advertisement is received. In the end we will end up with such a situation:

2001:1::/64 via fe80::1/64
2001:2::/64 via fe80::2/64
2001:3::/64 via fe80::3/64%hub3

RIPng update takes place

2001:1::/64 via fe80::1/64
2001:2::/64 via fe80::2/64
2001:4::/64 via fe80::3/64%hub4

RIPng update takes place

2001:1::/64 via fe80::1/64
2001:2::/64 via fe80::2/64
2001:3::/64 via fe80::3/64%hub3

and so on.

I believe this happens precisely because RIPng does not describe the received routes/prefixes with the 'LL%interface' information, but only takes the 'LL' part. At present I am running such an IPv6/RIPng hub with only 12 client tunnels and I have already seen such a case at least 3 times. I believe a solution to the problem would be to add the "%interface" part to a route's gateway descriptor, or if you at least increased the randomness pool for L2TP interfaces, so that one could run into such problems less often.

I can open a ticket with Support on this if you wish.

we are working to resolve the issue regarding RIPng routes.

This bug is still exist in RouterOS 6.15 both RIPng and OSPFv3.

http://forum.mikrotik.com/viewtopic.php ... 00#p432823