Us tunnel broker only as a last resort …
Your Tik router should work … your ISP is doing something WRONG ..
Actually not likely.
No because IPv6 (the outer layer added by tunnel) has larger headers which means lower payload per same MTU … which ultimately means a percent lower throughput at same packet rate.
Yes or no because IPv6 routing across the globe might be different than IPv4 routing between same pair of devices. My experience is that mostly IPv6 routing is on average a tad simpler (less hops) but overall RTT tens to be the same. So it really depends on route taken between you and HE if IPv4 vs. IPv6 makes any difference for you.
Thanks for advising me on this. I will push my ISP on it.
Nothing in the capture suggests any of these actions. Please try to capture at least 10 minutes worth of traffic. At the very least we need to see ICMPv6 Router Advertisement packet there.
Unfortunately it doesn’t look like my ISP will actually be much help in getting this sorted as they’re taking the “it’s a third-party router, not our responsibility” route.
Tunnelbroker works with usable speed and latency, but does break streaming services as the likes of Netflix have very aggressive blocking of anything that looks like it might be designed to bypass a geographic block.
I’d be happy to keep trying other fixes, but if this looks like an ISP problem then I might just have to live with IPv4 only for the time being.
If that is their way of dealing with this THEN i suspect they are using a Mac Addy or Serial number lock on your account … so then you should TRY the spoofing solution I mentiomed earlier:
Find out the Mac Addy of their provided Router and Serial number then on your TIK change the Mac Addy of your Tik ether1 port to their Routers Mac Addy and see if that solves the problem – I suggest that you use the ipv6 Config I provided you earlier …
Make sure to record the default Mac addy for the port [ether1] you want to make changes on in case you have to revert back
In teminal issue the following directive:
/interface ethernet set ether1 mac-address=xxx
If that does not work then you may try one other method.
The cryptic wall box [ONT] – How does your Tik router connect to the ONT? is it via ethernet cable or SFP module
What brand is the ONT ?
Well, after a bit of back and fourth with my ISP they have advised me that despite previous communication they are using RADV for prefix allocations on IPv6.
Im assuming that’s a pretty major change?
Very strange …
So I’m now trying to receive a prefix via RA.
I have a single Ipv6 address being received via DHCPv6 and believe I have my Mikrotik configured correctly to receive RAs.
In my log, I see some activity on the ether1 interface.
received Router Advertisement on ether1 from fe80::a05:e2ff:feb0:9e8f
However it never progresses any further than receiving some kind of RA from that bogon address, no prefix, no address, nothing else. I find it weird that my ISP has a bogon address on their end, which makes me believe that I may not be actually talking to their upstream router, but that the ONT may be more intelligent than it has to be.
Unfortunately, my ISP is still of the opinion that as long as I have RA enabled, it should work. I’m bouncing back to them yet again for an update on this one, but I’m not holding my breath.
My current IPv6 config:
/ipv6 dhcp-client
add interface=ether1 pool-name=litv6 request=address
/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6
/ipv6 firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMPv6" protocol=icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" dst-port=33434-33534 protocol=udp
add action=accept chain=input comment="defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=udp src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=ipsec-esp
add action=accept chain=input comment="defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=input comment="defconf: drop everything else not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=icmpv6
add action=accept chain=forward comment="defconf: accept HIP" protocol=139
add action=accept chain=forward comment="defconf: accept IKE" dst-port=500,4500 protocol=udp
add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=ipsec-ah
add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=ipsec-esp
add action=accept chain=forward comment="defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=forward comment="defconf: drop everything else not coming from LAN" in-interface-list=!LAN
/ipv6 nd
set [ find default=yes ] hop-limit=64
/ipv6 settings
set accept-router-advertisements=yes
You may have to add options to your logging rule to see detailed information - typically debug, and if there is too much output !packet can be useful too.
The address looks fine - IPv6 uses link-local addresses in many places, rather than global unique addresses.
Unfortunately the IPv6 standards allow for various methods of providing and configuring addresses, the most common is Router Advertisments to provide the ISP - customer WAN prefix with the customer WAN address being formed from this prefix plus the WAN interface MAC address, additionally DHCPv6 prefix delegation to obtain addresses for the customer LAN(s).
Just having
/ipv6 settings
set accept-router-advertisements=yes
should be sufficient for IPv6 connectivity from the Mikrotik itself, then
/ipv6 dhcp-client
add interface=ether1 pool-name=litv6 request=prefix
should request the delegated addresses.
I’ve never seen an ISP trying to provide the delegated prefix in Router Advertisments, I’m not convinced the standards have a mechanism to do so.
I agree with @tdw
I noticed in your ipv6 you have
ipv6 dhcp-client
add interface=ether1 pool-name=litv6 request=address
Can you change that to
ipv6 dhcp-client
add interface=ether1 pool-name=litv6 request=address,prefix
See if that makes any difference?
Hi both,
Thanks for your suggestions.
If I use just prefix or prefix,address I get nothing different (no address assigned at all, no prefix either)
If I use just address I get a single IPv6 address
I currently suspect that there is either an issue with my ISP or that their support has misunderstood me and incorrectly advised me on how their IPv6 works (although by this point I should have stumbled upon something). I’ll try to confirm this with them.
I have also upgraded my firmware to 7.17.
I didn’t expect that to fix it, but thought there was a chance.
There has been no change since the upgrade.
It can be difficult getting past first-line support who typically know nothing and are working off scripts. You may have to resort to using the packet sniffer to capture the IPv6 RA and DHCP packets to see what is going on. I don’t know if Lit use the router WAN MAC address to link prefix assignments, it may be worth cloning the address off the IP supplied router.
I have just tried cloning the MAC of my Lit provided router.
For reference, that device is a MitraStar MGS2028E-2. That might mean something to somebody.
When applying that MAC address to my ether1 interface it doesn’t appear to make any difference in terms of log output or whether or not I receive a prefix.
That is even after I reboot the router, and renew/release the allocation (not that anything is allocated).
A quick search suggests that people have used other routers successfully, but Lit use an oddly small delegated prefix size of /62.
It may also be worth experimenting with setting the DHCPv6 client rapid-commit=no (I believe the default is yes), you could try also try specifying prefix-hint=62 and possibly use-interface-duid=yes too.
I’ve not seen reference to that, so thank you for highlighting it here.
Unfortunately, the /62 hint didn’t seem to do anything, nor did disabling rapid-commit.
Although the fact some people have reported needing a /62 is weird, as Lit support assured me they assigned /48s. Although they have given me wrong information at least twice so far so I wouldn’t be surprised if they got the prefix length wrong too.
I’m waiting on an update from my ISP, so will update here when I have some more information.
Still making slow progress with my ISP, but I have now acquired a packet dump with some useful information in it.
For reference, the dump file has been edited to remove some identifiers, all packets were formed correctly at time of capture. It is also of the pcap type.
What is interesting is that I can see a message coming back from my ISP stating “Sorry, no prefix could be allocated.”
This makes it sound very much like an issue on their end, unless there is a setting on my Mikrotik device that is likely to trigger such a response.
sanitized_ipv6debug.txt (4.56 KB)
Just a guess, but perhaps ISP’s DHCPv6 server misinterprets the Prefix-Length option. Try setting prefix-hint=::/64, and if that works gradually increase the pool by setting prefix-hint=::/63 then prefix-hint=::/62 etc until it breaks.
This error is definitely something I’d confront the ISP with.
BTW, see https://blog.packet-foo.com/2016/11/the-wireshark-qa-trace-file-sharing-tutorial/comment-page-1/ for sanitizing wireshark traces non-destructively. In your pcap file you messed up IP addresses.
+1
Given the OPs comment in post #47 regarding the provider advertising the prefix it would be interesting to see a packet capture of the Router Advertisments too.