As stated in subject we’re used with many provider with which we do bgp peering to use link local addresses on Cisco Access Routers to avoid external public ip traffic flooding.
Unfortunately, RouterOS up to the latest 6.32.3 does not allow to manually enter a stateful LINK LOCAL ADDRESS.
Could you remove this limitation?
Thank you.
Federico
NHM
Italy
Yes, we need this too!
Please allow us to add custom link-local addresses!
Another use case is using fe80::1 as default gateway for clients.
https://www.edge-cloud.net/2013/08/ipv6-link-local-addresses-as-default-gateway/
Any news about this topic ? It should be easy to remove a limitation, right?
UP, i really need this feature, could i get any updates on it?
What does “stateful” link-local IP mean?
Does this mean that you want to assign a static link-local address? I know Cisco lets you do it, and it’s nice because you can make the access router on a segment be a simple fe80::1 for every network…
You can fake this with a Mikrotik by changing the administrative MAC address of the interface to something that maps to what you want, so long as you’re prepared to accept the fffe in the middle…
… so if this is what you mean, then add my vote for this.
I know it should be possible by tweaking the mac address, but a self specified address (as rfc states), could be much more better than just a software limitation.
Yet i’m not able to integrate IPv6 between our Cisco network with Mikrotik just cause that oddity.
Please remove such limitation.
This is a great read. I’ve been using fe80::1 as the link-local gateway for a while in GNS3 for my Cisco labs - it’s cool to see that this was a good idea in others’ opinions. I’m going to go read the rest of the links at the end of this page.
Thanks for linking!
Yeah, this is rather useful.
Many providers use fe80::1 as the default gateway.
It makes everything SO much easier when handling many many servers behind your router(s).
I hope this limitation is lifted soon. (And in theory it should be rather easy to do so)
I understand the lock behind this for users not knowing what they are doing but for us knowing what we are doing this is a serious limitation of mikrotik equipment.
if it is about “default router” on servers, you can just use the subnet router anycast address. e.g. xxxx::0
The ability to manually specify the Link-local address can make other things easy than just a consistent default GW on all network access segments. Since our address allocation scheme creates a unique 3-nibble code for each router in our toplogoy, it makes life easy to use that code as the link-local address on OSPF routers as well. When viewing the routing table, It’s much easier to know which router is the next hop for fe80::80b than for fe80::0214:b4ff:fe0c:d42f.
For those interested - the code is one nibble for network region (aka OSPF area) with the next 2 nibbles for router number within the region. With our relatively small number of routers and regions, this should scale well for us for quite some time. So in region 8, router 2’s block for customer assignments would be 2001:db8:8020::/40, and its loopback address would be 2001:db8::802. Therefore, all of its active OSPF transit interfaces would have fe80::802 as the link-local address. (customer-facing interfaces will all be fe80::1 for primary routers and fe80::2 for backup routers)
Yes - we would really like to see this feature as well. No need to use EUI64 address for static default gateway for a device (we don’t assign global addresses for ptp subnets, relying entirely on link-local).
Another thing that custom link local addresses would help with - we have been running into problems with tunnels that have no MAC address, where the generated link local is something very simple and short like fe80::e. If the other side of the tunnel gets the same link local address, we can’t establish OSPFv3 neighbor relationships due to duplicate link-local, and we can’t change the link local to fix it, so we end up just having to live with no IPv6 there. This is the most frustrating side effect of not being able to manually configure link local addresses, preventing us from deploying IPv6 to a site entirely.
nope. in this case - for example GRE - routeros just takes the remote IP address in hexadecimal format, and generates link local addresses by putting them into the last 32 bits of the address
[me@router] /interface gre> add
remote-address: hgw.netadmin.hu
[me@router] /interface gre> print
Flags: X - disabled, R - running
0 name="gre-tunnel1" mtu=auto actual-mtu=1476 local-address=0.0.0.0
remote-address=hgw.netadmin.hu current-remote-address=188.6.199.159
keepalive=10s,10 dscp=inherit clamp-tcp-mss=yes dont-fragment=no
allow-fast-path=yes
[me@router] /interface gre> /ipv6 address print where interface=gre-tunnel1
Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local
# ADDRESS FROM-... INTERFACE ADV
0 DL fe80::2:bc06:c79f/64 gre-tunnel1 no
well, you can still specify addresses if you want, as you’re not limited to have just one or two addresses on the link.
but ipv6 is about autoconfiguration, and it relies on link local addresses for everything. once this address configuration mechanism is screwed up, nothing will work. usually there is no reason to have the same mac addresses on both sides of the link, hence the generated ipv6 address is always unique, unless you tamper with it.
i’m not aware of any other non-ethernet L2 media that supports multiple access, and in general, with P2P interfaces you (almost) don’t need addressing at all, you need routes pointing on the P2P link.
routers are pretty good at figuring out LL addresses for the other parties. you can use OSPF to have this sorted out easily and you don’t need GUA just for your loopback and customer facing links, maybe. servers (or generally non-router hosts) will be just fine with RAs to pick their default gateway(s).
True on all counts regarding autoconfig, but end-user access segments are a very very rare case for my operation, where yes, SLAAC is the way to go for us.
We static-configure all customer attachment circuits at the PE boundary anyway, so doing this in IPv6 is no big deal. The main thing I like to use custom LL addressing for is router-to-router links so that whenever I look at the routing table, it’s easy to identify which router the next hop is. (It’s much easier to scan a list of addresses like fe80::402 than a list of strings like this - fe80::2c4:d1ff:fe9f:c20d
Commissioning new routers and new OSPF links is not that common of a task here, so it’s easy enough to have that one additional step of “ipv6 address link-local fe80::c04”
Note that this is all Cisco world stuff because we don’t use Mikrotik in our core / PE layers.