Struggling to receive IPv6 prefix delegation from ISP

saluki · Wed Jan 08, 2025 10:23 am

Hi all,

Apologies if I'm missing something obvious here, this is my first time with a Mikrotik device.

I'm using a hAP ax³ as my home router, and am plugging the WAN/ether1 port directly into my ISP box. I have no issues at all with receiving an IPv4 address over DHCP and then using it with NAT.

However, I've been unable to get an IPv6 prefix.

I know my ISP provides IPv6, as I have used it previously on their provided router. After contacting them, I have confirmed that they do provide IPv6 /48 prefixes over DHCPv6, and that it should "just work".

I have used the IPv6 -> DHCP Client menu to try and configure this. I am requesting a /48 prefix but it gets stuck on "searching...". If I request just an address, I get assigned a single IPv6 address. If I request an address and a prefix, I get the searching problem.

This suggests to me that the connection is fine, but that I've made a mistake somewhere.

I have created an IPv6 pool (also /48), and I am explicitly asking for a /48 in DHCP client. I have tried fiddling with add default route, rapid commit and other settings in the DHCPv6 client, but have not had any luck getting further with the v6 prefix.

I have not adjusted any settings outside of the DHCP client and the pools menu.

If anyone has any suggestions, or needs some more information to get a good picture of my setup, please just ask.

Kentzo · Wed Jan 08, 2025 7:19 pm

We need to see the current IPv6 config: `/ipv6/export`

saluki · Wed Jan 08, 2025 8:48 pm

Ah, apologies. Thanks for highlighting this.

Configuration is as follows:

/ipv6/export 

# 2025-01-08 18:46:37 by RouterOS 7.16.2

# software id = soft_id

#

# model = C53UiG+5HPaxD2HPaxD

# serial number = my_serial

/ipv6 pool

add name=ipv6-pool prefix=::/0 prefix-length=48

/ipv6 dhcp-client

add add-default-route=yes comment=LITFIBRE-IP6 interface=ether1 pool-name=ipv6-pool pool-prefix-length=48 request=address,prefix use-interface-duid=yes 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-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 ] managed-address-configuration=yes other-configuration=yes

Setting use-peer-dns=no to yes does not make a difference in the current configuration.

mkx · Wed Jan 08, 2025 9:16 pm

I don't know if that would fix the problem, but:

don't create IPv6 pool manually. DHCPv6 client will create it automatically after it receives prefix.
don't use prefix-length=48 (either set it to 64 or omit it altogether), it doesn't do what you probabky think it does. It's about prefix length when they are handed out: either to DHCPv6 server if your router is set up to pass prefixes further) or when assigning ipv6 address using syntax address=::1 from-pool=<pool name>.
If you want to indicate desired prefix size to upstream DHCPv6 server, you can set prefix-hint=::/48 property of DHCPv6 client (but it's a hint and upstream DHCPv6 server is likely to ignore it).
It could be that your ISP is handing out smaller (longer) prefixes than /48 (mine is giving /56, some are giving /60 and some brain-dead ISPs are giving /64) and since your setting says you'll be using /48 prefixes, any received prefix smaller than /48 might be ignored by DHCPv6 client.

Also: setting add-default-route=yes is conceptually wrong, but it might work with some ISPs. What this option does is that it takes DHCPv6 server's (link-local) address and uses it as upstream gateway in default IPv6 route. This works fine if DHVPv6 server is a router as well (either actually intended one or just happpens to support routing), but thr correct way would be to tisable this property and set /ipv6/settings/set accept-router-advertisements: yes (default is effectively "no" while ideally that would be enabled per interface).
But the setting, discussed in previous paragraph, doesn't prevent your DHCPv6 client from obtaining prefix.

saluki · Wed Jan 08, 2025 9:28 pm

Thank you for your guidance.

I have gone ahead and deleted my manually created pool.

When trying to enable accept router advertisements, I get an error like so:

/ipv6/settings/set accept-router-advertisements: yes
expected end of command (line 1 column 20)

Additionally, the DHCPv6 client isn't happy when I try to specify no pool, or a blank prefix. (When I set it to /64, it gets stuck in the "searching..." state again - my ISP has assured me they are assigning /48s in this case)

Is this an issue with WinBox, the router, or my understanding?

mkx · Wed Jan 08, 2025 9:41 pm

/ipv6/settings/set accept-router-advertisements: yes
expected end of command (line 1 column 20)

Sorry, it should be

/ipv6/settings/set accept-router-advertisements=yes

If it doesn't allow you to unset prefix-length, then set it to 64.

You can omit requesting address ... it's not always needed and some DHCP servers might have problems providing both in response to single request.

Are you using winbox4? I'm not closely following its development, but it might still have some teething problems here and there. So you can try using webfig (web UI) or CLI to verify that DHCPv6 client settings are indeed as intended.

saluki · Wed Jan 08, 2025 9:54 pm

The amended command worked to enable `accept-router-advertisments`.

I'm not actually entirely sure what version of winbox I'm running, but I am now using webfig instead and have verified the settings match expectations.

I have removed the request for a single address, but am still not being allocated a prefix.

Kentzo · Thu Jan 09, 2025 2:50 am

add action=accept chain=input comment="defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=udp src-address=fe80::/10

The `src-address=fe80::/10` may be the culprit. Either remove it or replace with `in-interface=ether1` instead.

Please post the update config after you make changes, just to make sure.

saluki · Thu Jan 09, 2025 8:04 pm

Thank you for the suggestion.

I made the requested change, but it does not appear to have had any impact on the IPv6 delegation.

New configuration:

/ipv6 dhcp-client
add comment=LITFIBRE-IP6 interface=ether1 pool-name=ipv6-pool \
    request=prefix
/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 in-interface=ether1 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 ] managed-address-configuration=yes \
    other-configuration=yes
/ipv6 settings
set accept-router-advertisements=yes

mkx · Thu Jan 09, 2025 8:09 pm

Just to make sure: your WAN is connected to ether1?

saluki · Thu Jan 09, 2025 8:11 pm

Yeah, my WAN is on `ether1` and IPv4 is working fine over it.

I've tried briefly toggling my IPv6 firewall down and back up and was unable to receive a prefix when it was down, suggesting that it might not be a firewall problem.

Kentzo · Thu Jan 09, 2025 8:30 pm

Is it feasible to disable all IPv6 firewall rules, reboot the router and then attach the output of `/ipv6/pool/print`?

saluki · Thu Jan 09, 2025 8:47 pm

After disabling the rules, rebooting and running that command I get a completely blank output.

Kentzo · Thu Jan 09, 2025 9:22 pm

In that case I would try to sniff ICMPv6 and DHCPv6 traffic on ether1. That does not seem right.

saluki · Fri Jan 10, 2025 11:30 am

I'm getting no IPv6 connectivity at all (I can't even acquire a prefix, after my recent firewall update mentioned in this thread).

But if I disable that rule, I can acquire a single IPv6 address again.

I have attached a dump that I believe covers my IPv6 traffic on ether1.

During the capture, I requested a prefix, changed my firewall rules, and then requested a single IP.

The attached file is a pcap

ipv6debug.txt

One of the IPv6 addresses in the pcap is registered to my ISP.

mozerd · Fri Jan 10, 2025 12:17 pm

Give the following a TRY <>

First: Disable your ipv6 Firewall
Second: Delete ALL your ipv6 configuration because you will start from scratch
Third: Once you have completed the 2 steps above THEN in Winbox Terminal issue the following directives - each one independently

1st directive:

/ipv6 dhcp-client
add add-default-route=yes comment="delegate ISP-assigned prefix" interface=\
ether1 pool-name=isp-ipv6 prefix-hint=::/48 request=address,prefix \
use-peer-dns=no

2nd directive:

/ipv6 nd
set [ find default=yes ] dns=2606:4700:4700::1111,2606:4700:4700::1001 \
interface=ether1 mtu=1500 ra-lifetime=none reachable-time=5m

3rd directive:

/ipv6 nd prefix default
set preferred-lifetime=4h valid-lifetime=4h

4th directive:

/ipv6 settings set accept-router-advertisements=yes max-neighbor-entries=8192

NOW REBOOT your Router

If you ipv6 confiuration is now working TURN ON the ipv6 Firewall

saluki · Fri Jan 10, 2025 12:29 pm

Hi mozerd

Thanks for the suggestion. I have given it a shot but unfortunately I still don't get IPv6 connectivity.

I have had no errors, the configuration seems to apply fine but after a reboot it gets stuck in the "searching..." state again.

I also noticed that my DoH server may be causing a problem, but after disabling it I found no difference either.

If anyone suspects the issue is something that could be resolved faster with information from my ISP, I have a pretty quick line of communication with them and could request information. The only thing they haven't been able to support with was the router, as it isn't provided by them - which is fair enough.

mozerd · Fri Jan 10, 2025 12:43 pm

@saluki
Pleasse reboot your ISP device ... best to turn the power OFF wait for 5 minutes then turn the power back on again ....

Also please confrim that your ISP device is in BRIDGE mode and not in gateway mode PRIOR to doing the step above ...

saluki · Fri Jan 10, 2025 12:50 pm

My ISP device is a cryptic box on the wall that I have no direct access to. I can't directly request or check what mode it is in.

I have just tried powering it off for a few minutes and then bringing it back up - but no luck still.

I have a separate router they provided, which is switched off and not involved in my current network architecture. It used to act as the gateway, so I assume the box is running in bridge mode. I could get in touch with my ISP to ask them to verify this, although I'm not sure if my IPv4 internet would be working if it was in gateway mode.

mozerd · Fri Jan 10, 2025 1:08 pm

Is the cryptic box getting a ipv6 address?

I suspect that there is a ipv6 mismatch happening between your cryptic box and your Tik Router .... best that you have your ISP check their DHCPv6 server to view how YOUR Tik ipv6 solicitation is taking place ....

Very interesting BTW

saluki · Fri Jan 10, 2025 1:36 pm

Yeah, I'll drop them a message now and see if they can shed any light on it. I'll be back here when I hear something.

It is pretty interesting, at this point I am quite invested in just figuring out why this is happening. I've done IPv6 from my own ASN on a cloud router (just BIRD2) before and I had some troubles with that but this is possibly something to do with me not having a good understanding of my ISP system.

saluki · Fri Jan 10, 2025 1:59 pm

Alright, I've heard back from my ISP.

Their network team cannot see the ONT (cryptic wall box) and the IP allocation is not coming through it anymore. They cannot see very much because of this.

My Mikrotik is plugged into the ONT and has working internet via it.

This isn't exactly the smoking gun pointing at the problem I hoped for, but rather another weirdness.

Once again, I have checked that my ISP router is able to connect via IPv6 when it is plugged into the ONT.

rextended · Fri Jan 10, 2025 2:05 pm

you use pppoe or vlan?
the dhcpv4 is directly over ether1?
what is your LAN interface?

saluki · Fri Jan 10, 2025 2:06 pm

And another consideration is my ISP recently disconnected me from their CGNAT to give me a dedicated IP(v4) address. I'd assume this shouldn't cause any problems, as I can see IPv6 works fine via the provided router, but it might cause some abnormal network conditions.

saluki · Fri Jan 10, 2025 2:11 pm

you use pppoe or vlan?
the dhcpv4 is directly over ether1?
what is your LAN interface?

DHCPv4 is working over ether1 yes.

My LAN interface is bridge.

And I'm using PPoE currently as I didn't want to configure VLANs just yet.

rextended · Fri Jan 10, 2025 2:25 pm

you use pppoe????
problably is pppoe that provide you the IP connectivity, not the dhcp on ether1...
I can fail on this because I do not understand correctly how you have setup yout router...
The first user that reply you on this topic must ask first how is configured and attached your router...

put /ip route pri on terminal and post results on forum, obfuscating (not removing) real IPs (not the 192.x, 10.x, 172.x obviously....)

saluki · Fri Jan 10, 2025 2:28 pm

I'm fairly sure I'm using PPPoE, as I haven't configured any VLANs.

/ip route pri 
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, d - DHCP
Columns: DST-ADDRESS, GATEWAY, DISTANCE
    DST-ADDRESS      GATEWAY       DISTANCE
DAd 0.0.0.0/0        1.1.1.1         1
DAc 1.1.1.1/20  ether1               0
DAc 192.168.1.0/24   bridge               0

My public IP replaced with 1.1.1.1

rextended · Fri Jan 10, 2025 2:30 pm

I do not see any pppoe interface in routes...

also /int pri please?

rextended · Fri Jan 10, 2025 2:33 pm

while waiting for /interface print

test this:

test code

/ipv6 settings
set accept-redirects=yes-if-forwarding-disabled accept-router-advertisements=yes-if-forwarding-disabled forward=yes max-neighbor-entries=32768
set multipath-hash-policy=l3 ; # this line do error if not used on v7.16.2 and up

/ipv6 dhcp-client
remove [find]
add add-default-route=no disabled=no interface=ether1 pool-name=dhcpv6-pool pool-prefix-length=64 prefix-hint=::/0 \
    rapid-commit=no request=prefix use-peer-dns=yes

/ipv6 address
remove [find where dynamic=no]
add address=::/64 advertise=yes disabled=no eui-64=yes from-pool=dhcpv6-pool no-dad=no interface=bridge

/ipv6 nd prefix default
set autonomous=yes preferred-lifetime=1w valid-lifetime=4w2d

/ipv6 nd
set [ find default=yes ] advertise-dns=yes advertise-mac-address=yes disabled=no hop-limit=64 managed-address-configuration=no \
    mtu=unspecified other-configuration=no ra-delay=3s ra-interval=3m20s-10m ra-lifetime=30m reachable-time=unspecified \
    retransmit-interval=unspecified interface=bridge
set [ find default=yes ] ra-preference=medium ; # this line do error if not used on v7.16.2 and up

saluki · Fri Jan 10, 2025 2:44 pm

Routes:

/interface print 
Flags: R - RUNNING; S - SLAVE
Columns: NAME, TYPE, ACTUAL-MTU, L2MTU, MAX-L2MTU, MAC-ADDRESS
 #    NAME    TYPE      ACTUAL-MTU  L2MTU  MAX-L2MTU  MAC-ADDRESS      
 0 R  ether1  ether           1500   1568       9214  F4:1E:57:2D:D4:5B
 1  S ether2  ether           1500   1568       9214  F4:1E:57:2D:D4:5C
 2 RS ether3  ether           1500   1568       9214  F4:1E:57:2D:D4:5D
 3 RS ether4  ether           1500   1568       9214  F4:1E:57:2D:D4:5E
 4  S ether5  ether           1500   1568       9214  F4:1E:57:2D:D4:5F
;;; defconf
 5 R  bridge  bridge          1500   1560             F4:1E:57:2D:D4:5C
 6 R  lo      loopback       65536                    00:00:00:00:00:00
 7 RS wifi1   wifi            1500   1560       1560  F4:1E:57:2D:D4:60
 8 RS wifi2   wifi            1500   1560       1560  F4:1E:57:2D:D4:61
 9 RS wifi3   wifi            1500   1560       1560  F6:1E:57:2D:D4:60
10 RS wifi4   wifi            1500   1560       1560  F6:1E:57:2D:D4:61

The test code doesn't seem to have got it working, although I have not performed a restart of the router after making the changes, just run a release on the dhcp6 client.

rextended · Fri Jan 10, 2025 2:50 pm

Now is clear that you do not use pppoe or vlan, but just DHCPv4 client.

Restart is not needed.

try this:

test2 code

/ipv6 address
remove [find where dynamic=no]

/ipv6 dhcp-client
remove [find]
add add-default-route=yes disabled=no interface=ether1 rapid-commit=no request=address use-peer-dns=yes

If you obtain an IPv6, put it here obfuscating it (but not the /xx part....)

also /ipv6 rou pri and /ipv6 address pri with results obfuscated.

saluki · Fri Jan 10, 2025 2:57 pm

Perfect, thank you for verifying for me.

I do obtain an IPv6 address correctly when running that code, in the range 2a10:bcc0::/29 (owned by my ISP)

This is correct for the allocation of a single address.

/ipv6 rou pri 
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, d - DHCP
Columns: DST-ADDRESS, GATEWAY, DISTANCE
    DST-ADDRESS                GATEWAY                          DISTANCE
DAd ::/0                       fe80::a05:e2ff:feb0:9e8f%ether1         1
DAc ::1/128                    lo                                      0
DAc ISP_PROVIDED_IP/128  ether1                                  0
DAc fe80::%ether1/64           ether1                                  0
DAc fe80::%bridge/64           bridge                                  0

/ipv6 address pri 
Flags: D - DYNAMIC; G - GLOBAL, L - LINK-LOCAL
Columns: ADDRESS, INTERFACE, ADVERTISE
#    ADDRESS                       INTERFACE  ADVERTISE
0 D  ::1/128                       lo         no       
1 DL fe80::f61e:57ff:fe2d:d45c/64  bridge     no       
2 DL fe80::f61e:57ff:fe2d:d45b/64  ether1     no       
3 DG ISP_PROVIDED_IP/128     ether1     no

Relevant outputs provided.

rextended · Fri Jan 10, 2025 3:02 pm

Ok, if you can only receive (correctly) one /128 and you can ping correctly 2606:4700:4700::1111 from your router,
is meaning that the "cryptic box" probably is just configured to do bridging,
and the Juniper router of your ISP provide public IPv4 on DHCP and single IPv6...

So you must ask your ISP for further checks, in meantime or if your ISP can't help,
you can use NATv6 with true IPv6 provided for free from hurricane electrics (see other posts) to use internally on your own network...
viewtopic.php?p=1110241#p1110122

EDIT: some edits for add link, detail on device used from the ISP, etc. ...

mozerd · Fri Jan 10, 2025 3:06 pm

Once again, I have checked that my ISP router is able to connect via IPv6 when it is plugged into the ONT.

I suspect this means that your ISP has a secuirty lock on the mac address of their provided Router.

So you can try the following [assuming you are still using the config I provided you]

Find out the MAC Address of the ISP Router for the WAN connection THEN on the TIK Router change the MAC addy of ether1 to match that and see if that solves the problem.

Or you can ask them if their security protocal ties their provided Router MAC addy or serial number to your account --- they can change that to your Tiks either1 MAC addy or Tiks serial number if that is the case ...

saluki · Fri Jan 10, 2025 3:23 pm

Once again, I have checked that my ISP router is able to connect via IPv6 when it is plugged into the ONT.
I suspect this means that your ISP has a secuirty lock on the mac address of their provided Router.

So you can try the following [assuming you are still using the config I provided you]

Find out the MAC Address of the ISP Router for the WAN connection THEN on the TIK Router change the MAC addy of ether1 to match that and see if that solves the problem.

Or you can ask them if their security protocal ties their provided Router MAC addy or serial number to your account --- they can change that to your Tiks either1 MAC addy or Tiks serial number if that is the case ...

Thanks for the suggestion, the ISP has confirmed that they do not use any MAC whitelisting and that the router "should" work fine.

I might give rextended's HE idea a go as there is clearly something wrong between me and my ISP systems and we could be stuck trying to debug it for days. I'll report back once I've had time to try Tunnelbroker.

rextended · Fri Jan 10, 2025 3:25 pm

added on previous post, if you not notice it:

"cryptic box" probably is just configured to do bridging,
and the Juniper router of your ISP provide public IPv4 on DHCP and single IPv6...

a05:e2 -> 0a:05:e2 -> 08:05:E2 Juniper https://hwaddress.com/oui-iab/08-05-E2/
f61e:57 -> f6:1e:57 -> F4:1E:57 MikroTik (as Routerboard.com) https://hwaddress.com/oui-iab/F4-1E-57/

mozerd · Fri Jan 10, 2025 3:34 pm

Their network team cannot see the ONT (cryptic wall box) and the IP allocation is not coming through it anymore. They cannot see very much because of this.

This is wrong …. If the network team cannot see the ONT …. ESCALATE TO some one who can … do not give up … this is not rocket science … someone from the NOC should be able to help you to resolve this ….

rextended · Fri Jan 10, 2025 3:37 pm

If the network team cannot see the ONT …. ESCALATE TO some one who can … do not give up … this is not rocket science … someone from the NOC should be able to help you to resolve this ….

+100

mkx · Fri Jan 10, 2025 3:41 pm

Their network team cannot see the ONT (cryptic wall box) and the IP allocation is not coming through it anymore. They cannot see very much because of this.
This is wrong …. If the network team cannot see the ONT ….

Another possibility (very common where optical network owner is different than ISP) is that ISP network team never saw ONT, they actually saw their own router. With their router out of the way, ISP can't see much. And ONT will be managed (and seen) by ON owner's network team (but you as ISP's customer don't have "right" to talk to them).
At least that's the way I have on one of my locations (GPON, owned by open networks provider ... their ONT ... and ISP who could access only their router if I hadn't replaced it with a Mikrotik

so now they can't see much).

saluki · Fri Jan 10, 2025 3:42 pm

Yeah, technically they MUST be able to see the ONT somewhere but this looks like it'll be a more long term problem.

Tunnelbroker works amazingly well actually, it took about a minute to get it working and my whole network now has "IPv6". I'm using 6to4, but I'm assuming there's probably a way to switch it to 6to6 as I can get a single IP6 address and it's probably going to be a little better?

I'm assuming my ISP are looking at some router management tool that Calix provided them, which would explain why they can't see the ONT if the software relies on their router. If I can get internet through their network then they must be able to see the ONT, as it sits between my router and them.

mozerd · Fri Jan 10, 2025 3:43 pm

Us tunnel broker only as a last resort …

Your Tik router should work … your ISP is doing something WRONG ..

mkx · Fri Jan 10, 2025 3:47 pm

I'm using 6to4, but I'm assuming there's probably a way to switch it to 6to6 as I can get a single IP6 address and it's probably going to be a little better?

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.

saluki · Fri Jan 10, 2025 3:48 pm

Thanks for advising me on this. I will push my ISP on it.

Kentzo · Fri Jan 10, 2025 6:14 pm

During the capture, I requested a prefix, changed my firewall rules, and then requested a single IP.

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.

saluki · Sat Jan 11, 2025 2:06 am

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.

mozerd · Sat Jan 11, 2025 5:59 pm

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.

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 ?

saluki · Mon Jan 13, 2025 10:27 am

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?

mozerd · Tue Jan 14, 2025 6:55 am

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.

Very strange ....

saluki · Wed Jan 15, 2025 8:00 pm

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

tdw · Thu Jan 16, 2025 2:45 pm

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.

mozerd · Thu Jan 16, 2025 3:15 pm

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?

saluki · Thu Jan 16, 2025 8:05 pm

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.

saluki · Thu Jan 16, 2025 8:36 pm

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.

tdw · Thu Jan 16, 2025 8:45 pm

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.

saluki · Fri Jan 17, 2025 12:22 am

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).

tdw · Fri Jan 17, 2025 1:37 am

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.

saluki · Fri Jan 17, 2025 10:11 am

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.

saluki · Mon Jan 20, 2025 8:24 pm

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.

Kentzo · Mon Jan 20, 2025 9:45 pm

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 ... nt-page-1/ for sanitizing wireshark traces non-destructively. In your pcap file you messed up IP addresses.

tdw · Mon Jan 20, 2025 10:09 pm

+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.

saluki · Mon Jan 20, 2025 11:58 pm

Well, I got it working.

For some reason, setting the prefix hint to 0 fixed it.

I had tried this previously, so some other configuration change must have been necessary.

I do now have working IPv6 on my network now though - which is neat.

Thank you so much to everyone who got involved in helping me figure this one out!

mozerd · Tue Jan 21, 2025 10:43 am

Well, I got it working.
For some reason, setting the prefix hint to 0 fixed it.

Nice to read that you have it now working ...

I'm very curiouse as to the prefix size they actually gave you because a prefix hint to 0 in the IPv6 prefix field indicates that the requesting router has no preference for the prefix ...

mkx · Tue Jan 21, 2025 11:28 am

Well, I got it working.
For some reason, setting the prefix hint to 0 fixed it.
Nice to read that you have it now working ...

I'm very curiouse as to the prefix size they actually gave you because a prefix hint to 0 in the IPv6 prefix field indicates that the requesting router has no preference for the prefix ...

And prefix hint ::/0 is default ... it's not shown in @OPs first shown configuration so it's been at default initially. So it must have been something other which made the difference.

saluki · Tue Jan 21, 2025 7:07 pm

Well, I got it working.
For some reason, setting the prefix hint to 0 fixed it.
Nice to read that you have it now working ...

I'm very curiouse as to the prefix size they actually gave you because a prefix hint to 0 in the IPv6 prefix field indicates that the requesting router has no preference for the prefix ...

They did allocate a /48 prefix as requested. Although with the prefix hint set to 48 they won't allocate it. The prefix hint must be 0. Weird.

saluki · Tue Jan 21, 2025 7:09 pm

Nice to read that you have it now working ...

I'm very curiouse as to the prefix size they actually gave you because a prefix hint to 0 in the IPv6 prefix field indicates that the requesting router has no preference for the prefix ...
You're correct yeah. I'm not sure if it's worth tracking down the specific configuration issue that caused the problem as I have a feeling fhat they [Lit Fibre/CityFibre] made some changes on their end at some point because packet captures started showing a bit more data later on.

Also I did apply a firmware update, which could have had an impact.

And prefix hint ::/0 is default ... it's not shown in @OPs first shown configuration so it's been at default initially. So it must have been something other which made the difference.

mozerd · Tue Jan 21, 2025 9:36 pm

They did allocate a /48 prefix as requested. Although with the prefix hint set to 48 they won't allocate it. The prefix hint must be 0. Weird.

Yes that is weird and frankly makes no sense to me.
So does everyone get a /48 or must the subscriber request that on a per account basis via what method? ONT, eMail, phone, lettermail ???