'IPv6-only' connectivity issue

devnull0 · Wed Mar 13, 2024 10:59 am

Greetings all,

I am running into an odd IPv6 issue and I'm not sure if this is an issue at my ISP's end (Xfinity/Comcast) or at my Mikrotik router's (RB4011iGS+).

My home network topology (typical and very plain vanilla):
Xfinity -> Netgear Nighthawk Cable Modem -> Mikrotik (RB4011iGS+) -> LAN
RouterOS: v7.14.1

I have a valid, public IPv6 address assigned the RB3011's ether1 (WAN) interface. That being said, the multitude of 'test-your-ipv6-connection'
sites consistently flag it as 'no IPv6 address detected'. A 'ping -6 <my_public_ipv6_address>' from the public internet also fails.

For a final confirmation, I also cannot reach "ipv6.google.com" from my home network.

On the other hand, a traceroute on my (seemingly) public IPv6 address always seems to succeed. It does terminate at my town, so I'm assuming my WAN-side IPv6 address is indeed somehow reachable.

Is there something more I need to do at my end (i.e. on the RB4011) to enable 'ipv6-only' connectivity for my home LAN? I'm pretty sure I've forgotten/missed/messed-up something basic but am out of ideas. Any helps you folks could provide would be highly appreciated!

Thanks!

/DN

Wed Mar 13, 2024 11:09 am

Give this a try.

Posted via IPv6 over Xfinity thru a MikroTik router.

devnull0 · Fri Mar 15, 2024 12:39 am

First off, apologies for the tardy acknowledgement of your super-quick response

life intervened

But yes, your guide worked perfectly. I'm now 'visible' on IPv6. Thanks a ton!

I do have a couple of quick follow-up questions (and a seemingly phantom RA issue that I'm seeing on the LAN side) that I'd really appreciate your input on:

First my questions:

1. Why do we add the <my_prefex>::1 IPv6 address on the bridge interface and not on the WAN interface? How does this enable 'IPv6 world visibility' (that my original question alluded to)?

2. Would be wise/safe to add another G address on the WAN interface (say <my_prefix>::/2)?

As for the 'phantom' RA:
While I see the 'real' RA sent by my mikrotik (on the LAN side) with its source address set to <my_prefix>::1 (i.e. the one advertising my prefix and my own DNS server) I'm also seeing another RA with a link-local source address that does not belong to any of the mikrotik's interfaces.

So are these from Xfinity (on the WAN side) and are somehow being 'forwarded' on to the LAN side? This is a bit counter-intuitive to me. Also, these RAs have the destination address of fe80::ffff:ffff:fffe. I've looked online but don't see this listed as a 'reserved' address anywhere. If it matters, these RAs also advertise a 'private' prefix of the '2001:0:x' sort.

So where are these RAs coming from and more importantly would it wise to suppress them on the LAN side? If yes, is there a simpler RouterOS option to disable these on the LAN side (as opposed to using a firewall rule)?

Thanks!
/DN

Fri Mar 15, 2024 6:26 am

Why do we add the <my_prefex>::1 IPv6 address on the bridge interface

Without it, the only LAN-side IPv6 addresses you'd have are of the link-local sort, which aren't routable. If you list your interfaces' IPs, you'll find a bunch of fe80:: stuff; that's fine for host-to-host comms on the LAN, but it doesn't make you visible on the Internet via IPv6.

(Not without NAT anyway, but that's eeeeevil

with IPv6 when you can get yourself a big fat /64 prefix for free.)

This should also answer your RA question. If there's more to it than I perceive, you might want to start a new thread, showing how you're seeing what it is you are seeing and asking the wiser IPv6 gurus around here what they think it means.

and not on the WAN interface?

You posed this as part of the above question, but it's a separate matter. You are free to assign ::2 on the WAN side as well, if that helps you in some way.

Realize, however, that with a prefix of your own, all of your LAN hosts are separately identifiable over an IPv6 configuration like this. You don't need to play port-forwarding type games, thus may have no need for Internet hosts to speak to the router directly as a proxy for a host behind it. You can give out the host's actual LAN-side 2601:: public IP and then set the gateway's firewall rules to let connections in to that IP.

Keep in mind, no NAT doesn't mean you're without a firewall. The gateway still gets to decide which inbound connections to allow.

Would be wise/safe to add another G address on the WAN interface (say <my_prefix>::/2)?

A /64 prefix gives you approximately 2 bazillion IPs to play with on your LAN. The chance of any host self-assigning ::2 would be near-zero if LLA assignment were purely random, but is actually zero because LLA is not purely random. These low-numbered addresses aren't going to conflict with anything. They're yours to assign as you see fit.

Whether splashing static IPv6 assignments around is wise, though, that's your decision as network admin. All I'll say on that point is that the IPv6 designers' intent is that you lean more on self-assigned addressing than in the v4 world. Thus all the complication surrounding addressing in v6; one size no longer fits all.

devnull0 · Fri Mar 15, 2024 8:19 pm

That was one of the most succinct and cogent explanations I've come across. Many, Many thanks!

I just need to stop viewing it from my IPv4 perspective and it starts to make sense.

Thanks again!

/DN

P.S: I'll dig around some more re. the phantom RA issue and maybe collect more data points, before I start a new/dedicated thread.

devnull0 · Mon Mar 18, 2024 5:04 am

Hello again!

<sigh> So I'm back at the 'no-ipv6-connectivity' message from the 'test ipv6 connectivity' sites again. I was playing with getting a /60 prefix from Xfinity (which did work, btw) and subnetting it to try out some new network topologies and somewhere along the line, I borked my IPv6 'world-visible' state. Wasn't too worried on account of your excellent doc so blew away all my experimental IPv6 config and re-config'ed the bare bones setup (exactly as per the doc) except with the '/60' hint. No Joy. Same result. So dumped the prefix hint altogether and accepted the default prefix (/64). I'm still seeing the same incorrect behavior.

I rebooted both, the mikrotik _and_ my pc (where I was accessing the 'check-your-ipv6-connectivity' sites) quite a few times at various stages, but that did not make any difference.

Where did I mess up?

My current Mikrotik config:

[admin@MikroTik] > /ipv6 /dhcp-client
[admin@MikroTik] /ipv6/dhcp-client> print
Columns: INTERFACE, STATUS, REQUEST, PREFIX
# INTERFACE   STATUS  REQUEST  PREFIX                           
0 ether1-WAN  bound   prefix   2601:600:xxxx:xxxx::/64, 1h59m23s

[admin@MikroTik] /ipv6/dhcp-client> /ipv6 address
[admin@MikroTik] /ipv6/address> print
Flags: D - DYNAMIC; G - GLOBAL, L - LINK-LOCAL
Columns: ADDRESS, FROM-POOL, INTERFACE, ADVERTISE
#    ADDRESS                       FROM-POOL             INTERFACE   ADVERTISE
0  G 2601:600:xxxx:xxxx::1/64      ipv6-delegation-pool  bridge-LAN  yes      
1 D  ::1/128                                             lo          no       
2 DL fe80::2ec8:1bff:xxxx:xxxx/64                        bridge-LAN  no       
3 DL fe80::2ec8:1bff:xxxx:xxxx/64                        ether1-WAN  no       

[admin@MikroTik] /ipv6/address> /ipv6 nd
[admin@MikroTik] /ipv6/nd> print
Flags: X - disabled, I - invalid; * - default 
 0  * interface=bridge-LAN ra-interval=15s-45s ra-delay=3s mtu=unspecified reachable-time=unspecified retransmit-interval=unspecified 
      ra-lifetime=30m ra-preference=high hop-limit=unspecified advertise-mac-address=yes advertise-dns=yes managed-address-configuration=no 
      other-configuration=no dns=2601:600:xxxx:xxxx::1 pref64=""

Mon Mar 18, 2024 6:24 am

No idea; it all looks sensible to me.

The only suggestion I have is to post the static configuration as well, being the output of "/ipv6/export".

devnull0 · Mon Mar 18, 2024 8:10 am

Thanks again for the quick response

Here's the '/ipv6/export' dump:

[admin@MikroTik] > /ipv6 export
# 2024-03-17 23:08:05 by RouterOS 7.14.1
# software id = R9T3-B8SI
#
# model = RB4011iGS+
# serial number = D4480EXXXXXX
/ipv6 address
add address=::1 from-pool=ipv6-delegation-pool interface=bridge-LAN
/ipv6 dhcp-client
add add-default-route=yes interface=ether1-WAN pool-name=ipv6-delegation-pool request=prefix use-peer-dns=no
/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-address=fe80::/10 dst-port=546 protocol=udp
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 ] dns=2601:600:xxxx:xxxx::1 interface=bridge-LAN ra-interval=15s-45s ra-preference=high
/ipv6 settings
set accept-router-advertisements=no
[admin@MikroTik] >

Mon Mar 18, 2024 8:26 am

You can try accept-router-advertisements=yes. That shouldn't be necessary (or even advisable) on networks where you get the default route from DHCP, so if it works, you'd set add-default-route=no in consequence. One or the other, never both.

mkx · Mon Mar 18, 2024 9:00 am

You can try accept-router-advertisements=yes. That shouldn't be necessary (or even advisable) on networks where you get the default route from DHCP ...

It has been said that default route via DHCPv6 is a MT hack. DHCPv6 doesn't provide routers, RAs are used for delivering routers (ND is a must then). What "add-default-route" property of DHCPv6 client does is to add DHCPv6 server's IPv6 address as default route. Which might work (if ISP supports this insanity) or it may not (if ISP's DHCPv6 device doesn't do IPv6 routing).

So yes, setting "accept-router-advertisements=yes" is generally a must (although it's a pity that in ROS it can't be set on per-interface basis, that would make so much more sense). Except when WAN interface is PPPoE, which has its own "add-default-route" property and should be used unless one knows much better.

Mon Mar 18, 2024 10:02 am

I hear you, @mkx, but my guide reports what worked here on the same ISP as the OP's, and it doesn't work as you say it should. I tried it both ways.

If swapping these settings fixes it, it means part of Xfinity's network works the way you think it ought to and the rest doesn't!

monotsc · Mon Mar 18, 2024 2:20 pm

are the mikrotik able to reach ipv6.google.com ?
are the pc get the proper ipv6 address from your prefix with "other-configuration=no" in ipv6-ND setting ?
maybe you should try resolving the problem from top (mikrotik side) and then from bottom (lan side devices)

devnull0 · Mon Mar 18, 2024 9:02 pm

Thank you all for your inputs

So enabling RAs fixes it irrespective of what 'add-default-route' is set to.

Specifics:

1. With 'add-default-route=yes', 'accept-router-advertisements=no'
Does not work. The default route (IPv6) points to the global address of the DHCP server (On the WAN interface).

2. With 'add-default-route=yes', 'accept-router-advertisements=yes'
Works. Two default route entries with the exiting route pointing to the DHCP server (As in 1 above) but marked as 'inactive' and an additional one pointing to the link local address (of the 'real' router) on the WAN interface.

(Usage of link-local address for the default route seems to be in line with RFC 4861 (although not explicitly mandated therein) and in keeping with current IPv6 network 'best practices'. On some further thought, this also makes sense to me as the default router _ought_ to be on the same link for configuration simplicity).

3. With 'add-default-route=no', 'accept-router-advertisements=yes'
Works. One default route entry pointing to the link local address of the 'real' router on the WAN interface.

This is my current config (with a /60 prefix from Xfinity). I'm puzzled by the different results seen by folks for the above combinations with Xfinity. Maybe Xfinity follows different policies in different regions?

Thanks!
/DN

Tue Mar 19, 2024 8:53 am

Maybe Xfinity follows different policies in different regions?

You don't change any single thing on a nation-scale network all at once. Can't be done.

Nevertheless, I've updated the article to recommend using RA to get the default route first, and only if that fails fall back to DHCPv6.

'IPv6-only' connectivity issue

'IPv6-only' connectivity issue

Re: 'IPv6-only' connectivity issue

Re: 'IPv6-only' connectivity issue

Re: 'IPv6-only' connectivity issue

Re: 'IPv6-only' connectivity issue

Re: 'IPv6-only' connectivity issue

Re: 'IPv6-only' connectivity issue

Re: 'IPv6-only' connectivity issue

Re: 'IPv6-only' connectivity issue

Re: 'IPv6-only' connectivity issue

Re: 'IPv6-only' connectivity issue

Re: 'IPv6-only' connectivity issue

Re: 'IPv6-only' connectivity issue

Re: 'IPv6-only' connectivity issue

Who is online