I'm building a portable rack for a traveling IP training program I do, where one of the components is a Mikrotik Cloud Core router. Verizon has started to do IPv6 PDs only for mobile static solutions (ie - no more IPv4 unless you already had it) which is part of this class, so I'm starting to incorporate that. I'm trying to configure the Mikrotik to allow for IPv6 connectivity in a variety of situations, meaning if IPv6 is available for whatever WAN connection I happen to have at any particular location it will allow for IPv6 connectivity in the classroom. As such, I have enabled accepting of RAs and DHCPv6. The Mikrotik itself has IPv6 connectivity when testing at home, via RAs from my Edgerouter. I assigned the classroom side an advertising fd00::/64 IP. Computers attached to that are successfully creating their own fd00:/64 IP via SLAAC, but have no IPv6 connectivity even though I have IPv6 forwarding enabled on the Mikrotik.

The long term goal is to be able to emulate Verizon in the classroom and assign PDs to the students who will then program their equipment accordingly, but for now even simple IPv6 connectivity is a good start...

Any thoughts on how to get this odd configuration to work? I may be missing something simple..Running 6.41rc26 if it matters.

Thanks!!

Unfortunately, you cannot use fc00::/7 (the "private" IPv6 range) addresses with Mikrotik and expect Internet connectivity because ROS does not support any kind of NAT in IPv6.

If you receive anything more than a /64 via dhcpv6-pd client, then you can delegate sub-prefixes from your assigned one, and get connectivity that way. Further complicating your "IPv6 anywhere" goals is the fact that RouterOS can NOT use RA to learn connectivity and then act as a router for a LAN behind it.

RA is basically the primary mechanism for SLAAC addressing - meaning that any device with an interface performing SLAAC is expecting to act as an end node within the connected network. Say the network has prefix of 2001:db8efab::/64 - your devices (and non-Mikrotik router interfaces) will be able to obtain a public IPv6 interface address on that network, and they will configure the default gateway by using the link-local IPv6 address of the router whose RA was used to learn the locally-attached prefix.

This is fine and dandy for devices, and for "routers" that don't intend to forward IPv6 packets. Mikrotik _can_ use SLAAC to configure its IPv6 address, but IPv6 forwarding must be disabled in the IP settings. And then it will just work quietly behind the scenes - it will not show the IPv6 address anywhere and the routing table won't show any default GW. Basically, I consider this as "not working" because you have to do a lot of un-intuitive things to even get it to work, and even then, it's only as an ipv6-connected end device, and not a functioning router.

For a router to make use of a SLAAC-configured "wan" interface, it will need to have some kind of IPv6 NAT capability.

If you get a /64 from DHCPv6-PD, then you can assign that /64 directly to the LAN interface and your devices will be able to use SLAAC to join the network and surf via the Mikrotik. Note that the WAN interface doesn't need a public address at all. The Mikrotik will use the link-local addressing on the WAN interface to send and receive IPv6 traffic for forwarding. If the router itself needs to connect to some host on the Internet, it will use the public (global unique is the technical term) address of some other interface to do so. (There's an RFC that dictates this behavior, so it's not a Mikrotik work-around).

However, without NAT in IPv6, if you receive just a /64, then you may only have one functional IPv6 network segment. If you receive something larger, say a /60 or a /56, then you will have several more /64 prefixes available in your pool. Using 2 routers, the "upstream" router can assign some of them to its own local interfaces, as well as using the pool as the source for leases in its own DHCPv6-PD server. Make the inside router act as a dhcpv6-pd client of the upstream router. Whenever the upstream router assigns a lease to the downstream router, the upstream router will also create the necessary dynamic static IPv6 route to the block via the link-local address of the client router. (link local is all of those fe80:: addresses)

With Mikrotik, only DHCPv6-PD (prefix delegation) and static configurations will work at the moment. I and fellow forum user Idlemind are both complaining about the lack of advancement in IPv6 functionality quite often nowadays.

Thanks for the detailed response! I often don't have control over the upstream router, so getting a PD is almost certainly not going to happen easily.

As such, I'll just focus on the LAN portion and issuing the students PDs to emulate the ISP...

Thanks again!!

Mikrotik _can_ use SLAAC to configure its IPv6 address, but IPv6 forwarding must be disabled in the IP settings.

Small correction, accept-router-advertisements offers three options (no, yes, yes-if-forwarding-disabled) and unlike in the past, unconditional "yes" now works as it should. It's still nothing to get too excited about, autoconfigured address doesn't show anywhere and neither does route. And if would be really nice if it could be enabled on per-interface basis, it could work like DHCPv6 client with options to accept dns, default route and everything.

Small correction, accept-router-advertisements offers three options (no, yes, yes-if-forwarding-disabled) and unlike in the past, unconditional "yes" now works as it should. It's still nothing to get too excited about, autoconfigured address doesn't show anywhere and neither does route. And if would be really nice if it could be enabled on per-interface basis, it could work like DHCPv6 client with options to accept dns, default route and everything.

Well, at least it's a start. I agree about the per-interface functionality 100% and even made a similar suggestion in my IPv6 triage list thread. You should be able to obtain interface addresses with SLAAC and assign distances to the interfaces just as you would with IPv4's dhcp client. Sure, the LAN side can't directly benefit from this w/o NAT but assuming that routing is being taken care of "somehow" then having automatically configured interfaces + default GW candidates would be a good thing. Heck - the LAN space might be supplied via a IP66 tunnel, which would handle the LAN routing...

Point is - it's a tool that should 100% definitely be in the tool box.

Thanks for the detailed response! I often don't have control over the upstream router, so getting a PD is almost certainly not going to happen easily.

As such, I'll just focus on the LAN portion and issuing the students PDs to emulate the ISP...

Thanks again!!

No problem - and to un-hijack this thread, I'm going to offer a suggestion. If you'd like "IPv6 anywhere" functionality, then you could consider building a tunnel broker interface into the router so that it can be deployed anywhere that has IPv4 and then supplies routable V6 over the tunnel. Hurricane Electric's tunnelbroker didn't support endpoints behind NAT or dynamic endpoints as of the last time I looked into it (a couple of years ago when my own ISP rolled out native IPv6 service) but there are others that may work for you.

That was my other thought since a lot of places I go don't have native IPv6 anyway. With that I'd have it everywhere...

HE has some real potential here! They support dynamic: https://forums.he.net/index.php?topic=1994.0

And provided a sample config here:

/interface 6to4 add comment="Hurricane Electric IPv6 Tunnel Broker" disabled=no local-address=(WAN IP) mtu=1280 name=sit1 remote-address=184.105.250.46
/ipv6 route add comment="" disabled=no distance=1 dst-address=2000::/3 gateway=2001:470:39:408::1 scope=30 target-scope=10
/ipv6 address add address=2001:470:39:408::2/64 advertise=no disabled=no eui-64=no interface=sit1

However, they say this:
NOTE: When behind a firewall appliance that passes protocol 41, use the IPv4 address you get from your appliance's DHCP service instead of the IPv4 endpoint you provided to our broker.

So it appears that it would work for a single client, but not globally. Or can I also interpret that as if my firewall appliance doesn't pass protocol 41(ie - I don't explicitly allow it) that it will tunnel within the IPv4 packets?

This could end up being perfect, as HE will also give you a /48, so I could give entire /64 PDs out to students and have real world connectivity...

I think this is my answer: https://wiki.mikrotik.com/wiki/Manual:H ... e_for_Home

At the time I tried to use that auto-update URL, there was something about Mikrotik's fetch client that didn't quite work right - but I have the feeling that whatever it was has been addressed. (I was doing that back in 2011 when the thread was created, so I've forgotten the particulars)

You'll also need to have some kind of script on your Mikrotik which updates the local-IP configuration of the tunnel interface whenever the WAN IP changes.

Chances are, whatever you're behind will allow protocol 41 - most stuff doesn't block things like that. The best advice is to just try it and see where you can get.

With Mikrotik, only DHCPv6-PD (prefix delegation) and static configurations will work at the moment. I and fellow forum user Idlemind are both complaining about the lack of advancement in IPv6 functionality quite often nowadays.

Hey that's me!

Now business. L2TP that nonsense! It has NAT traversal capabilities. Use L2TP/IPSec on your traveling gear in a road warrior fashion. Once that is established you can bring your own IPv6 in. Whether it's a subnet of your already assigned prefix or you bring a tunnel into your router at home or the office (or cloud) and feed that down the VPN.

When it lands on the VPN client (roaming MikroTik) carve it up from there.

Got it working on HE!!

I used this script for automation: https://wiki.mikrotik.com/wiki/Hurrican ... nt_updater

But I had to "hard code" the HE IP update part, using: "https://USERNAME:PASSWORD@ipv4.tunnelbr ... d=TUNNELID"

For some reason the other version ("https://ipv4.tunnelbroker.net/nic/updat ... e=TUNNELID") wouldn't work when called via the router (as ZeroByte mentioned - Apparently the same issue, whatever that is, still exists).

Thanks to both of you for the ideas - I now have readily available "IPv6 anywhere" as I needed. It's even fairly speedy for a free tunnel (~200Mbps).

Just a note for anyone searching for this in the future - The external WAN IP must allow ICMP, so if you're behind a router you don't control and are trying this it's somewhat likely that ICMP is blocked and this won't work...

Blocking ICMP is so late-90's security tech anyway. Everyone needs to stop doing that. It breaks subtle things in ways most people don't realize, and it doesn't improve security by making your host "undetectable." Your host isn't undetectable by blocking ICMP anyway - if there's so much as one open port, the scanning worms WILL find it and identify it, regardless of whether it's Apache on port 80 or ssh on port 61874.

Blocking ICMP is so late-90's security tech anyway. Everyone needs to stop doing that. It breaks subtle things in ways most people don't realize, and it doesn't improve security by making your host "undetectable." Your host isn't undetectable by blocking ICMP anyway - if there's so much as one open port, the scanning worms WILL find it and identify it, regardless of whether it's Apache on port 80 or ssh on port 61874.

Agreed - I wish more people would realize the importance of ICMP as it relates to IPv6 - This is a decent blog on the subject: https://blogs.cisco.com/security/icmp-a ... ty-in-ipv6

It's also imperative to accessing SSL sites when MTU changes in IPv4 (and other services that leverage the DF bit). Under those conditions ICMP too big messages are sent by a router similar to how IPv6. Path MTU discovery issues are incredibly common because of ICMP paranoia.

+1 to all the ICMP heroes out there!

Path MTU discovery issues are incredibly common because of ICMP paranoia.

+1 to all the ICMP heroes out there!

But... but clamp tcp mss is a thing, right? That will fix the mess I make when I block all ICMP right? Better to have to apply a workaround than to let my device be discovered by a ping scan.

Seriously though - another thread here mentions ND cache exhaustion attacks caused by IPv6 scans. This reminds me of the days before "no ip directed-broadcast" became a default setting in Cisco (back in IOS 11 days - wheeeee). Smurf attacks became the most feared form of DOS attack until Cisco mitigated it with this simple feature. . I wonder what kind of basic default feature will be implemented to prevent ND exhaustion attacks....

Seriously though - another thread here mentions ND cache exhaustion attacks caused by IPv6 scans. This reminds me of the days before "no ip directed-broadcast" became a default setting in Cisco (back in IOS 11 days - wheeeee). Smurf attacks became the most feared form of DOS attack until Cisco mitigated it with this simple feature. . I wonder what kind of basic default feature will be implemented to prevent ND exhaustion attacks....

Posting a potential fix in that thread along with more permanent thoughts.