I am working with trial 7.9.1 on a Mini-ITX x86 box. This is to establish RouterOS full working IPv4/IPv6 before I purchase a Netgear appliance. (Motivated by impending EOL of my CIsco RV34x router) The Cisco's IPv6 to this ISP worked fine the first time with a bog standard configuration - pretty much the same WAN DHCP-PD, LAN 64-bit prefix from WAN, and RA settings that routerOS accepted.

I arrived at the current RouterOS configuration by extensive use of online documentation. For example, the set of IPv6 firewall rules is the oft-repeated set of 21 or so that you see everywhere on this forum. IPv4 is working fine, it is only for IPv6 that I turn to the forum for help.

A lot of things work (though possibly the router must sit for a bit before they start to work). For example, ping and traceroute from the Winbox Tools work fine (Winbox1.jpg). The PC plugged into the router gets valid-looking IPv6 addresses (PC ipconfig to routerOS.jpg) and (remarkably) the PC does a working ping6 and a mostly working tracert (PC to routerOS.jpg).

So what doesn't work? All IPv6 websites FAIL from the Chrome browser (e.g. ipv6.cybernode.com which works only with IPv6).

I've looked and looked at the configuration, addresses, routing table and so on - I'm at wit's end to solve this. I have attached the output of the routerOS configuration export.

If anyone has some tips on what works or what to try, I would appreciate enormously. I would even love a configuration export of a fully working IPv6 routerOS setup. I'm willing to go through it line by line to see any differences with what I already have.

My best guess is that since your PC doesn't have an IPv6 DNS server the browser retrieves IPv4 address (the type=A record) which exists but presumably is ignored by the server.

To verify that, you can statically configure IPv6 on your PC to use a public IPv6 DNS server, e.g. 2620:fe::fe

If what @Kentzo suggests is indeed true, then it's doing of a particular application. Normal DNS servers, even if they only work on IPv4 (e.g. DNS server itself only has IPv4 connectivity), will happily return AAAA records if asked for them. So it's up to application (and resolving library used) to ask for AAAA records and do something about them.

Can you try also using other browsers? E.g. use Firefox, which is truly independent of Chrome; edge would be fine as well, but it's related to chrome and might experience similar problems if they are indeed introduced by browser itself.

Do you have a connection to the ISP with less than 1500 byte MTU? E.g. a PPPoE connection often has that problem.

If so, first try to fix that. Try to set 1500 byte MTU and MRU on the PPPoE interface and see if that remains after re-negotiation.
If so, your problem is probably fixed.

If not remove that again, and reduce the MTU in the IPv6 ND settings to the MTU you actually get from the ISP.
Some other routers do that automatically, but MikroTik does not do it and always advertises 1500 bytes unless you configure it differently.

You might want to try https://test-ipv6.com. It works both over IPv4 and IPv6 and can detect whether a browser prefers IPv4.
E.g. on my system Safari prefers IPv4 while Firefox prefers IPv6.

Thanks for all these responses. I believe that one way or another I have already tried everything mentioned except the MTU check.
nslookup and DNS records reveal IPv6 addresses returned as expected.
Firefox and Edge browsers behave the same as Chrome.
test-ipv6.com just confirms what ipv6.cybernode.com reports.
I will take a look but odd MTU is unlikely since the Cisco RV34x router and other router software works normally.
Also, I have brought up OpenWRT and pfSense routers with full concurrent IPv4/IPv6 stacks, working browsers.

What I have done is prepared an entirely new configuration file, taken from the routerOS man pages and ensuring that I understand each and every line.
This hasn't been tested yet (reset with "import" throws cryptic error messages either non-specific, or if they point to the line/column there is nothing there to see).
I have another small x86 box coming in a few days (a Barracuda F12) and I will try the new configuration on a fresh routerOS install there.

Lots of babble babble but not even a reply to my question, let alone an attempt to try a solution.
I wish you good luck! (but will not help you further)

pe1chl:
Sorry - although I did mention that I would take a look at the MTU issue.
Usually, I concentrate my testing (where I need to disconnect the house network from the ISP) on the weekend.
I wasn't planning on trying out the MTU until then, but I will eventually report on the result . . .

Thanks again!

ping.exe accepts the /l attribute to specify the size of the icmpv6 payload. Start with 1460 and see if you can find where it stops working.

ping.exe accepts the /l attribute to specify the size of the icmpv6 payload. Start with 1460 and see if you can find where it stops working.

It's useless without the option to not defrag the packet...



https://www.iea-software.com/products/mtupath/

dos terminal code

mtupath -4 one.one.one.one

MTU path scan to one.one.one.one (1.1.1.1), ttl=64, limit=48
# 16 processing - best MSS 1472 (estimated MTU 1500) [pPPPPpPppPpppppp]
# 01 nearest minimum MTU on local interface

        #1 MSS IN RANGE     1 <==  1471 ==>  1472
        #2 MSS EXCEEDED  1473 <== 14911 ==> 16384



mtupath -6 one.one.one.one

MTU path scan to one.one.one.one (2606:4700:4700::1111), ttl=64, limit=48
# 16 processing - best MSS 1452 (estimated MTU 1500) [uUUUUuUuuUuUuUuu]
# 01 nearest minimum MTU on local interface

        #1 MSS IN RANGE     1 <==  1451 ==>  1452
        #2 MSS EXCEEDED  1453 <== 14931 ==> 16384

IPv6 has one fixed header with 20 bytes more than "usual" IPv4, so, for same MTU, the MSS is 20 less.

MTU Path looks very handy.
I ran it just now, not through the routerOS development router, but through my production router - the ISP is the same though.

The results using an IPv4 target:

> C:\Users\xxx\Downloads\MTU Path>mtupath 8.8.8.8
>
> MTU path scan to 8.8.8.8, ttl=64, limit=48
> # 16 processing - best MSS 1472 (estimated MTU 1500) [pPPPPpPppPpppppp]
> # 01 nearest minimum MTU on local interface
>
> #1 MSS IN RANGE 1 <== 1471 ==> 1472
> #2 MSS EXCEEDED 1473 <== 14911 ==> 16384

The results with an IPv6 target:

> C:\Users\xxx\Downloads\MTU Path>mtupath 2620:119:35::35
>
> MTU path scan to 2620:119:35::35, ttl=64, limit=48
> # 16 processing - best MSS 1452 (estimated MTU 1500) [uUUUUuUuuUuUuUuu]
> # 01 nearest minimum MTU on local interface
>
> #1 MSS IN RANGE 1 <== 1451 ==> 1452
> #2 MSS EXCEEDED 1453 <== 14931 ==> 16384

So the IPv6 MSS is 20 less than the "usual" IPv4.
Does this indicate that setting MTU in my routerOS configuration is likely to do the trick?

Thanks!

Apparently there is not any problem...

P.S.: do not use 8.8.8.8 & co. when you do test for MTU... user another site, like 1.1.1.1
Google alter the ping reply.........

[deleted]

Telnet to an IPv6 address of google.com (2607:f8b0:4005:813::200e for me) over port 80, then enter a couple of chars and press enter. If connection is successful telnet will print some HTML output and then close the connection.

SOLVED. Thanks to all for your suggestions.
Aside from trying those, I spent the weekend going over about everything on the web about getting IPv6 working on routerOS.

IPv4 / IPv6 is now running on a Barracuda F12 (x86) box.
This is using what I considered a minimum set of IPv6 firewall filter rules for functionality and basic safety.
Notably, I didn't add all the IPv6 "bogon" firewall filter rules at this stage.
I figured I could fine tune the firewall rules once basic connectivity was established.
Are the IPv6 bogon rules important for a real-world router?

For the record, here is the IPv6 portion of the export config output (defaults, not shown, play an important role in allowing this to work):

/ipv6 address
add address=::20d:48ff:fe2d:6eaf eui-64=yes from-pool=WANPOOL interface=ether2-LAN

/ipv6 dhcp-client
add interface=ether1-WAN pool-name=WANPOOL rapid-commit=no request=prefix

/ipv6 firewall filter
add action=accept chain=input connection-state=established,related,untracked
add action=accept chain=input protocol=icmpv6
add action=accept chain=input port=33434-33534 protocol=udp
add action=accept chain=input dst-port=546 protocol=udp src-address=fe80::/16
add action=accept chain=input in-interface=ether2-LAN
add action=drop chain=input
add action=accept chain=forward connection-state=established,related,untracked
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward in-interface=ether1-WAN protocol=icmpv6
add action=accept chain=forward in-interface=ether2-LAN
add action=drop chain=forward

/ipv6 nd
set [ find default=yes ] interface=ether2-LAN ra-interval=20s-30s

Cheers.

> Are the IPv6 bogon rules important for a real-world router?

Depends on how your Mikrotik is connected to upstream. My stats show occasional packets from "bad" source IPs.

Depends on how your Mikrotik is connected to upstream.

In my case the router is a straight SOHO gateway, with WAN connected to a reliable ISP.
I was thinking, the ISP would keep those Bogons off their link.
My main concern about "extra" filter rules is performance impact.
Is that a known issue, or am I worrying about nothing?

My main concern about "extra" filter rules is performance impact.

No easy answers here, you'll have to measure. In my setup it's not noticeable, but my uplink utilization is very low.

Rule order does matter. With the first rule (in each chain) accepting all packets members of accepted and related connections, the majority of packets are already dealt with (in normal case that is). In abnormal cases (e.g. when you're victim of a DDoS attack) your router will suffer anyway, so a few additional rulees won't make situation much worse (because it will already be really bad).

I've seen a lot of crap ISPs do some crazy stuff... or I haven't seen them do the basic stuff...

As an end user you shouldn't have to worry about bogons or spoofing at all (apart from not generating it).
As an ISP, I accept incoming traffic only at the allocated 2000::/3 (33 blocks)
https://www.iana.org/assignments/ipv6-u ... ents.xhtml
and block those reported here:
https://www.spamhaus.org/drop/dropv6.txt
plus others I can't talk about due to N.D.A.

Given the nature of IPv6, it is quicker to accept the allocated ones, and drop-alll-at-the-end, than to block the unused ones and accept the rest...

[SOLUTION];
viewtopic.php?p=1024003#p1024003