Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
To those from Juniper, You are actively harming your own sales, and IPv6 deployment. On the SRX3xx line, Junos artificially limits update-router-advertisement to three downstream interfaces. In practice, that means the box will only automatically inject delegated IPv6 prefixes into RAs on three VLANs. This is not a hardware limit. This is not a throughput limit. This is not “the ASIC can’t handle it.” This is an arbitrary cap in software. Here is the operational problem: I have an SRX-340 acquired through Juniper, fully legitimate. It’s being used in my home. I have five VLANs: • management • desktops • servers • iot • guest On IPv4, this is trivial. Each VLAN is routable, each segment is isolated, everyone’s happy. On IPv6, because of this three-interface limit, I can only have automatic prefix delegation and router advertisements on three of those VLANs. After that, Junos just refuses the config. There is no documented way to extend it. There is no warning in the product literature that “this feature stops working at 3.” There is no published technical justification, in fact, I can't find anything published about this limit at all. The result is that I cannot deploy IPv6 cleanly across my entire network using Juniper’s intended/automated method. My choices are: • break my segmentation model to fit an undocumented limit, or • start doing manual RA gymnastics and scripting around Junos just to reach VLAN #4 and VLAN #5. Neither of those is what we should be calling “enterprise-ready IPv6.” It's not even "home-ready IPv6". It's embarrassing. One of the small branches where I installed an SRX-345 has over 40 vlans. We heavily segmented to protect the network from east-west movement, for compliance, and to prevent the spread of ransomware. This is exactly the kind of paper-cut that keeps corporate networks from rolling out IPv6 everywhere. It’s not that IPv6 is “hard.” It’s that Juniper quietly ship artificial restrictions and then make the fix “buy a bigger box that you otherwise don't need.” I for one am not buying it. If this is a licensing/commercial segmentation decision (“branch” products get three VLANs of working IPv6 and if you need more you’re supposed to move up-market and spend tens of thousands more), then please say that, on the record, so operators can plan accordingly (buy from another vendor) and so architects can see what they’re actually buying. If it’s not intentional product gating, then please remove the limit, and provide that to everyone who has bought an SRX-3xx. There is no technical reason an SRX-3xx should only be able to advertise delegated IPv6 prefixes on three VLANs. There are both hardware and software solutions that work as UTM firewalls for branch offices that don't have automatic limits. I am not beholden to Juniper, and I can/will buy other solutions if I have to. That is not helping IPv6 adoption. I opened a jcare ticket on it years ago, and got crickets, so now we're going to see if sunlight is the best disinfectant. I'm not your biggest customer but I've purchased well over $700,000 worth of Juniper gear and jcare. I'm asking that Juniper publicly commit to fixing this, because I assure you I can buy something else. Regards, Andrew Kirch AS401854
I would have no reason to assume there is anything designed or planned here. It's just people don't use IPv6, and IPv6 things can be broken and nothing happens. Even if the feature would work with a larger number of interfaces. I don't think the design is going to be very desirable, as you cannot guarantee which prefix is assigned to which interface, which implies if you add/remove downstream interfaces, you reorder prefixes they get. And you probably don't want your servers to change their prefixes when you add new VLAN. I don't blame Juniper here at all, this is every vendor, every feature. I blame myself, and the community. We were here when IPv6 happened, and we cocked it up. This pretend dual-stack environment, where IPv6 actually isn't business critical, wasn't supposed to happen. Time gap between IPv4 RFC and IPv6 RFC is smaller than the time gap between IPv6 RFC and today, we've had longer tenure of migration to IPv6 than we have IPv4 only. There is no other way to frame this than as an abject failure. And trying to paint this in some other light, just removes any traction to actually solve this. Actual solution will need some kind of voluntary or involuntary action by oligarchic big tech companies, so that they'd have a future date upon which they stop serving IPv4, which will create motivation for downstreams to adopt IPv6. Maybe someone could convince the FTC, FCC or DOJ that IPv4 is an antitrust issue they need to regulate. Which it absolutely is, it is an additional barrier of entry for many types of businesses favoring established large players over new entrants. On Sun, 2 Nov 2025 at 05:34, Andrew Kirch via NANOG <nanog@lists.nanog.org> wrote:
To those from Juniper,
You are actively harming your own sales, and IPv6 deployment.
On the SRX3xx line, Junos artificially limits update-router-advertisement to three downstream interfaces. In practice, that means the box will only automatically inject delegated IPv6 prefixes into RAs on three VLANs.
This is not a hardware limit. This is not a throughput limit. This is not “the ASIC can’t handle it.” This is an arbitrary cap in software.
Here is the operational problem:
I have an SRX-340 acquired through Juniper, fully legitimate. It’s being used in my home. I have five VLANs: • management • desktops • servers • iot • guest
On IPv4, this is trivial. Each VLAN is routable, each segment is isolated, everyone’s happy.
On IPv6, because of this three-interface limit, I can only have automatic prefix delegation and router advertisements on three of those VLANs. After that, Junos just refuses the config. There is no documented way to extend it. There is no warning in the product literature that “this feature stops working at 3.” There is no published technical justification, in fact, I can't find anything published about this limit at all.
The result is that I cannot deploy IPv6 cleanly across my entire network using Juniper’s intended/automated method. My choices are: • break my segmentation model to fit an undocumented limit, or • start doing manual RA gymnastics and scripting around Junos just to reach VLAN #4 and VLAN #5.
Neither of those is what we should be calling “enterprise-ready IPv6.” It's not even "home-ready IPv6". It's embarrassing.
One of the small branches where I installed an SRX-345 has over 40 vlans. We heavily segmented to protect the network from east-west movement, for compliance, and to prevent the spread of ransomware. This is exactly the kind of paper-cut that keeps corporate networks from rolling out IPv6 everywhere. It’s not that IPv6 is “hard.” It’s that Juniper quietly ship artificial restrictions and then make the fix “buy a bigger box that you otherwise don't need.” I for one am not buying it.
If this is a licensing/commercial segmentation decision (“branch” products get three VLANs of working IPv6 and if you need more you’re supposed to move up-market and spend tens of thousands more), then please say that, on the record, so operators can plan accordingly (buy from another vendor) and so architects can see what they’re actually buying.
If it’s not intentional product gating, then please remove the limit, and provide that to everyone who has bought an SRX-3xx. There is no technical reason an SRX-3xx should only be able to advertise delegated IPv6 prefixes on three VLANs. There are both hardware and software solutions that work as UTM firewalls for branch offices that don't have automatic limits. I am not beholden to Juniper, and I can/will buy other solutions if I have to.
That is not helping IPv6 adoption. I opened a jcare ticket on it years ago, and got crickets, so now we're going to see if sunlight is the best disinfectant. I'm not your biggest customer but I've purchased well over $700,000 worth of Juniper gear and jcare. I'm asking that Juniper publicly commit to fixing this, because I assure you I can buy something else.
Regards, Andrew Kirch AS401854 _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Z2ZX77BK...
-- ++ytti
Am 02.11.2025 um 09:36:04 Uhr schrieb Saku Ytti via NANOG:
I would have no reason to assume there is anything designed or planned here. It's just people don't use IPv6, and IPv6 things can be broken and nothing happens.
That's just plain BS. There are various networks with IPv6 nowadays (have a look a the Google and apnic statistic pages) and various IPv6-only nets already exist. If it breaks, people will notice it.
I blame myself, and the community. We were here when IPv6 happened, and we cocked it up. This pretend dual-stack environment, where IPv6 actually isn't business critical, wasn't supposed to happen. Time gap between IPv4 RFC and IPv6 RFC is smaller than the time gap between IPv6 RFC and today, we've had longer tenure of migration to IPv6 than we have IPv4 only.
Because the amount of networks and machines massively increased during that time.
There is no other way to frame this than as an abject failure. And trying to paint this in some other light, just removes any traction to actually solve this.
Is there any good alternative - or even a concept? I've never seen that and every time people come up with that, they suggest "IPv4 with a larger address space", but don't understand that such a thing cannot be implemented alongside with current IPv4, so no migration plan at all.
Actual solution will need some kind of voluntary or involuntary action by oligarchic big tech companies, so that they'd have a future date upon which they stop serving IPv4, which will create motivation for downstreams to adopt IPv6.
Some small sites already did that: https://konecipv4.cz/en/
Maybe someone could convince the FTC, FCC or DOJ that IPv4 is an antitrust issue they need to regulate. Which it absolutely is, it is an additional barrier of entry for many types of businesses favoring established large players over new entrants.
IIRC I've read that certain US government contracts require IPv6 compatibility. Device which don't support it cannot be used. -- Gruß Marco Send unsolicited bulk mail to 1762072564muell@cartoonies.org
participants (3)
-
Andrew Kirch -
Marco Moock -
Saku Ytti