[BUG] IPv6: 6rd support breaks after an IPv4 change

[TheCube]

Hello,

For context, I'm using CenturyLink fiber, which offers IPv6 through 6rd.

The problem: with 6rd, IPv6 autoconfig works only on the initial connection. It does not happen on subsequent IPv4 changes.

Reminder: RFC 5969 (for 6rd) states:

The 6rd delegated prefix for use at a customer site is created by combining the 6rd prefix and all or part of the CE IPv4 address. From these elements, the 6rd delegated prefix is automatically created by the CE for the customer site when IPv4 service is obtained. This 6rd delegated prefix is used in the same manner as a prefix obtained via DHCPv6 prefix delegation [RFC3633].

When configuring the Orbi router with 6rd, it should use the configured IPv6 prefix with the IPv4 from the ISP to auto-configure an IPv6, which can then be used for router advertisements on the LAN side.

However, I have a dynamic IPv4 which changes about once a week. Every time I get a new IPv4, I lose IPv6 connectivity because the 6rd-derived IPv6 is not reconfigured after the IPv4 change.

This seems like a bug in Orbi's handling of 6rd. Only way for me to get IPv6 connectivity back is to reboot the Orbi so it does auto-config again.

Posting this in remote hopes that someone at Netgear is looking at this. Please fix in the next firmware - thanks 🙂

Router model: RBR750
Firmware version: V4.6.14.3_2.3.12

[plemans]

You could trying centurylink's gateway and connecting the orbi in AP mode. 

[FURRYe38]

Please make contact with NG support to let them know this:

https://my.netgear.com/support/contact.aspx
https://www.netgear.com/about/contact-us/

---

@TheCube wrote:

Hello,

For context, I'm using CenturyLink fiber, which offers IPv6 through 6rd.

The problem: with 6rd, IPv6 autoconfig works only on the initial connection. It does not happen on subsequent IPv4 changes.

Reminder: RFC 5969 (for 6rd) states:

The 6rd delegated prefix for use at a customer site is created by combining the 6rd prefix and all or part of the CE IPv4 address. From these elements, the 6rd delegated prefix is automatically created by the CE for the customer site when IPv4 service is obtained. This 6rd delegated prefix is used in the same manner as a prefix obtained via DHCPv6 prefix delegation [RFC3633].

When configuring the Orbi router with 6rd, it should use the configured IPv6 prefix with the IPv4 from the ISP to auto-configure an IPv6, which can then be used for router advertisements on the LAN side.

However, I have a dynamic IPv4 which changes about once a week. Every time I get a new IPv4, I lose IPv6 connectivity because the 6rd-derived IPv6 is not reconfigured after the IPv4 change.

This seems like a bug in Orbi's handling of 6rd. Only way for me to get IPv6 connectivity back is to reboot the Orbi so it does auto-config again.

Posting this in remote hopes that someone at Netgear is looking at this. Please fix in the next firmware - thanks 🙂

Router model: RBR750
Firmware version: V4.6.14.3_2.3.12

---

[TheCube]

---

@plemans wrote:

You could trying centurylink's gateway and connecting the orbi in AP mode. 

---

Yeah, I know how to work around it, but a bug is still a bug 🙂 I'd rather reboot weekly in this case.

Also the combination of Orbi in AP mode + CenturyLink router is not something I like. Orbi in AP mode requires the upstream router to respond to ICMP pings otherwise it will reboot endlessly. And interestingly, on the CenturyLink router, there is no way to enable LAN-side ping without also enabling WAN-side ping (it's all under the "stealth mode" option - it's all or nothing). And I don't really like having my router responding to pings from the internet.

[TheCube]

@FURRYe38 

---

@FURRYe38 wrote:

Please make contact with NG support to let them know this:

https://my.netgear.com/support/contact.aspx
https://www.netgear.com/about/contact-us/

---

I don't have netgear support anymore, and I'd rather not pay $90 to file a bug report they are likely to ignore. Are they really taking bug reports on a home support phone number? Not sure how best to do this

[FURRYe38]

I'll pass this on to NG.

@KevinLiT 

[TheCube]

---

@FURRYe38 wrote:

I'll pass this on to NG.

@KevinLiT 

---

Excellent, thank you so much!

In case that helps anyone, I wrote this ugly bash script (works on Linux) to detect when the Orbi needs to be rebooted. Should work with CenturyLink, but may not work elsewhere as the length of the 6rd prefix may vary depending on the ISP (/24 on CenturyLink). Just need to change/shift the sed regexp to adapt.

#!/bin/bash

ip4=$(curl -4 -s ipinfo.io | jq -er .ip)

ip6=$(sipcalc $(ip route get ::1234 | sed 's/.*src \([^ ]*\).*/\1/') | grep -F Expanded | cut -d '-' -f 2 | tr -d ' ')
ip6to4=$(echo $ip6 | sed 's/....:..\(..\):\(..\)\(..\):\(..\)..:....:....:....:..../printf "$((0x\1)).$((0x\2)).$((0x\3)).$((0x\4))"/' | bash -s)

echo "IPv4: $ip4"
echo "IPv4 from 6rd: $ip6to4"

if [[ "$ip4" != "$ip6to4" ]]; then
    echo "Reboot the Orbi" >&2
    exit 1
fi

[FarmerBob1]

I have CL Fiber and have been through exactly what you describe many times. 6rd is the easiest and cheapest way to deploy "fakish" IPv6. And depending on what the area you are in was previously setup the settings and format may be different. But if you know that it's 6rd, you're a third of the way there. Even setting it up in their own routers is a bit of a job.

There is a set group of settings that your dynamic IPv4 Address won't affect. It directs you directly to the IPv6 servers. You may already have it, but please find them attached. I use them on all my gear and depending on which Router System you're using they will behave differently. On my Orbi RBK853, IPv6 worked like a charm until a FW update halfway through v3.x. Since it's work for a while then nothing. On an MK-X3 system I have had it up and running for a long time. So . . .

But this has been discussed in depth and we'll make sure the discussion keeps going and pertinent info gets passed on. Cuz we're all goin' to need it last week.

Hope this helps.

[CrimpOn]

I am also disappointed that while Netgear has a formal program for reporting security issues, there is no method for customers to report bugs. To be fair, it is pretty obvious that the vast majority of complaints would not actually be "bugs", but are more likely to be:

• I don't understand how the product works and want help.
• I don't like the way this thing works and want you to change how it works.

In other words, accepting "bug reports" could easily turn into a typical product support task.  Doing this for 90 days is built into the cost structure of the product.  After that, it's a separate self-supporting cost center.

It seems (to me) that there are two areas for improvement:

• Detecting that the ISP has assigned a new IPv6 prefix (i.e. the "bug"), and
• Updating IPv6 DDNS with the new information as the router already does for:
  • Netgear DDNS
  • No-IP.com DDNS
  • Dyn.com DDNS

Oops.  Netgear products do "Basic DDNS Only", which probably means that IPv6 DDNS is out of scope.

[TheCube]

---

@FarmerBob1 wrote:

I have CL Fiber and have been through exactly what you describe many times. 6rd is the easiest and cheapest way to deploy "fakish" IPv6. And depending on what the area you are in was previously setup the settings and format may be different. But if you know that it's 6rd, you're a third of the way there. Even setting it up in their own routers is a bit of a job.

There is a set group of settings that your dynamic IPv4 Address won't affect. It directs you directly to the IPv6 servers. You may already have it, but please find them attached. I use them on all my gear and depending on which Router System you're using they will behave differently.

Yeah I have no issues setting up 6rd - as stated in my first message, it works fine for about a week (until IPv4 gets renewed), due to the bug I described. Not sure if you read my message completely, or if you mention it for others just in case.

Anyway - some people may or may not experience what I describe, as it all depends on how often CenturyLink (or your ISP) changes our IPv4. For almost a year I had no issues because my IPv4 was never changing. In the past few months, CenturyLink seems to have rolled out a change that causes IPv4 leases not to be renewed, with a new IP getting issued every week or so. (there's also the possibility of a recent Orbi firmware update that caused the Orbi to stop renewing DHCPv4 leases, causing new ones to get issued by the ISP). Whatever the cause is, unfortunately that makes the Orbi 6rd bug described above a real issue due to the interaction between IPv4 and 6rd.

[FURRYe38]

There has been long standing IPv6 issues on Orbi AX since v4 intro'd and hasn't been fully addressed. 

We have passed all this up to NG for review. It's mostly in there ballpark. The other part is the ISP consideration, as there are some ISP service issues that has been observed that also plays a roll in all this as well. So this is a 2-sided problem and both NG and ISP need to come to the table. We have been pushing this as best as we can where we can. 

All I can say. 

[FarmerBob1]

"Yeh! What @FURRYe38 says!!"

BUT . . . It'll all be in Netgears' court to deal with. And they have and can. Being an ex-Telco person and having had these kinds of services since the mid-90's, the manner in which Telco's deploy something like IPv6 is going to be the most minimal and cheapest manner as possible. Which 6rd and some other versions are. But with my CL Fiber 6rd worked perfectly on my 853 until about halfway through v3 FW on these things when changes were made somewhere that did show up in the IPv6 UI as text and info presentation changes. So we know that they have done it, can do it and do it well. But isn't now. If it does it's not for long.

It's working great and long term on my Nighthawk MK-83.

[TheCube]

@FURRYe38 @KevinLiT  did you end up talking to NG about this?

On my side, I ended up managing to open a support case without a support contract, but I don't think this is going anywhere. I've been asked to beta-test new firmware multiple times since March, but by now I think they're just asking me to beta-test every new iteration of firmware regardless of whether it is meant to address the issue or not. As far as I can tell, Netgear is ignoring the issue. New firmware versions don't make any difference with regard to 6rd behavior.

I don't know how many layers of communication there are between the support person and the firmware development people, but there's clearly a lot of information that's getting lost in the process. 4 months after opening the case, I am not very confident the issue is actually getting looked at.

[FURRYe38]

Nothing currently. We've posted about this as well. 

What FW version are you currently using? 

I know NG is staging a beta for this community. FW should be forthcoming very soon I believe. 

[TheCube]

@FURRYe38 

I'm currently on beta firmware version 7.2.6.21 which they sent me yesterday. I've tested a bunch of beta versions in the 7.2 series in the past 4 months.

(I have signed an NDA for the beta firmware, but the NDA doesn't prevent me to disclose the above - I'm only prevented from sharing the files)

[FURRYe38]

Are you in the beta project or did you submit the request thru the surveymonkey link? 

[TheCube]

@FURRYe38 the support person handling my support case is just giving me beta firmware builds every few weeks. I'm not aware of a beta project or of a surveymonkey link - I don't know what you are referring to.

[FURRYe38]

AH ok. Thank you for the clarification. 

[TheCube]

Netgear somehow provided me with a trial firmware that fixed the issue back in September 2023. They've emailed me recently to ask me to try the new official release, which I just did. The new firmware release is still broken. I wish I had kept the trial version.

I'm now running a script on my raspberry pi that continuously tries to detect the bug, and reboots the Orbi when it is hit.

I've received DMs on other forums from a few other people impacted by this. I am now giving them by detection/reboot script. I'm not sure if anyone from Netgear is reading this, but 14 months later this is just sad lol. Support case 47156485

[FURRYe38]

What Firmware version is currently loaded?

What beta FW version did you get that seem to fix what you were seeing? 
What is the Mfr and model# of the Internet Service Providers modem/ONT the NG router is connected too?

Have you tried a custom IPv6 DNS address vs decteded ISP IPv6 DNS? 

[TheCube]

Hey - I replied to your DM where you asked some of these questions.

Note that the bug has been independently reproduced by BugCrowd through the Netgear bug bounty program. They used their own hardware to reproduce (probably in a black box environment - no ISP, no ONT). This is purely a firmware issue - IPv4 address changes aren't properly handled by the IPv6 stack. The Netgear support case (and Bugcrowd submission) has all the details

[FURRYe38]

OK sounds good. 
Will get this to NG and see if we can get some more traction on it. 
Ya the fix in the beta they gave you didn't get into following released versions. Wondering why. 🙄
See what we can do.