I’m slowly coming to terms with IPv6 but having some difficulty with my config on an 1100AHx2.
I added/enabled an entry in IPv6 > DHCP Client for the WAN interface, configured to request a prefix and address. Use Peer DNS and Add Default Route are checked. After applying my changes, the WAN interface acquired an IPv6 address and /64 prefix from the Comcast gateway. So far, so good. I then manually added IPv6 addresses to 2 LAN (different subnets) interfaces, entering just the 64-bit prefix in the address field, and checking the options EUI64 and Advertise. Upon applying, an IPv6 prefix + EUI64 address is generated and assigned. The WAN interface and 2 LAN interfaces already had link local (fe80) addresses (automatically generated at some point?). The three global unicast addresses on the WAN and 2 LAN ports all have the same /64 prefix. From the RB (Tools > Ping) I can successfully ping a well-known “online” IPv6 address (Google DNS server): 2001:4860:4860::8888. The default IPv6 > ND entry seems to be working fine. IPv6 clients on our LANs automatically generate valid global unicast addresses using the advertised prefix (same /64 prefix as used by the LAN and WAN interfaces on the RB). From an IPv6 client, I can ping other IPv6 clients on the LAN, using either their global unicast address or local link address. From an IPv6 client, I can also ping the local link address of a LAN interface on the RB, but cannot ping the global unicast address for that LAN interface. From an IPv6 client, attempts to ping well-known “online” IPv6 addresses such as a Google DNS server result in “Request timed out.” From the RB, attempts to ping the link local addresses of LAN clients works sometimes but seems to fail more often (nothing printed where I expect ping response output). At one point, it seemed to make a difference if I first pinged the RB (local link address) from a client, then pinged in the other direction, but that isn’t consistent.
Seems some of my IPv6 config (routing?) needs adjusting. Any tips/suggestions would be appreciated!
Forgot to mention attempts to ping global unicast addresses of IPv6 clients (LAN) from the RB result in “timeout - no route to host” responses.
When I try pinging a global unicast addresses on the RB, from a LAN client, a global unicast address for the client appears in IPv6 > Neighbors, on the RB. These entries briefly have a status of “failed” but quickly change to status “stale.”
If you want to have two separate LANs, /64 prefix is too small (strange thing to say about subnet with 2^64 addresses, but that’s how it is), you need to get larger prefix from ISP. Try adding prefix hint to DHCPv6 client, e.g. prefix-hint=::/60. Then if you get it, add addresses to LANs like this:
/ipv6 address
add address=::1/64 from-pool=<pool name from DHCPv6 client> interface=<lan1 interface>
add address=::1/64 from-pool=<pool name from DHCPv6 client> interface=<lan2 interface>
Didn’t make a difference. I’m seeing the same IPv6 addressing info from my ISP (Comcast/Xfinity Business Class Internet). I’m willing to try a different approach to my network design, especially if the changes required are minimal. 2 LAN ports on the RB connect to 2 switch ports configured for distinct/default VLANs (untagged)–I’m not doing any tagging/untagging on the RB itself. Not sure how/if it would help if I would use tagging to handle the LANs via single port on the RB…
Thank you!
I’d rather not request another /64 from Comcast if there is another reasonable approach.
There really isn’t. While you can divide /64 into something smaller, almost everything expects /64 to be the smallest subnet and it’s needed for autoconfiguration.
I know that you should be able to get larger prefix from Comcast without doing anything special. Not from personal experience, but there were reports about it on this forum. But I think I do remember one about some problem when switching from /64 to /60, not exactly sure about details.
Did you try to manually release and renew after changing prefix hint?
I think so. Changing the prefix hint field and applying my changes in WebFig appears to force the RB to re-negotiate IPv6 addressing with the Comcast gateway. The IPv6 addressing, prefix and pool briefly “disappear” and after a bit the addressing info reappears. For testing, I removed the manually-assigned prefix + EUI-64 address for one of the LAN interfaces. I can now ping the IPv6 address of the LAN interface that has an IPv6 address, from a workstation on that LAN. But I still can’t ping the IPv6 address assigned to the WAN interface, or a well-known non-local / “online” IPv6 address (e.g. 2001:4860:4860::8888), or otherwise access public Internet/web resources (e.g. http://ipv6test.google.com) via IPv6. In the image below, ether13 is the LAN interface with an IPv6 address, ether10 is the WAN interface connecting to a port on the Comcast gateway. The image shows IPv6 route entries displayed in WebFig. These route entries were automatically generated as far as I know. Do these appear in order for basic routing to/from Internet for the given interfaces?
As recommended in this post, I configured the RB IPv6 DHCP Client to request only a prefix, not an address and applied my changes. Now only a link-local IPv6 address is assigned to the WAN interface. I still cannot ping/access IPv6 addresses on the Internet (outside the LAN) from LAN-side nodes. For testing purposes, all IPv6 firewall rules are disabled–no change.
From the beginning, if you open properties of DHCPv6 client, on top there are buttons “Release” and “Renew”. Try using those. I can’t guarantee that it will help, but just to be sure.
Next thing, you have prefix xxxx:1b00::/64 on both ether13 and ether10. It’s wrong, because it works as load balancing, router will try to contact address from that subnet on one of those interfaces, but it might choose wrong one. You can have one subnet only on one interface.
Then you also have public subnet on WAN. It looks like it comes from DHCPv6 client’s request=address parameter. First, you don’t really need it. Everything works even without any public address on WAN interface. Link-local addresses are enough, as you can see by fe80::xxx default gateway. It does not hurt to keep it, but you can remove it (request only prefix, not address) to make things simpler.
And if xxxx:1b00::/64 comes from requested address, you definitely can’t use it for LAN. In fact, your prefix should be the other one, xxxx:1bff::/64, which you can use for one LAN. But not assigned manually, you should use from-pool option.
Route to xxxx:1bff::/64 is unreachable, because it’s the prefix received from ISP. It does not make much sense this way, but it would if it was bigger. If you received e.g. /48, it would be by default unreachable, but all used smaller parts would create more specific routes and would override it. But if someone tried to connect to subnet that you could in theory have (it would be part of large prefix) but do not really use, the unreachable route would prevent packet from bouncing back to ISP (and then back to you, ISP, you, … until TTL expired).
So your whole config should look like this:
/ipv6 dhcp-client
add add-default-route=yes interface=ether10 pool-name=dhcp-pool prefix-hint=::/60 request=prefix
/ipv6 address
add address=::1/64 from-pool=dhcp-pool interface=ether13
It will request prefix and put it into pool named “dhcp-pool”. And address will automatically take one /64 prefix from pool and make it into valid address. In case of larger prefix, you can do the same for multiple LANs and each will get unique subnet. If you have only one /64, it means only one LAN (don’t think about smaller subnets, you won’t be happy with result).
Right–I had already disabled requesting an address on the WAN interface, as indicated in my most recent response. As of that response, the RB only had a globally-routable IPv6 address on one LAN interface. But from a LAN client/workstation I could still only ping/access IPv6 addresses on the LAN.
I tried releasing and renewing for IPv6 DHCP Client (WebFig)–problem remains. I tweaked my config to closely match your recommendation:
/ipv6 dhcp-client
add add-default-route=yes interface=ether10 pool-name=Comcast-IPv6-Pool prefix-hint=::/60 request=prefix
/ipv6 address
add address=::1/64 from-pool=Comcast-IPv6-Pool interface=ether13
Now the IPv6 address assigned to the RB’s LAN interface ends in :1bff::1
After refreshing/renewing IPv6 clients (LAN), they also have IPv6 addresses with prefixes ending in :1bff: From such workstations, I can ping/access the RB’s :1bff::1 address, but still cannot ping/access any IPv6 resources outside the LAN.
I use Comcast with IPv6 and here’s one detail that the general community on Mikrotik forums might not be aware of:
The Comcast DHCP server tries to give you the same prefix whenever you release/renew your address.
So when you first change the prefix hint to specify a request for a /60, Comcast will accept it, but unfortunately, the primary server ignores the request and gives you the same /64 prefix that it has cached for you. (A packet capture reveals that the backup DHCP server, which has no prefix cached for you, DOES honor the /60 request, but since it’s the backup, your router takes the cached /64 from the primary and ignores the backup /60).
The solution is to disable dhcp client, wait 48 hours (I think it’s 48 hours), and then enable it with the prefix hint set. Once this happens, you’ll get your /60.
Next thing - you don’t need a routable address on the WAN interface. I don’t have one applied to my WAN interface - the WAN interface communicates with Comcast’s router using the link-local address. If you try to ping something global from the Mikrotik, then the router will be more than happy to use one of the lan interface addresses as the source-address for the pings. (or wget requests, or whatever the router needs to do on the Internet)
Also - there were some versions of ROS which had some buggy behavior about putting IPv6 prefixes on interfaces from a pool. I forget the version this got fixed in (6.27?) but make sure you’re running at least the current bugfix release, if not the current release. This bug caused the ND process to get confused and it wouldn’t properly activate the IP prefixes on LAN interfaces, thus it would not send RA messages for clients to use in their SLAAC functions, and it would not participate in ND.
Another thing to make certain of is that you’re not blocking all icmpv6 in your input chain of the firewall rules - icmpv6 is even more important to IPv6 than ICMP was to IPv4, since it also provides the functionality (ND) that was done by ARP in IPv4. At the very least, you need to allow icmpv6 from fe80::/16 on the WAN interface, and ideally, white-list it entirely on the LAN interfaces.
Here’s how you know you got the /60 from Comcast:
Note that the pool prefix is /60, but the prefix length is /64.
Prefix length = the length of prefixes assigned from this pool.
Since you’re assigning directly to local interfaces, /64 is correct for that.
(shorter prefixes like /63 /62 etc would be used for assigning to other routers in your own network which would request prefixes from this router, but that’s not your scenario)
Alright, thanks!
- Disabled IPv6 DHCP client. We’ll see what happens after re-enabling it in 48 hours or so.
- Yup, removed routable address for WAN a few posts back, thanks to your recommendation in another thread.
- I’m running (and was when I started experimenting) ROS 6.35.4 and the latest firmware for my RB
- I have no (enabled) IPv6 firewall rules and don’t plan to enable any until I get a good basic connectivity test
Got distracted with other duties and finally got back to this. Now after enabling IPv6 DHCP Client with prefix hint of 60 and pool prefix 64, I’m not getting anything. It just says status: searching.
Your DHCPv6 client settings match mine. (obviously the interface is different for me)
Just to make sure - your cable modem isn’t acting as a router is it?
If the modem is bridging, then I’d say the next thing to do is run a packet sniffer to see whether the dhcpv6 requests are actually being sent and also to see if there are any responses that the router is not acting upon.
It really wasn’t very hard to get this running.
Here’s my entire IPv6 configuration (firewall slightly doctored to omit the port knocking rule chain I have, which is pretty much irrelevant to basic functionality anyway)
/interface 6to4
add !keepalive mtu=1480 name=6to4relay
/ipv6 address
add from-pool=Comcast interface=LAN
/ipv6 dhcp-client
add add-default-route=yes interface=ether6 pool-name=Comcast prefix-hint=::/60 request=prefix use-peer-dns=no
/ipv6 firewall address-list
add address=xxx:xxxx::/32 list=Whitelist
/ipv6 firewall filter
add action=accept chain=forward comment="Allow existing connections" connection-state=established,related
add action=accept chain=forward protocol=icmpv6
add action=accept chain=forward comment="Allow whitelisted hosts and networks" src-address-list=Whitelist
add action=drop chain=forward comment="Block Internet from new inbound connections." in-interface=ether6
add action=accept chain=input comment="Allow Existing Connections" connection-state=established,related
add action=accept chain=input comment="Permit ICMP" log-prefix="" protocol=icmpv6
add action=accept chain=input comment="Trust Whitelisted Hosts" log-prefix="" src-address-list=Whitelist
add action=accept chain=input comment="Allow DHCPv6 replies on WAN from link-local dst-address=fe80::/16 dst-port=546 in-interface=ether6 protocol=udp src-address=fe80::/16
add action=drop chain=input comment="Block New Connections from Internet" in-interface=ether6 log-prefix=""
add action=drop chain=input comment="Block New Connections from Internet" in-interface=6to4relay log-prefix=""
add action=drop chain=forward comment="Block Internet from new inbound connections." in-interface=6to4relay
/ipv6 nd
set [ find default=yes ] advertise-dns=yes
/ipv6 route
add distance=1 dst-address=2002::/16 gateway=6to4relay scope=10
add comment="unreachable route for 6to4 block of current IPv4 address" distance=1 dst-address=2002:xxxx:xxxx::/48 type=unreachable
You can safely ignore the 6to4 stuff as well. That’s just there so that if I’m communicating with anything on the 2002::/16 block, I may as well send the packets directly to their IPv4 address since I also have IPv4 connectivity in my router. 
(for those interested, this interace pretty much never sees any activity, but I’d expect that)
The Comcast gateway (“modem”) is configured for what I think is termed pseudo bridge mode. “Disable Firewall for True Static IP Subnet Only” is checked in the Comcast gateway config. My understanding is our static IPv4 won’t work with true bridge mode.
In Wireshark, I see repeated DHCPv6 solicitation and advertisement packets from the RouterBoard and SMC Comcast gateway, respectively.
It’s apparent from the solicitation packet the RouterBoard is requesting/hinting a /60 prefix. The advertisement responses all have status code 6, “No prefixes available for this interface.”
Based on this Xfinity forum post, it sounds like I might need to contact Comcast support to get this sorted.
Thank you!
You should call tech support and get this sorted out.
Sounds like you’re using Comcast business… which is different.
“pseudo bridge” - that’s funny. It’s just forwarding IP.
Probably they have one or more /64 prefixes available in the router (let’s face it, the modem is a router, not a bridge - grrrr) and expect you to just use SLAAC and connect that way.
Routers can’t use SLAAC to do their job, so you need to ask them:
how many prefixes can you have ON YOUR ROUTER (not theirs - yours)
If it won’t allocate over DHCPv6, then you need to have Comcast route your prefixes to you with a static route on their side.
They could use your link-local address as the route’s next-hop target. If you do this, then remember that your MAC address is important, so that if you ever change routers, you’ll need to put the same MAC address on the new one’s WAN interface so the link-local address remains the same.
If they prefer to route to a public IPv6 address, then you’ll need to statically assign that to your WAN interface and have them route the block at your WAN address.
I know this is an old thread but maybe someone will be searching for the solution to the same issue like I was last night…
Basically in my case the end effects were pretty much exactly like OP described:
Hosts in the same subnet (local LAN) get local and global ipv6 fine. They can ping each other OK using local and global ipv6 but pinging or otherwise accessing external global ipv6 fail initially.
Notice the bolded “initially” because it’s important! Basically I discovered that once the router had recorded successfully the host in terms of ipv6 neighbor discovery the pings to outside (eg. ipv6.google.com) start working!
I was able to reproduce this every time by changing the default privacy setting on the interface of my test host from “default” to “prefer temporary addresses”. This is important because unlike ipv4’s ARP - it’s not possible to clear the ND (neighbor discovery) cache on mikrotik. This causes the host to generate a new IPv6 every time the interface gets up which in turn will guarantee that the router will not have it in it’s ND cache and pings initially fail. So once you have a fresh uncached (ND) ipv6 address on the host you ping eg. ipv6.google.com and see that pings fail.
In the meantime you ping the router’s global IPv6 address which will cause it to “notice” (discover) the new IP and record it and then magically pings starts to reply.
It turned out that the problem was caused by “IGMP snooping” set to ON on the LAN bridge. Once I’ve changed that back to OFF everything started working OK. I found the hint to this in http://forum.mikrotik.com/t/ipv6-neighbor-status-failed/135912/1 so hopefully it will help anyone experiencing similar issues.
Thanks for the tip on IGMP snooping! It was absolutely breaking connectivity for me on daisy-chained switches trying to ping Google’s IPv6 DNS.
Your setup seems pretty solid, but maybe check if your RB’s firewall is playing nice with IPv6. Also, have you tried traceroute to see where the ping hiccup kicks in? Sometimes it’s a routing thing.