DHCPv6 client - dismiss ULA prefixes

RouterOS General
1

I have a location with Starlink uplink where since a few weeks the uplinks hands out fd44:: prefixes to DHCPv6 clients. This really sucks, as it breaks IPv6 connectivity completely and introduces a very noticeable delay on on each connection before the client stack falls back to v4. When ever I receive such a ULA prefix, a release → renew gives a good 2xxx:: GUA prefix.

Obviously something is broken upstream.

My question now is how can i best mitigate this on the router side? sure, I can add a dhcpv6 client script, but how would i best check in that script if I’m getting a ULA or a GUA prefix?

any ideas how to best address this?

anyone with starlink seeing the same issue?

thanks & best

2

Did you ask Starlink support why this is happening, if it is a problem or if it is intentional and supposed to work?

3

Did I ask the Starlink WHAT? XD I fear they don’t have any support in the classical meaning.

Well, I see that they have their IPv6 DNS recursive resolver in that fd44:: range, but I have no idea why they would had out fd44:: prefixes and then a second later give me a 2xxx:: prefix. Only see the implications.

Looking for a local work around until the upstream issue is resolved.

4

I have a similar problem in the ipv4 space. My router should get a public IP. The ISP will update firmware on their gateway and when it reboots it starts handing out private IPs before processing its passthrough IP configuration. So I’ll get a private address.

Seems like my script should work for you, changing 192.168.0.0/16 with fd44::/16 (or fd::/8), and changing /ip/dhcp-client to /ipv6/dhcp-client.

:delay 15s;
:if ($bound=1) do={
    :local ipaddress $"lease-address";
    :if ($ipaddress in 192.168.0.0/16) do={
        :log info "WAN IP is $ipaddress. Releasing and renewing.";
        /ip/dhcp-client release [find interface="ether1"];
        :delay 5s;
		}
	:log info "WAN IP is $ipaddress";
}
1 Like
5

Ok I do not have Starlink but my own ISP has a Helpdesk where I can ask such questions and they will be (maybe after an initial “huh?” response) forwarded to a technician.

When there is a reason to initially issue another address, e.g. to check firmware level or other admin procedures, they should use a short lease time so the router will renew and get the correct address.

But I guess at Starlink only Grok is at the controls…

6

Thanks, that’s exactly the starter I needed!

Here what I ended up for the v6 dhcp client:

:delay 15s;
:if ($"pd-valid"=1) do={
    :local prefix $"pd-prefix";
    :if ($prefix in fd00:/8) do={
        :log info "WAN IPv6 prefix is $prefix in fd00::/8. Releasing and renewing.";
        /ipv6/dhcp-client release [find interface="UPLINK-SL"];
        :delay 5s;
    }
    :log info "WAN IPv6 prefix is $prefix";
}

Lets hope that works aroud the issue.

Thanks again!

1 Like
7

I have a wild idea: try setting 2000::/3 (or a longer prefix if you know Starlink’s allocation) as a prefix-hint of the DHCPv6 Client.

8

I’ll try that.

My current hypothesis is that fe44:: is the local net of the starlink router and its not handing out a GUA prefix because its in a renewal itself/has lost satellite uplink or whatever.

9

What does the “Prefix Expires After” field show in the DHCPv6 client?

10

the prefixes are relatively short lived, like 5mins or so.

11

Ok, so it isn’t really an issue, you see it only when testing.

1 Like
12

No, definitively not.

The complains of the users downstream triggered my involvement (v6 timeout before v4 fallback), I didn’t do any testing, just debugging.

13

and when you connect to a ROS showing fe44:: as the assigned prefix, you start to wonder. when the issue pops up more often you start looking for a workaround.

don’t you?

14

This exact issue happens to me…, i tought was only me

15

I mean: this issue only occurs in the first 2-5 minutes after you powered up the system. Assuming it would be powered up all the time the users need it, why would everyone complain?

16

No, that’s not whats going on. Your understanding of DHCPv6 and prefix lifetimes might not be up to whats really going on.

I do see that the fe44:: prefixes are coming to the router with with an uptime > 1 month, while right after boot its working fine. anyhow, you don’t have starlink, you don’t have this problem, I have my workaround. It feels like you really want to keep the old forum spirit alive; judging before understanding.

Please don’t.

All the best

1 Like
17

Your problem is that you tell us something different every time. Just to find out if you would get a wrong prefix assigned for a long time, I asked you what the valid time was en you said 5 minutes or so.

That would mean the router requests again at that time, and when the Starlink has a valid prefix by then it would get that.

But now you are presenting an entirely different situation. Still, you refuse to take it up with the people where the problem occurs.

Anyway, thanks for explaining that Starlink is crap. I live in a densely populated area and would not consider it anyway, but sometimes other people ask me. So I can now tell them “whenever you get that, make sure you disable IPv6”…

1 Like