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
I agree with Marco.
It's just people don't use IPv6, and IPv6 things can be broken and nothing happens.
That is BS. I would gamble 95+% of mobile traffic is ipv6 only. If anything the telecom's have had to invent new RFCs and workarounds to make sure clients can get to ipv4 only services. see 464XLAT as an example. see https://datatracker.ietf.org/doc/html/rfc6877 I'm on an old edgerouter lite3 at home at the moment and have no problem with my ipv6 prefix delegations. You assign an ID to each vlan for the RA and it uses that in the prefix. Example I get delegated prefix that contains ...."a8e3"... for an IoT vlan indexed as 3 and an "a8e1" on a vlan tagged as 1 This isn't rocket science. We should be IPv6 all the things. The only excuse is the IT management with the "if it isn't broken don't fix it" approach to technology. They can get left behind. ========== Notes and data below ========== Google:: As of 2025, it is estimated there are approximately 8.31 to 8.8 billion mobile phones in operation worldwide, including both smartphones and feature phones. As of late 2024/early 2025, several major trends indicate high mobile IPv6 usage: - High Operator Deployment Rates: Many major mobile network operators have aggressively adopted IPv6. In the US, for example, T-Mobile and AT&T show over 84% to 90% of their traffic is over IPv6. In India, Reliance Jio reports over 92% IPv6 deployment. - Mobile Driving Adoption: The mobile and residential segments are the primary drivers of global IPv6 adoption, accounting for a large portion of the overall traffic statistics, which globally sit around 45-49% of all internet traffic. - Prevalence of IPv6-only Cores: Many mobile networks are transitioning their internal infrastructure to be IPv6-only, using mechanisms like 464XLAT to support legacy IPv4-only applications and content. This simplifies network operations and reduces costs. - Client vs. Server Side Discrepancy: While most mobile devices and networks are highly capable of using IPv6, a major barrier is that only about 30% of websites and servers are IPv6-enabled. This means that even with IPv6-ready devices, connections often still fall back to IPv4 for a substantial portion of content. On Sun, Nov 2, 2025 at 4:30 AM Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
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 _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MW2EZMUN...
There is a big misunderstanding about IPv6 on mobile (and the majority of residential broadband): it is NOT an IPv6. The primary difference between IPv4 and IPv6 is the first hop: IPv6 has enormous flexibility and complexity here. But MBB/FBB completely disabled all IPv6 features on the first hop; it is possible because L2 P2P connection is emulated here (PPP or GTP tunnel). Such castrated IPv6 works perfectly fine (for residential/mobile) because it is even simpler than IPv4. The big address space of IPv6 (64 bits) is a value here. There is no possibility of canceling the "subnet" concept for business. IPv6 subnet complexity is too much burden for businesses. Hence, IPv4 will stay for business forever. IMHO: the world would finally accept: "reduced IPv6 for subscribers, IPv4 for businesses". IMHO: the full IPv6 (it was called "Next Generation" 3 decades ago) has no future. Eduard -----Original Message----- From: Javier J via NANOG <nanog@lists.nanog.org> Sent: Monday, November 3, 2025 18:00 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de>; Javier J <javier@advancedmachines.us> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) I agree with Marco.
It's just people don't use IPv6, and IPv6 things can be broken and nothing happens.
That is BS. I would gamble 95+% of mobile traffic is ipv6 only. If anything the telecom's have had to invent new RFCs and workarounds to make sure clients can get to ipv4 only services. see 464XLAT as an example. see https://datatracker.ietf.org/doc/html/rfc6877 I'm on an old edgerouter lite3 at home at the moment and have no problem with my ipv6 prefix delegations. You assign an ID to each vlan for the RA and it uses that in the prefix. Example I get delegated prefix that contains ...."a8e3"... for an IoT vlan indexed as 3 and an "a8e1" on a vlan tagged as 1 This isn't rocket science. We should be IPv6 all the things. The only excuse is the IT management with the "if it isn't broken don't fix it" approach to technology. They can get left behind. ========== Notes and data below ========== Google:: As of 2025, it is estimated there are approximately 8.31 to 8.8 billion mobile phones in operation worldwide, including both smartphones and feature phones. As of late 2024/early 2025, several major trends indicate high mobile IPv6 usage: - High Operator Deployment Rates: Many major mobile network operators have aggressively adopted IPv6. In the US, for example, T-Mobile and AT&T show over 84% to 90% of their traffic is over IPv6. In India, Reliance Jio reports over 92% IPv6 deployment. - Mobile Driving Adoption: The mobile and residential segments are the primary drivers of global IPv6 adoption, accounting for a large portion of the overall traffic statistics, which globally sit around 45-49% of all internet traffic. - Prevalence of IPv6-only Cores: Many mobile networks are transitioning their internal infrastructure to be IPv6-only, using mechanisms like 464XLAT to support legacy IPv4-only applications and content. This simplifies network operations and reduces costs. - Client vs. Server Side Discrepancy: While most mobile devices and networks are highly capable of using IPv6, a major barrier is that only about 30% of websites and servers are IPv6-enabled. This means that even with IPv6-ready devices, connections often still fall back to IPv4 for a substantial portion of content. On Sun, Nov 2, 2025 at 4:30 AM Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
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 _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MW 2EZMUNKCPPVESI2KILS7OTJKXKDGGQ/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/25SARHQY...
On Wed, 5 Nov 2025 at 08:27, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
There is no possibility of canceling the "subnet" concept for business. IPv6 subnet complexity is too much burden for businesses. Hence, IPv4 will stay for business forever.
You may very well be right, but it doesn't have to be that. And if it is, we are to blame, we were here when it happened. Dual stack is expensive, complicated and reduces availability and quality. End users ultimately pay a premium for lower quality because of what we did, not to mention the companies which will never exist to compete with oligarchs, because procuring sufficient amounts of IPv4 addresses was too large a barrier to compete already in an uneven playing field. We should have been single stack for more than a decade by now, with IPv4 being IPX or AppleTalk, relegated to some odd corners. And yes, we can pull various metrics to show 'no, things are actually progressing swimmingly', but that just stops us from looking into the mirror and accepting we cocked this up badly and need to do something meaningful and real.
IPv6 is not possible to fix - does not matter who is guilty. It is bad design because it was a "consensus" (read "compromise") between different politicians pushing IPv4, IPX, Apple Talk, Apollo Domain, DEC net, banyan VINES, etc. IPv6 has satisfied all requests - it is really flexible architecture. IPv6 inside P2P tunnel (with all features disabled) - is actually not IPv6. The statistics is misleading, almost all installations are residential/mobile where all first-hop functionality is cancelled. Actual IPv6 progress (where 1st hop complexity is exercised) is below 1%. IMHO: It could not surpass 1% long-term. Eduard -----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: Wednesday, November 5, 2025 11:26 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de>; Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On Wed, 5 Nov 2025 at 08:27, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
There is no possibility of canceling the "subnet" concept for business. IPv6 subnet complexity is too much burden for businesses. Hence, IPv4 will stay for business forever.
You may very well be right, but it doesn't have to be that. And if it is, we are to blame, we were here when it happened. Dual stack is expensive, complicated and reduces availability and quality. End users ultimately pay a premium for lower quality because of what we did, not to mention the companies which will never exist to compete with oligarchs, because procuring sufficient amounts of IPv4 addresses was too large a barrier to compete already in an uneven playing field. We should have been single stack for more than a decade by now, with IPv4 being IPX or AppleTalk, relegated to some odd corners. And yes, we can pull various metrics to show 'no, things are actually progressing swimmingly', but that just stops us from looking into the mirror and accepting we cocked this up badly and need to do something meaningful and real.
IPv6 is just IPv4 with longer addresses, no IP checksum field, and a few optional features. Can you be more specific in your complaints? Which one of these is your complaint about? On 5 November 2025 10:38:46 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
IPv6 is not possible to fix - does not matter who is guilty. It is bad design because it was a "consensus" (read "compromise") between different politicians pushing IPv4, IPX, Apple Talk, Apollo Domain, DEC net, banyan VINES, etc. IPv6 has satisfied all requests - it is really flexible architecture.
IPv6 inside P2P tunnel (with all features disabled) - is actually not IPv6. The statistics is misleading, almost all installations are residential/mobile where all first-hop functionality is cancelled. Actual IPv6 progress (where 1st hop complexity is exercised) is below 1%. IMHO: It could not surpass 1% long-term. Eduard -----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: Wednesday, November 5, 2025 11:26 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de>; Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
On Wed, 5 Nov 2025 at 08:27, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
There is no possibility of canceling the "subnet" concept for business. IPv6 subnet complexity is too much burden for businesses. Hence, IPv4 will stay for business forever.
You may very well be right, but it doesn't have to be that. And if it is, we are to blame, we were here when it happened.
Dual stack is expensive, complicated and reduces availability and quality. End users ultimately pay a premium for lower quality because of what we did, not to mention the companies which will never exist to compete with oligarchs, because procuring sufficient amounts of IPv4 addresses was too large a barrier to compete already in an uneven playing field.
We should have been single stack for more than a decade by now, with IPv4 being IPX or AppleTalk, relegated to some odd corners. And yes, we can pull various metrics to show 'no, things are actually progressing swimmingly', but that just stops us from looking into the mirror and accepting we cocked this up badly and need to do something meaningful and real. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VMI27Y4J...
Nope. It is an extremally complex bunch of protocols on the 1st hope (between the computer and the router). If it was be like you said - IPv4 would be down already. Eduard -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 15:02 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: RE: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) IPv6 is just IPv4 with longer addresses, no IP checksum field, and a few optional features. Can you be more specific in your complaints? Which one of these is your complaint about? On 5 November 2025 10:38:46 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
IPv6 is not possible to fix - does not matter who is guilty. It is bad design because it was a "consensus" (read "compromise") between different politicians pushing IPv4, IPX, Apple Talk, Apollo Domain, DEC net, banyan VINES, etc. IPv6 has satisfied all requests - it is really flexible architecture.
IPv6 inside P2P tunnel (with all features disabled) - is actually not IPv6. The statistics is misleading, almost all installations are residential/mobile where all first-hop functionality is cancelled. Actual IPv6 progress (where 1st hop complexity is exercised) is below 1%. IMHO: It could not surpass 1% long-term. Eduard -----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: Wednesday, November 5, 2025 11:26 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de>; Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
On Wed, 5 Nov 2025 at 08:27, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
There is no possibility of canceling the "subnet" concept for business. IPv6 subnet complexity is too much burden for businesses. Hence, IPv4 will stay for business forever.
You may very well be right, but it doesn't have to be that. And if it is, we are to blame, we were here when it happened.
Dual stack is expensive, complicated and reduces availability and quality. End users ultimately pay a premium for lower quality because of what we did, not to mention the companies which will never exist to compete with oligarchs, because procuring sufficient amounts of IPv4 addresses was too large a barrier to compete already in an uneven playing field.
We should have been single stack for more than a decade by now, with IPv4 being IPX or AppleTalk, relegated to some odd corners. And yes, we can pull various metrics to show 'no, things are actually progressing swimmingly', but that just stops us from looking into the mirror and accepting we cocked this up badly and need to do something meaningful and real. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VMI27Y4J...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3BQNH3AU...
On 06.11.2025 12:13 Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
Nope. It is an extremally complex bunch of protocols on the 1st hope (between the computer and the router).
If it was be like you said - IPv4 would be down already.
It already is in certain networks. Various ISPs do DS-Lite - no IPv4 to the customer - IPv6 with tunneled IPv4 if needed. Cellular ISPs only give IPv6 with NAT64 or CLAT. -- kind regards Marco Send spam to abfall1762427614@stinkedores.dorfdsl.de
IPv6 has made good progress for Telco (including DS-Lite, MAP-T, etc). Where Telco has offloaded the 1st hop problem to the subscriber. IPv6 has made miserable progress for enterprises, SMB, SOHO. Eduard -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 17:54 To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 12:13 Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
Nope. It is an extremally complex bunch of protocols on the 1st hope (between the computer and the router).
If it was be like you said - IPv4 would be down already.
It already is in certain networks. Various ISPs do DS-Lite - no IPv4 to the customer - IPv6 with tunneled IPv4 if needed. Cellular ISPs only give IPv6 with NAT64 or CLAT. -- kind regards Marco Send spam to abfall1762427614@stinkedores.dorfdsl.de
On 07.11.2025 06:34 Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
IPv6 has made miserable progress for enterprises, SMB, SOHO.
Because there are various people who are simply unwilling. For home users, the provider enables it and it mostly works if the CPE supports it, which applies for most CPE. In enterprises, many people are part of the decisions (change management etc.), time is limited and there are always people who are against. That slows down the process. -- kind regards Marco Send spam to abfall1762493694@stinkedores.dorfdsl.de
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 8, 2025, at 7:51 AM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: On 07.11.2025 06:34 Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote: IPv6 has made miserable progress for enterprises, SMB, SOHO. Because there are various people who are simply unwilling. For home users, the provider enables it and it mostly works if the CPE supports it, which applies for most CPE. In enterprises, many people are part of the decisions (change management etc.), time is limited and there are always people who are against. That slows down the process. -- kind regards Marco Send spam to abfall1762493694@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/NQYGSMMA...
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 8, 2025, at 7:51 AM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: On 07.11.2025 06:34 Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote: IPv6 has made miserable progress for enterprises, SMB, SOHO. Because there are various people who are simply unwilling. For home users, the provider enables it and it mostly works if the CPE supports it, which applies for most CPE. In enterprises, many people are part of the decisions (change management etc.), time is limited and there are always people who are against. That slows down the process. -- kind regards Marco Send spam to abfall1762493694@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 7:34 AM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: IPv6 has made good progress for Telco (including DS-Lite, MAP-T, etc). Where Telco has offloaded the 1st hop problem to the subscriber. IPv6 has made miserable progress for enterprises, SMB, SOHO. Eduard -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 17:54 To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 12:13 Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Nope. It is an extremally complex bunch of protocols on the 1st hope (between the computer and the router). If it was be like you said - IPv4 would be down already. It already is in certain networks. Various ISPs do DS-Lite - no IPv4 to the customer - IPv6 with tunneled IPv4 if needed. Cellular ISPs only give IPv6 with NAT64 or CLAT. -- kind regards Marco Send spam to abfall1762427614@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 6, 2025, at 3:53 PM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: On 06.11.2025 12:13 Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Nope. It is an extremally complex bunch of protocols on the 1st hope (between the computer and the router). If it was be like you said - IPv4 would be down already. It already is in certain networks. Various ISPs do DS-Lite - no IPv4 to the customer - IPv6 with tunneled IPv4 if needed. Cellular ISPs only give IPv6 with NAT64 or CLAT. -- kind regards Marco Send spam to abfall1762427614@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MG7OT54U...
Vasilenko Eduard via NANOG wrote on 06/11/2025 12:13:
Nope. It is an extremally complex bunch of protocols on the1st hope (between the computer and the router).
it's pretty simple really. Neighbor discovery is defined in RFC4861. There's also formal updates in RFCs 8319, 8425, 9131, 5942, 6980, 7048, 7527, 7559, 8028, 9685, and 9762. Various other notes areincluded in 7217, 8978, 8981, and 4941. After that rfc8415 defines DHCPv6, with extensions and various updates in 8156, 8168, 8639, 8948, 8987, 9527, 9663, 9686 and 9818. Obviously everyone needs yang so dhcpv6/yang is in 9243. Then there's secure neighbour discovery. And ND proxy and LPWAN. Lots of RFCs there. 4943, 5269, 5909, 6273, 6494, 6495, 6496, 6583, 6775, 6980, 7219, 7342, 8161, 8302, 8425, 8505, 8928, and 9131 for starters. And plenty of other references inside other RFCs. Oh yeah, and 15 errata for rfc4861 (there was another one confirmed earlier today and placed in HDU status): https://www.rfc-editor.org/errata_search.php?rfc=4861 Hopefully this clearly shows to the OP that IPv6 neighbor discovery isn't remotely complicated. Nick
I suppose that the number of people who understand it well enough is below 2k worldwide. IPv6 1st hop is very complex. Ed/ -----Original Message----- From: Nick Hilliard via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 17:58 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Nick Hilliard <nick@foobar.org> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) Vasilenko Eduard via NANOG wrote on 06/11/2025 12:13:
Nope. It is an extremally complex bunch of protocols on the1st hope (between the computer and the router).
it's pretty simple really. Neighbor discovery is defined in RFC4861. There's also formal updates in RFCs 8319, 8425, 9131, 5942, 6980, 7048, 7527, 7559, 8028, 9685, and 9762. Various other notes areincluded in 7217, 8978, 8981, and 4941. After that rfc8415 defines DHCPv6, with extensions and various updates in 8156, 8168, 8639, 8948, 8987, 9527, 9663, 9686 and 9818. Obviously everyone needs yang so dhcpv6/yang is in 9243. Then there's secure neighbour discovery. And ND proxy and LPWAN. Lots of RFCs there. 4943, 5269, 5909, 6273, 6494, 6495, 6496, 6583, 6775, 6980, 7219, 7342, 8161, 8302, 8425, 8505, 8928, and 9131 for starters. And plenty of other references inside other RFCs. Oh yeah, and 15 errata for rfc4861 (there was another one confirmed earlier today and placed in HDU status): https://www.rfc-editor.org/errata_search.php?rfc=4861 Hopefully this clearly shows to the OP that IPv6 neighbor discovery isn't remotely complicated. Nick _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/NEEBC5FV...
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 7:37 AM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: I suppose that the number of people who understand it well enough is below 2k worldwide. IPv6 1st hop is very complex. Ed/ -----Original Message----- From: Nick Hilliard via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 17:58 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Nick Hilliard <nick@foobar.org> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) Vasilenko Eduard via NANOG wrote on 06/11/2025 12:13: Nope. It is an extremally complex bunch of protocols on the1st hope (between the computer and the router). it's pretty simple really. Neighbor discovery is defined in RFC4861. There's also formal updates in RFCs 8319, 8425, 9131, 5942, 6980, 7048, 7527, 7559, 8028, 9685, and 9762. Various other notes areincluded in 7217, 8978, 8981, and 4941. After that rfc8415 defines DHCPv6, with extensions and various updates in 8156, 8168, 8639, 8948, 8987, 9527, 9663, 9686 and 9818. Obviously everyone needs yang so dhcpv6/yang is in 9243. Then there's secure neighbour discovery. And ND proxy and LPWAN. Lots of RFCs there. 4943, 5269, 5909, 6273, 6494, 6495, 6496, 6583, 6775, 6980, 7219, 7342, 8161, 8302, 8425, 8505, 8928, and 9131 for starters. And plenty of other references inside other RFCs. Oh yeah, and 15 errata for rfc4861 (there was another one confirmed earlier today and placed in HDU status): https://urldefense.com/v3/__https://www.rfc-editor.org/errata_search.php?rfc... [rfc-editor[.]org] Hopefully this clearly shows to the OP that IPv6 neighbor discovery isn't remotely complicated. Nick _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
Why does anyone even use an Auto responder in 2025? On Mon, Nov 10, 2025, 9:06 AM Samaneh Tajalizadehkhoob via NANOG < nanog@lists.nanog.org> wrote:
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh
On Nov 7, 2025, at 7:37 AM, Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote:
I suppose that the number of people who understand it well enough is below 2k worldwide. IPv6 1st hop is very complex. Ed/ -----Original Message----- From: Nick Hilliard via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 17:58 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Nick Hilliard <nick@foobar.org> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
Vasilenko Eduard via NANOG wrote on 06/11/2025 12:13: Nope. It is an extremally complex bunch of protocols on the1st hope (between the computer and the router).
it's pretty simple really. Neighbor discovery is defined in RFC4861.
There's also formal updates in RFCs 8319, 8425, 9131, 5942, 6980, 7048, 7527, 7559, 8028, 9685, and 9762. Various other notes areincluded in 7217, 8978, 8981, and 4941.
After that rfc8415 defines DHCPv6, with extensions and various updates in 8156, 8168, 8639, 8948, 8987, 9527, 9663, 9686 and 9818.
Obviously everyone needs yang so dhcpv6/yang is in 9243.
Then there's secure neighbour discovery. And ND proxy and LPWAN. Lots of RFCs there. 4943, 5269, 5909, 6273, 6494, 6495, 6496, 6583, 6775, 6980, 7219, 7342, 8161, 8302, 8425, 8505, 8928, and 9131 for starters.
And plenty of other references inside other RFCs.
Oh yeah, and 15 errata for rfc4861 (there was another one confirmed earlier today and placed in HDU status):
https://urldefense.com/v3/__https://www.rfc-editor.org/errata_search.php?rfc... [rfc-editor[.]org]
Hopefully this clearly shows to the OP that IPv6 neighbor discovery isn't remotely complicated.
Nick _______________________________________________ NANOG mailing list
https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list
https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3SEY6ZZL...
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 6, 2025, at 3:58 PM, Nick Hilliard via NANOG <nanog@lists.nanog.org> wrote: Vasilenko Eduard via NANOG wrote on 06/11/2025 12:13: Nope. It is an extremally complex bunch of protocols on the1st hope (between the computer and the router). it's pretty simple really. Neighbor discovery is defined in RFC4861. There's also formal updates in RFCs 8319, 8425, 9131, 5942, 6980, 7048, 7527, 7559, 8028, 9685, and 9762. Various other notes areincluded in 7217, 8978, 8981, and 4941. After that rfc8415 defines DHCPv6, with extensions and various updates in 8156, 8168, 8639, 8948, 8987, 9527, 9663, 9686 and 9818. Obviously everyone needs yang so dhcpv6/yang is in 9243. Then there's secure neighbour discovery. And ND proxy and LPWAN. Lots of RFCs there. 4943, 5269, 5909, 6273, 6494, 6495, 6496, 6583, 6775, 6980, 7219, 7342, 8161, 8302, 8425, 8505, 8928, and 9131 for starters. And plenty of other references inside other RFCs. Oh yeah, and 15 errata for rfc4861 (there was another one confirmed earlier today and placed in HDU status): https://urldefense.com/v3/__https://www.rfc-editor.org/errata_search.php?rfc... [rfc-editor[.]org] Hopefully this clearly shows to the OP that IPv6 neighbor discovery isn't remotely complicated. Nick _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
On Wednesday, 5 November, 2025 06:26, "Vasilenko Eduard via NANOG" <nanog@lists.nanog.org> said:
There is no possibility of canceling the "subnet" concept for business. IPv6 subnet complexity is too much burden for businesses.
I'm genuinely curious as to what you mean by this, Eduard. For me, one of the benefits of v6 at the design stage is that subnetting is substantially *easier*. You don't have to worry about trying to carve up your address space to get the right number of hosts in the right places, or trade off bits of host-mask against bits of net-mask. All the subnets (and I mean LAN-type subnets here, obviously, not linknets) are /64s, there will *always* be enough host addresses. Stop thinking about host counts - it's irrelevant to the design. Simplification step 1. Now your design can purely think about how many subnets do I need, where do I need them, what do I need them for. Even a basic home-level allocation of a /56 lets you either have a flat '00' - 'ff' subnet space that you can assign a function to each value of with loads to spare, or split out into a 'location' nibble and a 'function' nibble. A business with a /48 can encode all kinds of useful information into the 16 bits of 'subnet' available - business units, security zones, multiple levels of geographical hierarchy. Or if you don't want to be that complex, you can still just work upwards from 2001:db8:1234:0::/64, 2001:db8:1234:1::/64, in the same way you did for 192.168.0.0/24, 192.168.1.0/24. There are challenges to adopting v6, sure, but I'm not clear how 'subnetting' is one of them. Cheers, Tim.
Hi Tim, Multi-prefix, SP address delegation through the site, absence of NAT. Many things. Try to organize the primary and redundant connection to the SP (that is needed for every business). The fact that every subnet is /64 is convenient. Just if has a payment 16/750=2% of the overall Internet capacity (750B is the average packet size). The decision to violate OSI model and put MAC address inside IP address was very questionable. Eduard -----Original Message----- From: tim--- via NANOG <nanog@lists.nanog.org> Sent: Wednesday, November 5, 2025 12:59 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: tim@pelican.org Subject: RE: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On Wednesday, 5 November, 2025 06:26, "Vasilenko Eduard via NANOG" <nanog@lists.nanog.org> said:
There is no possibility of canceling the "subnet" concept for business. IPv6 subnet complexity is too much burden for businesses.
I'm genuinely curious as to what you mean by this, Eduard. For me, one of the benefits of v6 at the design stage is that subnetting is substantially *easier*. You don't have to worry about trying to carve up your address space to get the right number of hosts in the right places, or trade off bits of host-mask against bits of net-mask. All the subnets (and I mean LAN-type subnets here, obviously, not linknets) are /64s, there will *always* be enough host addresses. Stop thinking about host counts - it's irrelevant to the design. Simplification step 1. Now your design can purely think about how many subnets do I need, where do I need them, what do I need them for. Even a basic home-level allocation of a /56 lets you either have a flat '00' - 'ff' subnet space that you can assign a function to each value of with loads to spare, or split out into a 'location' nibble and a 'function' nibble. A business with a /48 can encode all kinds of useful information into the 16 bits of 'subnet' available - business units, security zones, multiple levels of geographical hierarchy. Or if you don't want to be that complex, you can still just work upwards from 2001:db8:1234:0::/64, 2001:db8:1234:1::/64, in the same way you did for 192.168.0.0/24, 192.168.1.0/24. There are challenges to adopting v6, sure, but I'm not clear how 'subnetting' is one of them. Cheers, Tim. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BK74QBTI...
Am 05.11.2025 um 11:00:13 Uhr schrieb Vasilenko Eduard via NANOG:
Multi-prefix, SP address delegation through the site, absence of NAT.
If you want NAT really hard, you can use it with IPv6 too. fd00::/8 exist.
Many things. Try to organize the primary and redundant connection to the SP (that is needed for every business).
A connection with 2 prefixes (or even 2 IPv4 addresses) via 2 ISPs is never redundant, unless you set it up this way with both ISPs cooperating. If you really want redundancy, you have to get your own ASN and route it via 2 independent ISPs. Or let 2 ISPs route your network ranges. In all other cases with NAT and 2 IPv4 addresses, connections will be lost when one of the connections fail, as the remote system won't accept the packages from a different address unless a new connection is being established.
The fact that every subnet is /64 is convenient. Just if has a payment 16/750=2% of the overall Internet capacity (750B is the average packet size). The decision to violate OSI model and put MAC address inside IP address was very questionable.
Are you aware that EUI64 is only one way to generate the addresses and that the 64 bits can be randomly filled or be static? -- Gruß Marco Send unsolicited bulk mail to 1762336813muell@cartoonies.org
Are you aware that EUI64 is only one way to generate the addresses and that the 64 bits can be randomly filled or be static? Do you mean that random garbage (for privacy) did return 2% resources to the Internet? These 16 bytes (8 for source and 8 for destination) are still used not for IP addressing. Does it matter for what it is used, if it is not IP addressing? IPv6 is 64+bit architecture (a few bits are used inside subnet)
If you want NAT really hard, you can use it with IPv6 too. fd00::/8 exist. Then it is better to use NTP. But IETF makes everything possible to block it too. Anyway, if NAT (in any form) is blocked then there is no practical solution for ISP redundancy: https://datatracker.ietf.org/doc/html/draft-fbnvv-v6ops-site-multihoming-03 Read it to understand what the mess is going there - it is really complicated. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Wednesday, November 5, 2025 14:17 To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
Am 05.11.2025 um 11:00:13 Uhr schrieb Vasilenko Eduard via NANOG:
Multi-prefix, SP address delegation through the site, absence of NAT.
If you want NAT really hard, you can use it with IPv6 too. fd00::/8 exist.
Many things. Try to organize the primary and redundant connection to the SP (that is needed for every business).
A connection with 2 prefixes (or even 2 IPv4 addresses) via 2 ISPs is never redundant, unless you set it up this way with both ISPs cooperating. If you really want redundancy, you have to get your own ASN and route it via 2 independent ISPs. Or let 2 ISPs route your network ranges. In all other cases with NAT and 2 IPv4 addresses, connections will be lost when one of the connections fail, as the remote system won't accept the packages from a different address unless a new connection is being established.
The fact that every subnet is /64 is convenient. Just if has a payment 16/750=2% of the overall Internet capacity (750B is the average packet size). The decision to violate OSI model and put MAC address inside IP address was very questionable.
Are you aware that EUI64 is only one way to generate the addresses and that the 64 bits can be randomly filled or be static? -- Gruß Marco Send unsolicited bulk mail to 1762336813muell@cartoonies.org
Am 05.11.2025 um 13:03:46 Uhr schrieb Vasilenko Eduard:
Are you aware that EUI64 is only one way to generate the addresses and that the 64 bits can be randomly filled or be static? Do you mean that random garbage (for privacy) did return 2% resources to the Internet? These 16 bytes (8 for source and 8 for destination) are still used not for IP addressing. Does it matter for what it is used, if it is not IP addressing? IPv6 is 64+bit architecture (a few bits are used inside subnet)
I do not understand what you are talking about. For IPv6, the subnets that are connected to links should always be /64. Various ways exist to fill the other 64 bit.
If you want NAT really hard, you can use it with IPv6 too. fd00::/8 exist. Then it is better to use NTP. But IETF makes everything possible to block it too. Anyway, if NAT (in any form) is blocked then there is no practical solution for ISP redundancy:
There is and I pointed that out. The NAT "redundancy" "solutions" do not offer redundancy. They are a cripple solution. -- Gruß Marco Send unsolicited bulk mail to 1762344226muell@cartoonies.org
I do not understand what you are talking about. IPv6 is mostly using SLAAC. SLAAC is 64 bit addressing architecture. (by the way, 64 bit is enough for addressing of everything) Even if somebody use DHCP, he typically makes subnet "SLAAC compatible", it means: use 64 bits for addressing. Eduard -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Wednesday, November 5, 2025 17:35 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
Am 05.11.2025 um 13:03:46 Uhr schrieb Vasilenko Eduard:
Are you aware that EUI64 is only one way to generate the addresses and that the 64 bits can be randomly filled or be static? Do you mean that random garbage (for privacy) did return 2% resources to the Internet? These 16 bytes (8 for source and 8 for destination) are still used not for IP addressing. Does it matter for what it is used, if it is not IP addressing? IPv6 is 64+bit architecture (a few bits are used inside subnet)
I do not understand what you are talking about. For IPv6, the subnets that are connected to links should always be /64. Various ways exist to fill the other 64 bit.
If you want NAT really hard, you can use it with IPv6 too. fd00::/8 exist. Then it is better to use NTP. But IETF makes everything possible to block it too. Anyway, if NAT (in any form) is blocked then there is no practical solution for ISP redundancy:
There is and I pointed that out. The NAT "redundancy" "solutions" do not offer redundancy. They are a cripple solution. -- Gruß Marco Send unsolicited bulk mail to 1762344226muell@cartoonies.org
On 06.11.2025 06:27 Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
I do not understand what you are talking about. IPv6 is mostly using SLAAC. SLAAC is 64 bit addressing architecture. (by the way, 64 bit is enough for addressing of everything) Even if somebody use DHCP, he typically makes subnet "SLAAC compatible", it means: use 64 bits for addressing.
Where is the issue there? Unless the A-bit is set for the prefix in the RA, no machine will do autoconfiguration using SLAAC. -- kind regards Marco Send spam to abfall1762406841@stinkedores.dorfdsl.de
The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. Eduard -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 10:07 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 06:27 Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
I do not understand what you are talking about. IPv6 is mostly using SLAAC. SLAAC is 64 bit addressing architecture. (by the way, 64 bit is enough for addressing of everything) Even if somebody use DHCP, he typically makes subnet "SLAAC compatible", it means: use 64 bits for addressing.
Where is the issue there? Unless the A-bit is set for the prefix in the RA, no machine will do autoconfiguration using SLAAC. -- kind regards Marco Send spam to abfall1762406841@stinkedores.dorfdsl.de
On 06.11.2025 07:12 Vasilenko Eduard wrote:
The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity.
No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over.
Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:12 Vasilenko Eduard wrote:
The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity.
No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GQ5AQ75W...
On 06.11.2025 12:11 Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
Tell any financial department that 2% does not matter and see the reaction.
Please tell that the various companies that route IPv6 traffic. All the ISP that don't have enough IPv4 want to have more traffic via IPv6 to save resources in their NAT gateways. This year was a talk at the RIPE conference about that topic. TLDR: IPv6 is cheaper in such situations. The larger header size is simply irrelevant. -- kind regards Marco Send spam to abfall1762427476@stinkedores.dorfdsl.de
On Thu, 6 Nov 2025 at 16:52, Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
Please tell that the various companies that route IPv6 traffic. All the ISP that don't have enough IPv4 want to have more traffic via IPv6 to save resources in their NAT gateways.
The entropy of DADDR/SADDR in IPv6 is very low compared to IPv4. Yes there is some traffic, but it looks artificially good because some large content providers happen to have it. For most of the world and people IPv6 continues to be completely immaterial. Very few of my customers care about IPv6 and it is easy to notice when issues are IPv6 only, it takes a long time for them to escalate. Vendors stil ship IPv4 first, or maybe even IPv4 only on some features. And indeed as someone else mentioned, IPv6 is just more addresses. Any other argument is just crusade for good or bad cause, but ultimately crusade which will hurt adoption. Yes IPv6 NAT and NAPT were always going to be a thing and IPv6 ULA is probably still the best alternative for enterprise addressing, unless they happen to have their own globally routable address. We shouldn't try to promote any other changes with IPv6, except more addresses and keep other crusades for another time. Currently we are just helping the incumbents to maintain their oligarchy by insisting nothing is wrong, trajectory is good and it was always intended to be dual-stack for decades. -- ++ytti
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 6, 2025, at 4:47 PM, Saku Ytti via NANOG <nanog@lists.nanog.org> wrote: On Thu, 6 Nov 2025 at 16:52, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: Please tell that the various companies that route IPv6 traffic. All the ISP that don't have enough IPv4 want to have more traffic via IPv6 to save resources in their NAT gateways. The entropy of DADDR/SADDR in IPv6 is very low compared to IPv4. Yes there is some traffic, but it looks artificially good because some large content providers happen to have it. For most of the world and people IPv6 continues to be completely immaterial. Very few of my customers care about IPv6 and it is easy to notice when issues are IPv6 only, it takes a long time for them to escalate. Vendors stil ship IPv4 first, or maybe even IPv4 only on some features. And indeed as someone else mentioned, IPv6 is just more addresses. Any other argument is just crusade for good or bad cause, but ultimately crusade which will hurt adoption. Yes IPv6 NAT and NAPT were always going to be a thing and IPv6 ULA is probably still the best alternative for enterprise addressing, unless they happen to have their own globally routable address. We shouldn't try to promote any other changes with IPv6, except more addresses and keep other crusades for another time. Currently we are just helping the incumbents to maintain their oligarchy by insisting nothing is wrong, trajectory is good and it was always intended to be dual-stack for decades. -- ++ytti _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
Hi Marco, In general, you are right about NAT, but it is not an argument against my message. 1. if you eliminate NAT44, you need to install NAT64, the last one is 3x more expensive (per user/flow). But IPv6 for Telco would be 90+%, hence, NAT64 would be cheaper than NAT44 before. 2. NAT is not an important factor for business - it coincides with FW. Hence, "for free". I was saying that IPv6 would not be accepted by businesses. 3. My message was not that "IPv4 is enough". The shortage of IPv4 addresses is real. My message was that IPv6 design is so bad (on the subnet level) that businesses would stay on IPv4. Eduard -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 17:52 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 12:11 Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
Tell any financial department that 2% does not matter and see the reaction.
Please tell that the various companies that route IPv6 traffic. All the ISP that don't have enough IPv4 want to have more traffic via IPv6 to save resources in their NAT gateways. This year was a talk at the RIPE conference about that topic. TLDR: IPv6 is cheaper in such situations. The larger header size is simply irrelevant. -- kind regards Marco Send spam to abfall1762427476@stinkedores.dorfdsl.de
On 07.11.2025 06:32 Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
3. My message was not that "IPv4 is enough". The shortage of IPv4 addresses is real. My message was that IPv6 design is so bad (on the subnet level) that businesses would stay on IPv4.
Businesses stay on that because they don't want change. This applies to operating system versions and protocols. Remember when most businesses transferred HTTP traffic without TLS? It was Google that made that mandatory, so they implemented it. Same applies for SPF and DKIM. It existed more than 10 years and when Google and other big player made it mandatory, the businesses hurried up and implemented it. If Google ever decides to make IPv6 a criteria for page rank, businesses will implement that very fast. -- kind regards Marco Send spam to abfall1762493530@stinkedores.dorfdsl.de
Or, in some cases, to comply with the federal mandate, just slap cloudflare/LB service of choice/etc in front of whatever on the outside and call it a day..... I remember a CEO in 2016 stating in an interview that IPv6 was a priority for them - and it was. All external services hosted for gov customers are IPv6 accessible. Internal IPv6 years later for them? Hah. Nope. -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Saturday, November 8, 2025 1:49 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 07.11.2025 06:32 Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
3. My message was not that "IPv4 is enough". The shortage of IPv4 addresses is real. My message was that IPv6 design is so bad (on the subnet level) that businesses would stay on IPv4.
Businesses stay on that because they don't want change. This applies to operating system versions and protocols. Remember when most businesses transferred HTTP traffic without TLS? It was Google that made that mandatory, so they implemented it. Same applies for SPF and DKIM. It existed more than 10 years and when Google and other big player made it mandatory, the businesses hurried up and implemented it. If Google ever decides to make IPv6 a criteria for page rank, businesses will implement that very fast. -- kind regards Marco Send spam to abfall1762493530@stinkedores.dorfdsl.de
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 8, 2025, at 7:55 AM, Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote: Or, in some cases, to comply with the federal mandate, just slap cloudflare/LB service of choice/etc in front of whatever on the outside and call it a day..... I remember a CEO in 2016 stating in an interview that IPv6 was a priority for them - and it was. All external services hosted for gov customers are IPv6 accessible. Internal IPv6 years later for them? Hah. Nope. -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Saturday, November 8, 2025 1:49 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 07.11.2025 06:32 Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote: 3. My message was not that "IPv4 is enough". The shortage of IPv4 addresses is real. My message was that IPv6 design is so bad (on the subnet level) that businesses would stay on IPv4. Businesses stay on that because they don't want change. This applies to operating system versions and protocols. Remember when most businesses transferred HTTP traffic without TLS? It was Google that made that mandatory, so they implemented it. Same applies for SPF and DKIM. It existed more than 10 years and when Google and other big player made it mandatory, the businesses hurried up and implemented it. If Google ever decides to make IPv6 a criteria for page rank, businesses will implement that very fast. -- kind regards Marco Send spam to abfall1762493530@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 8, 2025, at 7:55 AM, Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote: Or, in some cases, to comply with the federal mandate, just slap cloudflare/LB service of choice/etc in front of whatever on the outside and call it a day..... I remember a CEO in 2016 stating in an interview that IPv6 was a priority for them - and it was. All external services hosted for gov customers are IPv6 accessible. Internal IPv6 years later for them? Hah. Nope. -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Saturday, November 8, 2025 1:49 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 07.11.2025 06:32 Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote: 3. My message was not that "IPv4 is enough". The shortage of IPv4 addresses is real. My message was that IPv6 design is so bad (on the subnet level) that businesses would stay on IPv4. Businesses stay on that because they don't want change. This applies to operating system versions and protocols. Remember when most businesses transferred HTTP traffic without TLS? It was Google that made that mandatory, so they implemented it. Same applies for SPF and DKIM. It existed more than 10 years and when Google and other big player made it mandatory, the businesses hurried up and implemented it. If Google ever decides to make IPv6 a criteria for page rank, businesses will implement that very fast. -- kind regards Marco Send spam to abfall1762493530@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 8, 2025, at 7:49 AM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: On 07.11.2025 06:32 Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote: 3. My message was not that "IPv4 is enough". The shortage of IPv4 addresses is real. My message was that IPv6 design is so bad (on the subnet level) that businesses would stay on IPv4. Businesses stay on that because they don't want change. This applies to operating system versions and protocols. Remember when most businesses transferred HTTP traffic without TLS? It was Google that made that mandatory, so they implemented it. Same applies for SPF and DKIM. It existed more than 10 years and when Google and other big player made it mandatory, the businesses hurried up and implemented it. If Google ever decides to make IPv6 a criteria for page rank, businesses will implement that very fast. -- kind regards Marco Send spam to abfall1762493530@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3JNFOYGE...
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 8, 2025, at 7:49 AM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: On 07.11.2025 06:32 Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote: 3. My message was not that "IPv4 is enough". The shortage of IPv4 addresses is real. My message was that IPv6 design is so bad (on the subnet level) that businesses would stay on IPv4. Businesses stay on that because they don't want change. This applies to operating system versions and protocols. Remember when most businesses transferred HTTP traffic without TLS? It was Google that made that mandatory, so they implemented it. Same applies for SPF and DKIM. It existed more than 10 years and when Google and other big player made it mandatory, the businesses hurried up and implemented it. If Google ever decides to make IPv6 a criteria for page rank, businesses will implement that very fast. -- kind regards Marco Send spam to abfall1762493530@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 6, 2025, at 3:51 PM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: On 06.11.2025 12:11 Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote: Tell any financial department that 2% does not matter and see the reaction. Please tell that the various companies that route IPv6 traffic. All the ISP that don't have enough IPv4 want to have more traffic via IPv6 to save resources in their NAT gateways. This year was a talk at the RIPE conference about that topic. TLDR: IPv6 is cheaper in such situations. The larger header size is simply irrelevant. -- kind regards Marco Send spam to abfall1762427476@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DOLKO2JW...
So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine. On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
On 06.11.2025 07:12 Vasilenko Eduard wrote:
The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity.
No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GQ5AQ75W... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3WJNGJSN...
fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org> wrote:
So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine.
On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
On 06.11.2025 07:12 Vasilenko Eduard wrote:
The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity.
No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GQ5AQ75W... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3WJNGJSN...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZYNMIDYA...
Yes but that 98% reduction in electricity (do you have a source for that number?) is on the carrier side, not the cell phone side. There is also a good chance that the carrier router is going to consume the same power either way. Matthew Rienzo Network Engineer Southwestern Healthcare, Inc. 812.436.4333 Office 812.893.3576 Mobile From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 11:58 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: [External Sender] RE: my finance department cares deeply about 2% CAUTION: This email originated from outside of the organization. fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote:
So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine.
On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote:
Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
On 06.11.2025 07:12 Vasilenko Eduard wrote:
The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity.
No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GQ5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GQ5AQ75WAWRXFYS54QLFQAUMDGCM4QV4> _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3WJNGJSN3R252QI7CWBDOTAL37LNQFIH/<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3WJNGJSN3R252QI7CWBDOTAL37LNQFIH>
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EI7EM7BXCFKDS3WR7HNRLREHECTMUCR7/<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EI7EM7BXCFKDS3WR7HNRLREHECTMUCR7> Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.
Probably better to just ignore the nameless Internet trolls, rather than feeding them. ^_^; The 98% number is complete nonsense, as anyone who has built a network is aware. Eduard had a very good point that IPv6's multi homing support for multi-ISP hookups is horrifically broken compared to IPv4 with NAT for non-BGP speaking home installations. After years of trying to make it work, at my house we gave up and just disabled IPv6. In v4, primary ISP goes down, health check fails, default gateway VRRP address flips over to the other router, and web pages need a simple reload, and you're back in business with a new NAT translation table entry on the other router. With v6, primary router goes down, you try to flip default router addresses over, but you're not very successful because the default router is a link-local address coming from the RAs, so you start futzing with timing parameters to force the router's RA to invalidate the gateway so hosts stop using it, but then you have downstream devices that haven't stopped using the delegated v6 prefix from the dead ISP, so you have a bunch of "no route to host" problems where the host hasn't figured out it needs to invalidate its v6 address from that ISP and switch to using a v6 address from the other ISP. NAT66 is the answer, but due to dogmatic orthodoxy the number of consumer CPE devices that support NAT66 out of the box can be counted on one hand by captain Hook. So, the eventual inevitable answer is that if you're a home user with two ISPs, say Spectrum and ATT fiber, you simply disable IPv6 so that your family will stop calling you every time one ISP drops to ask why everything has gone so screwy again. Matt On Thu, Nov 6, 2025, 11:33 Matt Rienzo via NANOG <nanog@lists.nanog.org> wrote:
Yes but that 98% reduction in electricity (do you have a source for that number?) is on the carrier side, not the cell phone side. There is also a good chance that the carrier router is going to consume the same power either way.
Matthew Rienzo Network Engineer Southwestern Healthcare, Inc. 812.436.4333 Office 812.893.3576 Mobile
From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 11:58 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: [External Sender] RE: my finance department cares deeply about 2%
CAUTION: This email originated from outside of the organization. fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6.
On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> wrote:
So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine.
On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG < nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote:
Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto: nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
On 06.11.2025 07:12 Vasilenko Eduard wrote:
The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity.
No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GQ5AQ75W... < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GQ5AQ75W...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3WJNGJSN... < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3WJNGJSN...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZYNMIDYA... < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZYNMIDYA...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EI7EM7BX... < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EI7EM7BX...
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website. _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CHSFHGQW...
Multi-homing connections is very UNcommon for residential users, though, so I would think not much thought in consumer CPE would have been given to it at all. However, a bit different for business users.... As to your example, which seems to be a bit more of a step-up from regular consumer CPE.... I would think, you would keep consistent link-local addresses on the standby router, and on failover, that part would work just fine. Then the new router's RAs would go out, new addresses picked up, and the default route is unchanged. The old addresses linger on the host until they age out, but the new ones become primary and start flowing traffic almost immediately anyway. Effectively, except for the client address change, functionally identical to IPv4 failover. Existing TCP sessions will fail as expected and re-establish over the new primary address. I have dual-WAN setup with an SRX320 here, not a redundant pair unfortunately, and IPv6 failover between ISPs is rather seamless. Still the annoyance of broken connections (dropped call, game disconnect, etc - the standard tcp disruption stuff) but no real wait other than maybe one page timeout before connectivity is re-established entirely across the entire network. At least, for Windows/linux/mac/BSD/iOS/Android/PS5/cisco SIP desk phone/solaris/etc client devices I have here anyway. -----Original Message----- From: Matthew Petach via NANOG <nanog@lists.nanog.org> Sent: Friday, November 7, 2025 12:42 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Matt Rienzo <rienzom@southwestern.org>; Matthew Petach <mpetach@netflight.com> Subject: Re: [External Sender] RE: my finance department cares deeply about 2% Probably better to just ignore the nameless Internet trolls, rather than feeding them. ^_^; The 98% number is complete nonsense, as anyone who has built a network is aware. Eduard had a very good point that IPv6's multi homing support for multi-ISP hookups is horrifically broken compared to IPv4 with NAT for non-BGP speaking home installations. After years of trying to make it work, at my house we gave up and just disabled IPv6. In v4, primary ISP goes down, health check fails, default gateway VRRP address flips over to the other router, and web pages need a simple reload, and you're back in business with a new NAT translation table entry on the other router. With v6, primary router goes down, you try to flip default router addresses over, but you're not very successful because the default router is a link-local address coming from the RAs, so you start futzing with timing parameters to force the router's RA to invalidate the gateway so hosts stop using it, but then you have downstream devices that haven't stopped using the delegated v6 prefix from the dead ISP, so you have a bunch of "no route to host" problems where the host hasn't figured out it needs to invalidate its v6 address from that ISP and switch to using a v6 address from the other ISP. NAT66 is the answer, but due to dogmatic orthodoxy the number of consumer CPE devices that support NAT66 out of the box can be counted on one hand by captain Hook. So, the eventual inevitable answer is that if you're a home user with two ISPs, say Spectrum and ATT fiber, you simply disable IPv6 so that your family will stop calling you every time one ISP drops to ask why everything has gone so screwy again. Matt On Thu, Nov 6, 2025, 11:33 Matt Rienzo via NANOG <nanog@lists.nanog.org> wrote:
Yes but that 98% reduction in electricity (do you have a source for that number?) is on the carrier side, not the cell phone side. There is also a good chance that the carrier router is going to consume the same power either way.
Matthew Rienzo Network Engineer Southwestern Healthcare, Inc. 812.436.4333 Office 812.893.3576 Mobile
From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 11:58 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: [External Sender] RE: my finance department cares deeply about 2%
CAUTION: This email originated from outside of the organization. fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6.
So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the
On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> wrote: plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine.
On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG <
Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto: nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
On 06.11.2025 07:12 Vasilenko Eduard wrote:
The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity.
No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the
nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: header aren't.
The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GQ 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GQ 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3W JNGJSN3R252QI7CWBDOTAL37LNQFIH/ < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3W JNGJSN3R252QI7CWBDOTAL37LNQFIH
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZY NMIDYAXYZMGQJT2VX36DZIEY5XHNYC/ < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZY NMIDYAXYZMGQJT2VX36DZIEY5XHNYC
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EI 7EM7BXCFKDS3WR7HNRLREHECTMUCR7/ < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EI 7EM7BXCFKDS3WR7HNRLREHECTMUCR7
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website. _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CH SFHGQWW7FLVDF6LENS6PRO65TEDQ2S/
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3IZLYF5I...
Windows/linux/mac/BSD/iOS/Android/PS5/cisco SIP desk phone/solaris/etc
I had to laugh at this. I lose track of VMs these days in my SoHO/Lab. On Fri, Nov 7, 2025 at 1:32 PM Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote:
Multi-homing connections is very UNcommon for residential users, though, so I would think not much thought in consumer CPE would have been given to it at all. However, a bit different for business users....
As to your example, which seems to be a bit more of a step-up from regular consumer CPE....
I would think, you would keep consistent link-local addresses on the standby router, and on failover, that part would work just fine. Then the new router's RAs would go out, new addresses picked up, and the default route is unchanged. The old addresses linger on the host until they age out, but the new ones become primary and start flowing traffic almost immediately anyway.
Effectively, except for the client address change, functionally identical to IPv4 failover. Existing TCP sessions will fail as expected and re-establish over the new primary address.
I have dual-WAN setup with an SRX320 here, not a redundant pair unfortunately, and IPv6 failover between ISPs is rather seamless. Still the annoyance of broken connections (dropped call, game disconnect, etc - the standard tcp disruption stuff) but no real wait other than maybe one page timeout before connectivity is re-established entirely across the entire network. At least, for Windows/linux/mac/BSD/iOS/Android/PS5/cisco SIP desk phone/solaris/etc client devices I have here anyway.
-----Original Message----- From: Matthew Petach via NANOG <nanog@lists.nanog.org> Sent: Friday, November 7, 2025 12:42 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Matt Rienzo <rienzom@southwestern.org>; Matthew Petach < mpetach@netflight.com> Subject: Re: [External Sender] RE: my finance department cares deeply about 2%
Probably better to just ignore the nameless Internet trolls, rather than feeding them. ^_^;
The 98% number is complete nonsense, as anyone who has built a network is aware.
Eduard had a very good point that IPv6's multi homing support for multi-ISP hookups is horrifically broken compared to IPv4 with NAT for non-BGP speaking home installations. After years of trying to make it work, at my house we gave up and just disabled IPv6. In v4, primary ISP goes down, health check fails, default gateway VRRP address flips over to the other router, and web pages need a simple reload, and you're back in business with a new NAT translation table entry on the other router. With v6, primary router goes down, you try to flip default router addresses over, but you're not very successful because the default router is a link-local address coming from the RAs, so you start futzing with timing parameters to force the router's RA to invalidate the gateway so hosts stop using it, but then you have downstream devices that haven't stopped using the delegated v6 prefix from the dead ISP, so you have a bunch of "no route to host" problems where the host hasn't figured out it needs to invalidate its v6 address from that ISP and switch to using a v6 address from the other ISP. NAT66 is the answer, but due to dogmatic orthodoxy the number of consumer CPE devices that support NAT66 out of the box can be counted on one hand by captain Hook. So, the eventual inevitable answer is that if you're a home user with two ISPs, say Spectrum and ATT fiber, you simply disable IPv6 so that your family will stop calling you every time one ISP drops to ask why everything has gone so screwy again.
Matt
On Thu, Nov 6, 2025, 11:33 Matt Rienzo via NANOG <nanog@lists.nanog.org> wrote:
Yes but that 98% reduction in electricity (do you have a source for that number?) is on the carrier side, not the cell phone side. There is also a good chance that the carrier router is going to consume the same power either way.
Matthew Rienzo Network Engineer Southwestern Healthcare, Inc. 812.436.4333 Office 812.893.3576 Mobile
From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 11:58 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: [External Sender] RE: my finance department cares deeply about 2%
CAUTION: This email originated from outside of the organization. fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6.
So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the
On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> wrote: plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine.
On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG <
Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto: nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
On 06.11.2025 07:12 Vasilenko Eduard wrote:
The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity.
No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the
nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: header aren't.
The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GQ 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GQ 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3W JNGJSN3R252QI7CWBDOTAL37LNQFIH/ < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3W JNGJSN3R252QI7CWBDOTAL37LNQFIH
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZY NMIDYAXYZMGQJT2VX36DZIEY5XHNYC/ < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZY NMIDYAXYZMGQJT2VX36DZIEY5XHNYC
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EI 7EM7BXCFKDS3WR7HNRLREHECTMUCR7/ < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EI 7EM7BXCFKDS3WR7HNRLREHECTMUCR7
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website. _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CH SFHGQWW7FLVDF6LENS6PRO65TEDQ2S/
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3IZLYF5I... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZHAOIN7Z...
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 8:20 PM, Javier J via NANOG <nanog@lists.nanog.org> wrote: Windows/linux/mac/BSD/iOS/Android/PS5/cisco SIP desk phone/solaris/etc I had to laugh at this. I lose track of VMs these days in my SoHO/Lab. On Fri, Nov 7, 2025 at 1:32 PM Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote: Multi-homing connections is very UNcommon for residential users, though, so I would think not much thought in consumer CPE would have been given to it at all. However, a bit different for business users.... As to your example, which seems to be a bit more of a step-up from regular consumer CPE.... I would think, you would keep consistent link-local addresses on the standby router, and on failover, that part would work just fine. Then the new router's RAs would go out, new addresses picked up, and the default route is unchanged. The old addresses linger on the host until they age out, but the new ones become primary and start flowing traffic almost immediately anyway. Effectively, except for the client address change, functionally identical to IPv4 failover. Existing TCP sessions will fail as expected and re-establish over the new primary address. I have dual-WAN setup with an SRX320 here, not a redundant pair unfortunately, and IPv6 failover between ISPs is rather seamless. Still the annoyance of broken connections (dropped call, game disconnect, etc - the standard tcp disruption stuff) but no real wait other than maybe one page timeout before connectivity is re-established entirely across the entire network. At least, for Windows/linux/mac/BSD/iOS/Android/PS5/cisco SIP desk phone/solaris/etc client devices I have here anyway. -----Original Message----- From: Matthew Petach via NANOG <nanog@lists.nanog.org> Sent: Friday, November 7, 2025 12:42 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Matt Rienzo <rienzom@southwestern.org>; Matthew Petach < mpetach@netflight.com> Subject: Re: [External Sender] RE: my finance department cares deeply about 2% Probably better to just ignore the nameless Internet trolls, rather than feeding them. ^_^; The 98% number is complete nonsense, as anyone who has built a network is aware. Eduard had a very good point that IPv6's multi homing support for multi-ISP hookups is horrifically broken compared to IPv4 with NAT for non-BGP speaking home installations. After years of trying to make it work, at my house we gave up and just disabled IPv6. In v4, primary ISP goes down, health check fails, default gateway VRRP address flips over to the other router, and web pages need a simple reload, and you're back in business with a new NAT translation table entry on the other router. With v6, primary router goes down, you try to flip default router addresses over, but you're not very successful because the default router is a link-local address coming from the RAs, so you start futzing with timing parameters to force the router's RA to invalidate the gateway so hosts stop using it, but then you have downstream devices that haven't stopped using the delegated v6 prefix from the dead ISP, so you have a bunch of "no route to host" problems where the host hasn't figured out it needs to invalidate its v6 address from that ISP and switch to using a v6 address from the other ISP. NAT66 is the answer, but due to dogmatic orthodoxy the number of consumer CPE devices that support NAT66 out of the box can be counted on one hand by captain Hook. So, the eventual inevitable answer is that if you're a home user with two ISPs, say Spectrum and ATT fiber, you simply disable IPv6 so that your family will stop calling you every time one ISP drops to ask why everything has gone so screwy again. Matt On Thu, Nov 6, 2025, 11:33 Matt Rienzo via NANOG <nanog@lists.nanog.org> wrote: Yes but that 98% reduction in electricity (do you have a source for that number?) is on the carrier side, not the cell phone side. There is also a good chance that the carrier router is going to consume the same power either way. Matthew Rienzo Network Engineer Southwestern Healthcare, Inc. 812.436.4333 Office 812.893.3576 Mobile From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 11:58 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: [External Sender] RE: my finance department cares deeply about 2% CAUTION: This email originated from outside of the organization. fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> wrote: So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine. On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG < nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto: nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:12 Vasilenko Eduard wrote: The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4 _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] JNGJSN3R252QI7CWBDOTAL37LNQFIH/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] JNGJSN3R252QI7CWBDOTAL37LNQFIH _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] NMIDYAXYZMGQJT2VX36DZIEY5XHNYC/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] NMIDYAXYZMGQJT2VX36DZIEY5XHNYC _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 7EM7BXCFKDS3WR7HNRLREHECTMUCR7/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 7EM7BXCFKDS3WR7HNRLREHECTMUCR7 Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] SFHGQWW7FLVDF6LENS6PRO65TEDQ2S/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 8:20 PM, Javier J via NANOG <nanog@lists.nanog.org> wrote: Windows/linux/mac/BSD/iOS/Android/PS5/cisco SIP desk phone/solaris/etc I had to laugh at this. I lose track of VMs these days in my SoHO/Lab. On Fri, Nov 7, 2025 at 1:32 PM Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote: Multi-homing connections is very UNcommon for residential users, though, so I would think not much thought in consumer CPE would have been given to it at all. However, a bit different for business users.... As to your example, which seems to be a bit more of a step-up from regular consumer CPE.... I would think, you would keep consistent link-local addresses on the standby router, and on failover, that part would work just fine. Then the new router's RAs would go out, new addresses picked up, and the default route is unchanged. The old addresses linger on the host until they age out, but the new ones become primary and start flowing traffic almost immediately anyway. Effectively, except for the client address change, functionally identical to IPv4 failover. Existing TCP sessions will fail as expected and re-establish over the new primary address. I have dual-WAN setup with an SRX320 here, not a redundant pair unfortunately, and IPv6 failover between ISPs is rather seamless. Still the annoyance of broken connections (dropped call, game disconnect, etc - the standard tcp disruption stuff) but no real wait other than maybe one page timeout before connectivity is re-established entirely across the entire network. At least, for Windows/linux/mac/BSD/iOS/Android/PS5/cisco SIP desk phone/solaris/etc client devices I have here anyway. -----Original Message----- From: Matthew Petach via NANOG <nanog@lists.nanog.org> Sent: Friday, November 7, 2025 12:42 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Matt Rienzo <rienzom@southwestern.org>; Matthew Petach < mpetach@netflight.com> Subject: Re: [External Sender] RE: my finance department cares deeply about 2% Probably better to just ignore the nameless Internet trolls, rather than feeding them. ^_^; The 98% number is complete nonsense, as anyone who has built a network is aware. Eduard had a very good point that IPv6's multi homing support for multi-ISP hookups is horrifically broken compared to IPv4 with NAT for non-BGP speaking home installations. After years of trying to make it work, at my house we gave up and just disabled IPv6. In v4, primary ISP goes down, health check fails, default gateway VRRP address flips over to the other router, and web pages need a simple reload, and you're back in business with a new NAT translation table entry on the other router. With v6, primary router goes down, you try to flip default router addresses over, but you're not very successful because the default router is a link-local address coming from the RAs, so you start futzing with timing parameters to force the router's RA to invalidate the gateway so hosts stop using it, but then you have downstream devices that haven't stopped using the delegated v6 prefix from the dead ISP, so you have a bunch of "no route to host" problems where the host hasn't figured out it needs to invalidate its v6 address from that ISP and switch to using a v6 address from the other ISP. NAT66 is the answer, but due to dogmatic orthodoxy the number of consumer CPE devices that support NAT66 out of the box can be counted on one hand by captain Hook. So, the eventual inevitable answer is that if you're a home user with two ISPs, say Spectrum and ATT fiber, you simply disable IPv6 so that your family will stop calling you every time one ISP drops to ask why everything has gone so screwy again. Matt On Thu, Nov 6, 2025, 11:33 Matt Rienzo via NANOG <nanog@lists.nanog.org> wrote: Yes but that 98% reduction in electricity (do you have a source for that number?) is on the carrier side, not the cell phone side. There is also a good chance that the carrier router is going to consume the same power either way. Matthew Rienzo Network Engineer Southwestern Healthcare, Inc. 812.436.4333 Office 812.893.3576 Mobile From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 11:58 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: [External Sender] RE: my finance department cares deeply about 2% CAUTION: This email originated from outside of the organization. fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> wrote: So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine. On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG < nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto: nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:12 Vasilenko Eduard wrote: The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4 _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] JNGJSN3R252QI7CWBDOTAL37LNQFIH/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] JNGJSN3R252QI7CWBDOTAL37LNQFIH _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] NMIDYAXYZMGQJT2VX36DZIEY5XHNYC/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] NMIDYAXYZMGQJT2VX36DZIEY5XHNYC _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 7EM7BXCFKDS3WR7HNRLREHECTMUCR7/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 7EM7BXCFKDS3WR7HNRLREHECTMUCR7 Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] SFHGQWW7FLVDF6LENS6PRO65TEDQ2S/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
Wow! But how would you like to handle the situation where your IPv6 prefix is already (dynamically) assigned to the other household? A few seconds after the uplink was down. RIPE claims that it is 37% of cases worldwide. How to explain to the host that the particular IPv6 prefix should be immediately depicted? (after the event that it has not seen) Especially in the situation when your site has a few subnets (the host is in a different subnet from the Internet gateway). It is not just "the old session failed"; the new session would use IPv6, which is no longer leased to this household. It is too late to do anything on the router; the host would insert the wrong source IPv6 address. Actually, the number of problems for MHMP is tremendous. Read the draft if you'd like to know more. It just does not work for IPv6. I would agree that MHMP is not for residential users. It is for 30M of businesses worldwide. It is possible to push residential to IPv6, and they would not be aware of it (by the way, it is a success).
The number of consumer CPE devices that support NAT66 out of the box can be counted on one hand by captain Hook. The IETF policy is successful. Ed/ -----Original Message----- From: Gary Sparkes via NANOG <nanog@lists.nanog.org> Sent: Friday, November 7, 2025 21:32 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Matt Rienzo <rienzom@southwestern.org>; Gary Sparkes <gary@kisaracorporation.com> Subject: RE: [External Sender] RE: my finance department cares deeply about 2%
Multi-homing connections is very UNcommon for residential users, though, so I would think not much thought in consumer CPE would have been given to it at all. However, a bit different for business users....
As to your example, which seems to be a bit more of a step-up from regular consumer CPE....
I would think, you would keep consistent link-local addresses on the standby router, and on failover, that part would work just fine. Then the new router's RAs would go out, new addresses picked up, and the default route is unchanged. The old addresses linger on the host until they age out, but the new ones become primary and start flowing traffic almost immediately anyway.
Effectively, except for the client address change, functionally identical to IPv4 failover. Existing TCP sessions will fail as expected and re-establish over the new primary address.
I have dual-WAN setup with an SRX320 here, not a redundant pair unfortunately, and IPv6 failover between ISPs is rather seamless. Still the annoyance of broken connections (dropped call, game disconnect, etc - the standard tcp disruption stuff) but no real wait other than maybe one page timeout before connectivity is re-established entirely across the entire network. At least, for Windows/linux/mac/BSD/iOS/Android/PS5/cisco SIP desk phone/solaris/etc client devices I have here anyway.
-----Original Message----- From: Matthew Petach via NANOG <nanog@lists.nanog.org> Sent: Friday, November 7, 2025 12:42 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Matt Rienzo <rienzom@southwestern.org>; Matthew Petach <mpetach@netflight.com> Subject: Re: [External Sender] RE: my finance department cares deeply about 2%
Probably better to just ignore the nameless Internet trolls, rather than feeding them. ^_^;
The 98% number is complete nonsense, as anyone who has built a network is aware.
Eduard had a very good point that IPv6's multi homing support for multi-ISP hookups is horrifically broken compared to IPv4 with NAT for non-BGP speaking home installations. After years of trying to make it work, at my house we gave up and just disabled IPv6. In v4, primary ISP goes down, health check fails, default gateway VRRP address flips over to the other router, and web pages need a simple reload, and you're back in business with a new NAT translation table entry on the other router. With v6, primary router goes down, you try to flip default router addresses over, but you're not very successful because the default router is a link-local address coming from the RAs, so you start futzing with timing parameters to force the router's RA to invalidate the gateway so hosts stop using it, but then you have downstream devices that haven't stopped using the delegated v6 prefix from the dead ISP, so you have a bunch of "no route to host" problems where the host hasn't figured out it needs to invalidate its v6 address from that ISP and switch to using a v6 address from the other ISP. NAT66 is the answer, but due to dogmatic orthodoxy the number of consumer CPE devices that support NAT66 out of the box can be counted on one hand by captain Hook. So, the eventual inevitable answer is that if you're a home user with two ISPs, say Spectrum and ATT fiber, you simply disable IPv6 so that your family will stop calling you every time one ISP drops to ask why everything has gone so screwy again.
Matt
On Thu, Nov 6, 2025, 11:33 Matt Rienzo via NANOG <nanog@lists.nanog.org> wrote:
Yes but that 98% reduction in electricity (do you have a source for that number?) is on the carrier side, not the cell phone side. There is also a good chance that the carrier router is going to consume the same power either way.
Matthew Rienzo Network Engineer Southwestern Healthcare, Inc. 812.436.4333 Office 812.893.3576 Mobile
From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 11:58 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: [External Sender] RE: my finance department cares deeply about 2%
CAUTION: This email originated from outside of the organization. fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6.
So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the
On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> wrote: plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine.
On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG <
Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto: nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
On 06.11.2025 07:12 Vasilenko Eduard wrote:
The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity.
No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the
nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: header aren't.
The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GQ 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GQ 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3W JNGJSN3R252QI7CWBDOTAL37LNQFIH/ < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3W JNGJSN3R252QI7CWBDOTAL37LNQFIH
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZY NMIDYAXYZMGQJT2VX36DZIEY5XHNYC/ < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZY NMIDYAXYZMGQJT2VX36DZIEY5XHNYC
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EI 7EM7BXCFKDS3WR7HNRLREHECTMUCR7/ < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EI 7EM7BXCFKDS3WR7HNRLREHECTMUCR7
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website. _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CH SFHGQWW7FLVDF6LENS6PRO65TEDQ2S/
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3IZLYF5I T5FH5TZ6QKG3E2EPOZHVHCKC/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZHAOIN 7ZHX4G4GAW4N5OWP2NZILMIH2U/
Am 10.11.2025 um 09:17:13 Uhr schrieb Vasilenko Eduard via NANOG:
But how would you like to handle the situation where your IPv6 prefix is already (dynamically) assigned to the other household? A few seconds after the uplink was down. RIPE claims that it is 37% of cases worldwide. How to explain to the host that the particular IPv6 prefix should be immediately depicted? (after the event that it has not seen) Especially in the situation when your site has a few subnets (the host is in a different subnet from the Internet gateway).
Routers can invalidate RAs, my Cisco does when I reboot it. The clients will then remove those addresses and routes from the interface.
It is not just "the old session failed"; the new session would use IPv6, which is no longer leased to this household. It is too late to do anything on the router; the host would insert the wrong source IPv6 address.
The ISP blocks that in this case if it only allows the assigned source addresses, which is a good thing to avoid IP spoofing.
I would agree that MHMP is not for residential users. It is for 30M of businesses worldwide. It is possible to push residential to IPv6, and they would not be aware of it (by the way, it is a success).
You want to use residential solutions for businesses that have other demands. That is your biggest fallacy. Businesses do not want dynamically changing prefixes. There is no reason for ISPs not to provide static prefixes. It get one from my ISP - and I am a residual customer. -- Gruß Marco Send unsolicited bulk mail to 1762762633muell@cartoonies.org
You want to use residential solutions for businesses that have other demands. That is your biggest fallacy. EV: SOHO and SMB did use cheapest home GWs - it was enough for IPv4, even with ISP redundancy. If you would like to upgrade them to something much more expensive - good luck! I did not investigate specifically Cisco, I am doubt anybody supports MHMP properly, especially for the site that has a few subnets. IPv6 has fundamental problems on the subnet level. -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Monday, November 10, 2025 12:29 To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: [External Sender] RE: my finance department cares deeply about 2%
Am 10.11.2025 um 09:17:13 Uhr schrieb Vasilenko Eduard via NANOG:
But how would you like to handle the situation where your IPv6 prefix is already (dynamically) assigned to the other household? A few seconds after the uplink was down. RIPE claims that it is 37% of cases worldwide. How to explain to the host that the particular IPv6 prefix should be immediately depicted? (after the event that it has not seen) Especially in the situation when your site has a few subnets (the host is in a different subnet from the Internet gateway).
Routers can invalidate RAs, my Cisco does when I reboot it. The clients will then remove those addresses and routes from the interface.
It is not just "the old session failed"; the new session would use IPv6, which is no longer leased to this household. It is too late to do anything on the router; the host would insert the wrong source IPv6 address.
The ISP blocks that in this case if it only allows the assigned source addresses, which is a good thing to avoid IP spoofing.
I would agree that MHMP is not for residential users. It is for 30M of businesses worldwide. It is possible to push residential to IPv6, and they would not be aware of it (by the way, it is a success).
You want to use residential solutions for businesses that have other demands. That is your biggest fallacy.
Businesses do not want dynamically changing prefixes. There is no reason for ISPs not to provide static prefixes.
It get one from my ISP - and I am a residual customer.
-- Gruß Marco
Send unsolicited bulk mail to 1762762633muell@cartoonies.org
Am 10.11.2025 um 10:05:16 Uhr schrieb Vasilenko Eduard:
You want to use residential solutions for businesses that have other demands. That is your biggest fallacy. EV: SOHO and SMB did use cheapest home GWs - it was enough for IPv4,
Then I wish them fun with the crap they use. You get what you pay for and cheap home user hardware is not intended for business needs. If they use it anyway, their fault. As I already told you (I still have doubt you understand it), they don't get redundancy with that, but believe they get. I've seen crap network solutions and met people who had to investigate issues with them in companies. It is a PITA and if they want it, they deserve it. Rather simple. -- Gruß Marco Send unsolicited bulk mail to 1762765516muell@cartoonies.org
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 11:45 AM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: Am 10.11.2025 um 10:05:16 Uhr schrieb Vasilenko Eduard: You want to use residential solutions for businesses that have other demands. That is your biggest fallacy. EV: SOHO and SMB did use cheapest home GWs - it was enough for IPv4, Then I wish them fun with the crap they use. You get what you pay for and cheap home user hardware is not intended for business needs. If they use it anyway, their fault. As I already told you (I still have doubt you understand it), they don't get redundancy with that, but believe they get. I've seen crap network solutions and met people who had to investigate issues with them in companies. It is a PITA and if they want it, they deserve it. Rather simple. -- Gruß Marco Send unsolicited bulk mail to 1762765516muell@cartoonies.org _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HY5W6RAO...
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:05 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 11:45 AM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: Am 10.11.2025 um 10:05:16 Uhr schrieb Vasilenko Eduard: You want to use residential solutions for businesses that have other demands. That is your biggest fallacy. EV: SOHO and SMB did use cheapest home GWs - it was enough for IPv4, Then I wish them fun with the crap they use. You get what you pay for and cheap home user hardware is not intended for business needs. If they use it anyway, their fault. As I already told you (I still have doubt you understand it), they don't get redundancy with that, but believe they get. I've seen crap network solutions and met people who had to investigate issues with them in companies. It is a PITA and if they want it, they deserve it. Rather simple. -- Gruß Marco Send unsolicited bulk mail to 1762765516muell@cartoonies.org _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 11:05 AM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: You want to use residential solutions for businesses that have other demands. That is your biggest fallacy. EV: SOHO and SMB did use cheapest home GWs - it was enough for IPv4, even with ISP redundancy. If you would like to upgrade them to something much more expensive - good luck! I did not investigate specifically Cisco, I am doubt anybody supports MHMP properly, especially for the site that has a few subnets. IPv6 has fundamental problems on the subnet level. -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Monday, November 10, 2025 12:29 To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: [External Sender] RE: my finance department cares deeply about 2% Am 10.11.2025 um 09:17:13 Uhr schrieb Vasilenko Eduard via NANOG: But how would you like to handle the situation where your IPv6 prefix is already (dynamically) assigned to the other household? A few seconds after the uplink was down. RIPE claims that it is 37% of cases worldwide. How to explain to the host that the particular IPv6 prefix should be immediately depicted? (after the event that it has not seen) Especially in the situation when your site has a few subnets (the host is in a different subnet from the Internet gateway). Routers can invalidate RAs, my Cisco does when I reboot it. The clients will then remove those addresses and routes from the interface. It is not just "the old session failed"; the new session would use IPv6, which is no longer leased to this household. It is too late to do anything on the router; the host would insert the wrong source IPv6 address. The ISP blocks that in this case if it only allows the assigned source addresses, which is a good thing to avoid IP spoofing. I would agree that MHMP is not for residential users. It is for 30M of businesses worldwide. It is possible to push residential to IPv6, and they would not be aware of it (by the way, it is a success). You want to use residential solutions for businesses that have other demands. That is your biggest fallacy. Businesses do not want dynamically changing prefixes. There is no reason for ISPs not to provide static prefixes. It get one from my ISP - and I am a residual customer. -- Gruß Marco Send unsolicited bulk mail to 1762762633muell@cartoonies.org _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:05 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 11:05 AM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: You want to use residential solutions for businesses that have other demands. That is your biggest fallacy. EV: SOHO and SMB did use cheapest home GWs - it was enough for IPv4, even with ISP redundancy. If you would like to upgrade them to something much more expensive - good luck! I did not investigate specifically Cisco, I am doubt anybody supports MHMP properly, especially for the site that has a few subnets. IPv6 has fundamental problems on the subnet level. -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Monday, November 10, 2025 12:29 To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: [External Sender] RE: my finance department cares deeply about 2% Am 10.11.2025 um 09:17:13 Uhr schrieb Vasilenko Eduard via NANOG: But how would you like to handle the situation where your IPv6 prefix is already (dynamically) assigned to the other household? A few seconds after the uplink was down. RIPE claims that it is 37% of cases worldwide. How to explain to the host that the particular IPv6 prefix should be immediately depicted? (after the event that it has not seen) Especially in the situation when your site has a few subnets (the host is in a different subnet from the Internet gateway). Routers can invalidate RAs, my Cisco does when I reboot it. The clients will then remove those addresses and routes from the interface. It is not just "the old session failed"; the new session would use IPv6, which is no longer leased to this household. It is too late to do anything on the router; the host would insert the wrong source IPv6 address. The ISP blocks that in this case if it only allows the assigned source addresses, which is a good thing to avoid IP spoofing. I would agree that MHMP is not for residential users. It is for 30M of businesses worldwide. It is possible to push residential to IPv6, and they would not be aware of it (by the way, it is a success). You want to use residential solutions for businesses that have other demands. That is your biggest fallacy. Businesses do not want dynamically changing prefixes. There is no reason for ISPs not to provide static prefixes. It get one from my ISP - and I am a residual customer. -- Gruß Marco Send unsolicited bulk mail to 1762762633muell@cartoonies.org _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 10:29 AM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: Am 10.11.2025 um 09:17:13 Uhr schrieb Vasilenko Eduard via NANOG: But how would you like to handle the situation where your IPv6 prefix is already (dynamically) assigned to the other household? A few seconds after the uplink was down. RIPE claims that it is 37% of cases worldwide. How to explain to the host that the particular IPv6 prefix should be immediately depicted? (after the event that it has not seen) Especially in the situation when your site has a few subnets (the host is in a different subnet from the Internet gateway). Routers can invalidate RAs, my Cisco does when I reboot it. The clients will then remove those addresses and routes from the interface. It is not just "the old session failed"; the new session would use IPv6, which is no longer leased to this household. It is too late to do anything on the router; the host would insert the wrong source IPv6 address. The ISP blocks that in this case if it only allows the assigned source addresses, which is a good thing to avoid IP spoofing. I would agree that MHMP is not for residential users. It is for 30M of businesses worldwide. It is possible to push residential to IPv6, and they would not be aware of it (by the way, it is a success). You want to use residential solutions for businesses that have other demands. That is your biggest fallacy. Businesses do not want dynamically changing prefixes. There is no reason for ISPs not to provide static prefixes. It get one from my ISP - and I am a residual customer. -- Gruß Marco Send unsolicited bulk mail to 1762762633muell@cartoonies.org _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JOZATY4N...
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:05 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 10:29 AM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: Am 10.11.2025 um 09:17:13 Uhr schrieb Vasilenko Eduard via NANOG: But how would you like to handle the situation where your IPv6 prefix is already (dynamically) assigned to the other household? A few seconds after the uplink was down. RIPE claims that it is 37% of cases worldwide. How to explain to the host that the particular IPv6 prefix should be immediately depicted? (after the event that it has not seen) Especially in the situation when your site has a few subnets (the host is in a different subnet from the Internet gateway). Routers can invalidate RAs, my Cisco does when I reboot it. The clients will then remove those addresses and routes from the interface. It is not just "the old session failed"; the new session would use IPv6, which is no longer leased to this household. It is too late to do anything on the router; the host would insert the wrong source IPv6 address. The ISP blocks that in this case if it only allows the assigned source addresses, which is a good thing to avoid IP spoofing. I would agree that MHMP is not for residential users. It is for 30M of businesses worldwide. It is possible to push residential to IPv6, and they would not be aware of it (by the way, it is a success). You want to use residential solutions for businesses that have other demands. That is your biggest fallacy. Businesses do not want dynamically changing prefixes. There is no reason for ISPs not to provide static prefixes. It get one from my ISP - and I am a residual customer. -- Gruß Marco Send unsolicited bulk mail to 1762762633muell@cartoonies.org _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 10:17 AM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Wow! But how would you like to handle the situation where your IPv6 prefix is already (dynamically) assigned to the other household? A few seconds after the uplink was down. RIPE claims that it is 37% of cases worldwide. How to explain to the host that the particular IPv6 prefix should be immediately depicted? (after the event that it has not seen) Especially in the situation when your site has a few subnets (the host is in a different subnet from the Internet gateway). It is not just "the old session failed"; the new session would use IPv6, which is no longer leased to this household. It is too late to do anything on the router; the host would insert the wrong source IPv6 address. Actually, the number of problems for MHMP is tremendous. Read the draft if you'd like to know more. It just does not work for IPv6. I would agree that MHMP is not for residential users. It is for 30M of businesses worldwide. It is possible to push residential to IPv6, and they would not be aware of it (by the way, it is a success). The number of consumer CPE devices that support NAT66 out of the box can be counted on one hand by captain Hook. The IETF policy is successful. Ed/ -----Original Message----- From: Gary Sparkes via NANOG <nanog@lists.nanog.org> Sent: Friday, November 7, 2025 21:32 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Matt Rienzo <rienzom@southwestern.org>; Gary Sparkes <gary@kisaracorporation.com> Subject: RE: [External Sender] RE: my finance department cares deeply about 2% Multi-homing connections is very UNcommon for residential users, though, so I would think not much thought in consumer CPE would have been given to it at all. However, a bit different for business users.... As to your example, which seems to be a bit more of a step-up from regular consumer CPE.... I would think, you would keep consistent link-local addresses on the standby router, and on failover, that part would work just fine. Then the new router's RAs would go out, new addresses picked up, and the default route is unchanged. The old addresses linger on the host until they age out, but the new ones become primary and start flowing traffic almost immediately anyway. Effectively, except for the client address change, functionally identical to IPv4 failover. Existing TCP sessions will fail as expected and re-establish over the new primary address. I have dual-WAN setup with an SRX320 here, not a redundant pair unfortunately, and IPv6 failover between ISPs is rather seamless. Still the annoyance of broken connections (dropped call, game disconnect, etc - the standard tcp disruption stuff) but no real wait other than maybe one page timeout before connectivity is re-established entirely across the entire network. At least, for Windows/linux/mac/BSD/iOS/Android/PS5/cisco SIP desk phone/solaris/etc client devices I have here anyway. -----Original Message----- From: Matthew Petach via NANOG <nanog@lists.nanog.org> Sent: Friday, November 7, 2025 12:42 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Matt Rienzo <rienzom@southwestern.org>; Matthew Petach <mpetach@netflight.com> Subject: Re: [External Sender] RE: my finance department cares deeply about 2% Probably better to just ignore the nameless Internet trolls, rather than feeding them. ^_^; The 98% number is complete nonsense, as anyone who has built a network is aware. Eduard had a very good point that IPv6's multi homing support for multi-ISP hookups is horrifically broken compared to IPv4 with NAT for non-BGP speaking home installations. After years of trying to make it work, at my house we gave up and just disabled IPv6. In v4, primary ISP goes down, health check fails, default gateway VRRP address flips over to the other router, and web pages need a simple reload, and you're back in business with a new NAT translation table entry on the other router. With v6, primary router goes down, you try to flip default router addresses over, but you're not very successful because the default router is a link-local address coming from the RAs, so you start futzing with timing parameters to force the router's RA to invalidate the gateway so hosts stop using it, but then you have downstream devices that haven't stopped using the delegated v6 prefix from the dead ISP, so you have a bunch of "no route to host" problems where the host hasn't figured out it needs to invalidate its v6 address from that ISP and switch to using a v6 address from the other ISP. NAT66 is the answer, but due to dogmatic orthodoxy the number of consumer CPE devices that support NAT66 out of the box can be counted on one hand by captain Hook. So, the eventual inevitable answer is that if you're a home user with two ISPs, say Spectrum and ATT fiber, you simply disable IPv6 so that your family will stop calling you every time one ISP drops to ask why everything has gone so screwy again. Matt On Thu, Nov 6, 2025, 11:33 Matt Rienzo via NANOG <nanog@lists.nanog.org> wrote: Yes but that 98% reduction in electricity (do you have a source for that number?) is on the carrier side, not the cell phone side. There is also a good chance that the carrier router is going to consume the same power either way. Matthew Rienzo Network Engineer Southwestern Healthcare, Inc. 812.436.4333 Office 812.893.3576 Mobile From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 11:58 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: [External Sender] RE: my finance department cares deeply about 2% CAUTION: This email originated from outside of the organization. fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> wrote: So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine. On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG < nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto: nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:12 Vasilenko Eduard wrote: The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4 _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] JNGJSN3R252QI7CWBDOTAL37LNQFIH/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] JNGJSN3R252QI7CWBDOTAL37LNQFIH _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] NMIDYAXYZMGQJT2VX36DZIEY5XHNYC/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] NMIDYAXYZMGQJT2VX36DZIEY5XHNYC _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 7EM7BXCFKDS3WR7HNRLREHECTMUCR7/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 7EM7BXCFKDS3WR7HNRLREHECTMUCR7 Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] SFHGQWW7FLVDF6LENS6PRO65TEDQ2S/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] T5FH5TZ6QKG3E2EPOZHVHCKC/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 7ZHX4G4GAW4N5OWP2NZILMIH2U/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:05 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 10:17 AM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Wow! But how would you like to handle the situation where your IPv6 prefix is already (dynamically) assigned to the other household? A few seconds after the uplink was down. RIPE claims that it is 37% of cases worldwide. How to explain to the host that the particular IPv6 prefix should be immediately depicted? (after the event that it has not seen) Especially in the situation when your site has a few subnets (the host is in a different subnet from the Internet gateway). It is not just "the old session failed"; the new session would use IPv6, which is no longer leased to this household. It is too late to do anything on the router; the host would insert the wrong source IPv6 address. Actually, the number of problems for MHMP is tremendous. Read the draft if you'd like to know more. It just does not work for IPv6. I would agree that MHMP is not for residential users. It is for 30M of businesses worldwide. It is possible to push residential to IPv6, and they would not be aware of it (by the way, it is a success). The number of consumer CPE devices that support NAT66 out of the box can be counted on one hand by captain Hook. The IETF policy is successful. Ed/ -----Original Message----- From: Gary Sparkes via NANOG <nanog@lists.nanog.org> Sent: Friday, November 7, 2025 21:32 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Matt Rienzo <rienzom@southwestern.org>; Gary Sparkes <gary@kisaracorporation.com> Subject: RE: [External Sender] RE: my finance department cares deeply about 2% Multi-homing connections is very UNcommon for residential users, though, so I would think not much thought in consumer CPE would have been given to it at all. However, a bit different for business users.... As to your example, which seems to be a bit more of a step-up from regular consumer CPE.... I would think, you would keep consistent link-local addresses on the standby router, and on failover, that part would work just fine. Then the new router's RAs would go out, new addresses picked up, and the default route is unchanged. The old addresses linger on the host until they age out, but the new ones become primary and start flowing traffic almost immediately anyway. Effectively, except for the client address change, functionally identical to IPv4 failover. Existing TCP sessions will fail as expected and re-establish over the new primary address. I have dual-WAN setup with an SRX320 here, not a redundant pair unfortunately, and IPv6 failover between ISPs is rather seamless. Still the annoyance of broken connections (dropped call, game disconnect, etc - the standard tcp disruption stuff) but no real wait other than maybe one page timeout before connectivity is re-established entirely across the entire network. At least, for Windows/linux/mac/BSD/iOS/Android/PS5/cisco SIP desk phone/solaris/etc client devices I have here anyway. -----Original Message----- From: Matthew Petach via NANOG <nanog@lists.nanog.org> Sent: Friday, November 7, 2025 12:42 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Matt Rienzo <rienzom@southwestern.org>; Matthew Petach <mpetach@netflight.com> Subject: Re: [External Sender] RE: my finance department cares deeply about 2% Probably better to just ignore the nameless Internet trolls, rather than feeding them. ^_^; The 98% number is complete nonsense, as anyone who has built a network is aware. Eduard had a very good point that IPv6's multi homing support for multi-ISP hookups is horrifically broken compared to IPv4 with NAT for non-BGP speaking home installations. After years of trying to make it work, at my house we gave up and just disabled IPv6. In v4, primary ISP goes down, health check fails, default gateway VRRP address flips over to the other router, and web pages need a simple reload, and you're back in business with a new NAT translation table entry on the other router. With v6, primary router goes down, you try to flip default router addresses over, but you're not very successful because the default router is a link-local address coming from the RAs, so you start futzing with timing parameters to force the router's RA to invalidate the gateway so hosts stop using it, but then you have downstream devices that haven't stopped using the delegated v6 prefix from the dead ISP, so you have a bunch of "no route to host" problems where the host hasn't figured out it needs to invalidate its v6 address from that ISP and switch to using a v6 address from the other ISP. NAT66 is the answer, but due to dogmatic orthodoxy the number of consumer CPE devices that support NAT66 out of the box can be counted on one hand by captain Hook. So, the eventual inevitable answer is that if you're a home user with two ISPs, say Spectrum and ATT fiber, you simply disable IPv6 so that your family will stop calling you every time one ISP drops to ask why everything has gone so screwy again. Matt On Thu, Nov 6, 2025, 11:33 Matt Rienzo via NANOG <nanog@lists.nanog.org> wrote: Yes but that 98% reduction in electricity (do you have a source for that number?) is on the carrier side, not the cell phone side. There is also a good chance that the carrier router is going to consume the same power either way. Matthew Rienzo Network Engineer Southwestern Healthcare, Inc. 812.436.4333 Office 812.893.3576 Mobile From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 11:58 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: [External Sender] RE: my finance department cares deeply about 2% CAUTION: This email originated from outside of the organization. fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> wrote: So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine. On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG < nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto: nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:12 Vasilenko Eduard wrote: The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4 _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] JNGJSN3R252QI7CWBDOTAL37LNQFIH/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] JNGJSN3R252QI7CWBDOTAL37LNQFIH _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] NMIDYAXYZMGQJT2VX36DZIEY5XHNYC/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] NMIDYAXYZMGQJT2VX36DZIEY5XHNYC _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 7EM7BXCFKDS3WR7HNRLREHECTMUCR7/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 7EM7BXCFKDS3WR7HNRLREHECTMUCR7 Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] SFHGQWW7FLVDF6LENS6PRO65TEDQ2S/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] T5FH5TZ6QKG3E2EPOZHVHCKC/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 7ZHX4G4GAW4N5OWP2NZILMIH2U/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 7:31 PM, Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote: Multi-homing connections is very UNcommon for residential users, though, so I would think not much thought in consumer CPE would have been given to it at all. However, a bit different for business users.... As to your example, which seems to be a bit more of a step-up from regular consumer CPE.... I would think, you would keep consistent link-local addresses on the standby router, and on failover, that part would work just fine. Then the new router's RAs would go out, new addresses picked up, and the default route is unchanged. The old addresses linger on the host until they age out, but the new ones become primary and start flowing traffic almost immediately anyway. Effectively, except for the client address change, functionally identical to IPv4 failover. Existing TCP sessions will fail as expected and re-establish over the new primary address. I have dual-WAN setup with an SRX320 here, not a redundant pair unfortunately, and IPv6 failover between ISPs is rather seamless. Still the annoyance of broken connections (dropped call, game disconnect, etc - the standard tcp disruption stuff) but no real wait other than maybe one page timeout before connectivity is re-established entirely across the entire network. At least, for Windows/linux/mac/BSD/iOS/Android/PS5/cisco SIP desk phone/solaris/etc client devices I have here anyway. -----Original Message----- From: Matthew Petach via NANOG <nanog@lists.nanog.org> Sent: Friday, November 7, 2025 12:42 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Matt Rienzo <rienzom@southwestern.org>; Matthew Petach <mpetach@netflight.com> Subject: Re: [External Sender] RE: my finance department cares deeply about 2% Probably better to just ignore the nameless Internet trolls, rather than feeding them. ^_^; The 98% number is complete nonsense, as anyone who has built a network is aware. Eduard had a very good point that IPv6's multi homing support for multi-ISP hookups is horrifically broken compared to IPv4 with NAT for non-BGP speaking home installations. After years of trying to make it work, at my house we gave up and just disabled IPv6. In v4, primary ISP goes down, health check fails, default gateway VRRP address flips over to the other router, and web pages need a simple reload, and you're back in business with a new NAT translation table entry on the other router. With v6, primary router goes down, you try to flip default router addresses over, but you're not very successful because the default router is a link-local address coming from the RAs, so you start futzing with timing parameters to force the router's RA to invalidate the gateway so hosts stop using it, but then you have downstream devices that haven't stopped using the delegated v6 prefix from the dead ISP, so you have a bunch of "no route to host" problems where the host hasn't figured out it needs to invalidate its v6 address from that ISP and switch to using a v6 address from the other ISP. NAT66 is the answer, but due to dogmatic orthodoxy the number of consumer CPE devices that support NAT66 out of the box can be counted on one hand by captain Hook. So, the eventual inevitable answer is that if you're a home user with two ISPs, say Spectrum and ATT fiber, you simply disable IPv6 so that your family will stop calling you every time one ISP drops to ask why everything has gone so screwy again. Matt On Thu, Nov 6, 2025, 11:33 Matt Rienzo via NANOG <nanog@lists.nanog.org> wrote: Yes but that 98% reduction in electricity (do you have a source for that number?) is on the carrier side, not the cell phone side. There is also a good chance that the carrier router is going to consume the same power either way. Matthew Rienzo Network Engineer Southwestern Healthcare, Inc. 812.436.4333 Office 812.893.3576 Mobile From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 11:58 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: [External Sender] RE: my finance department cares deeply about 2% CAUTION: This email originated from outside of the organization. fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> wrote: So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine. On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG < nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto: nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:12 Vasilenko Eduard wrote: The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4 _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] JNGJSN3R252QI7CWBDOTAL37LNQFIH/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] JNGJSN3R252QI7CWBDOTAL37LNQFIH _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] NMIDYAXYZMGQJT2VX36DZIEY5XHNYC/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] NMIDYAXYZMGQJT2VX36DZIEY5XHNYC _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 7EM7BXCFKDS3WR7HNRLREHECTMUCR7/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 7EM7BXCFKDS3WR7HNRLREHECTMUCR7 Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] SFHGQWW7FLVDF6LENS6PRO65TEDQ2S/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 7:31 PM, Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote: Multi-homing connections is very UNcommon for residential users, though, so I would think not much thought in consumer CPE would have been given to it at all. However, a bit different for business users.... As to your example, which seems to be a bit more of a step-up from regular consumer CPE.... I would think, you would keep consistent link-local addresses on the standby router, and on failover, that part would work just fine. Then the new router's RAs would go out, new addresses picked up, and the default route is unchanged. The old addresses linger on the host until they age out, but the new ones become primary and start flowing traffic almost immediately anyway. Effectively, except for the client address change, functionally identical to IPv4 failover. Existing TCP sessions will fail as expected and re-establish over the new primary address. I have dual-WAN setup with an SRX320 here, not a redundant pair unfortunately, and IPv6 failover between ISPs is rather seamless. Still the annoyance of broken connections (dropped call, game disconnect, etc - the standard tcp disruption stuff) but no real wait other than maybe one page timeout before connectivity is re-established entirely across the entire network. At least, for Windows/linux/mac/BSD/iOS/Android/PS5/cisco SIP desk phone/solaris/etc client devices I have here anyway. -----Original Message----- From: Matthew Petach via NANOG <nanog@lists.nanog.org> Sent: Friday, November 7, 2025 12:42 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Matt Rienzo <rienzom@southwestern.org>; Matthew Petach <mpetach@netflight.com> Subject: Re: [External Sender] RE: my finance department cares deeply about 2% Probably better to just ignore the nameless Internet trolls, rather than feeding them. ^_^; The 98% number is complete nonsense, as anyone who has built a network is aware. Eduard had a very good point that IPv6's multi homing support for multi-ISP hookups is horrifically broken compared to IPv4 with NAT for non-BGP speaking home installations. After years of trying to make it work, at my house we gave up and just disabled IPv6. In v4, primary ISP goes down, health check fails, default gateway VRRP address flips over to the other router, and web pages need a simple reload, and you're back in business with a new NAT translation table entry on the other router. With v6, primary router goes down, you try to flip default router addresses over, but you're not very successful because the default router is a link-local address coming from the RAs, so you start futzing with timing parameters to force the router's RA to invalidate the gateway so hosts stop using it, but then you have downstream devices that haven't stopped using the delegated v6 prefix from the dead ISP, so you have a bunch of "no route to host" problems where the host hasn't figured out it needs to invalidate its v6 address from that ISP and switch to using a v6 address from the other ISP. NAT66 is the answer, but due to dogmatic orthodoxy the number of consumer CPE devices that support NAT66 out of the box can be counted on one hand by captain Hook. So, the eventual inevitable answer is that if you're a home user with two ISPs, say Spectrum and ATT fiber, you simply disable IPv6 so that your family will stop calling you every time one ISP drops to ask why everything has gone so screwy again. Matt On Thu, Nov 6, 2025, 11:33 Matt Rienzo via NANOG <nanog@lists.nanog.org> wrote: Yes but that 98% reduction in electricity (do you have a source for that number?) is on the carrier side, not the cell phone side. There is also a good chance that the carrier router is going to consume the same power either way. Matthew Rienzo Network Engineer Southwestern Healthcare, Inc. 812.436.4333 Office 812.893.3576 Mobile From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 11:58 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: [External Sender] RE: my finance department cares deeply about 2% CAUTION: This email originated from outside of the organization. fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> wrote: So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine. On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG < nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto: nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:12 Vasilenko Eduard wrote: The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4 _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] JNGJSN3R252QI7CWBDOTAL37LNQFIH/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] JNGJSN3R252QI7CWBDOTAL37LNQFIH _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] NMIDYAXYZMGQJT2VX36DZIEY5XHNYC/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] NMIDYAXYZMGQJT2VX36DZIEY5XHNYC _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 7EM7BXCFKDS3WR7HNRLREHECTMUCR7/ < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 7EM7BXCFKDS3WR7HNRLREHECTMUCR7 Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] SFHGQWW7FLVDF6LENS6PRO65TEDQ2S/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
Am 07.11.2025 um 09:41:46 Uhr schrieb Matthew Petach via NANOG:
NAT66 is the answer, but due to dogmatic orthodoxy the number of consumer CPE devices that support NAT66 out of the box can be counted on one hand by captain Hook.
You want a feature in a product for a consumer base that doesn't ask for this feature. This is the issue. -- Gruß Marco Send unsolicited bulk mail to 1762504906muell@cartoonies.org
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 8:45 PM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: Am 07.11.2025 um 09:41:46 Uhr schrieb Matthew Petach via NANOG: NAT66 is the answer, but due to dogmatic orthodoxy the number of consumer CPE devices that support NAT66 out of the box can be counted on one hand by captain Hook. You want a feature in a product for a consumer base that doesn't ask for this feature. This is the issue. -- Gruß Marco Send unsolicited bulk mail to 1762504906muell@cartoonies.org _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/65JSMR5F...
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 8:45 PM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: Am 07.11.2025 um 09:41:46 Uhr schrieb Matthew Petach via NANOG: NAT66 is the answer, but due to dogmatic orthodoxy the number of consumer CPE devices that support NAT66 out of the box can be counted on one hand by captain Hook. You want a feature in a product for a consumer base that doesn't ask for this feature. This is the issue. -- Gruß Marco Send unsolicited bulk mail to 1762504906muell@cartoonies.org _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 6:41 PM, Matthew Petach via NANOG <nanog@lists.nanog.org> wrote: Probably better to just ignore the nameless Internet trolls, rather than feeding them. ^_^; The 98% number is complete nonsense, as anyone who has built a network is aware. Eduard had a very good point that IPv6's multi homing support for multi-ISP hookups is horrifically broken compared to IPv4 with NAT for non-BGP speaking home installations. After years of trying to make it work, at my house we gave up and just disabled IPv6. In v4, primary ISP goes down, health check fails, default gateway VRRP address flips over to the other router, and web pages need a simple reload, and you're back in business with a new NAT translation table entry on the other router. With v6, primary router goes down, you try to flip default router addresses over, but you're not very successful because the default router is a link-local address coming from the RAs, so you start futzing with timing parameters to force the router's RA to invalidate the gateway so hosts stop using it, but then you have downstream devices that haven't stopped using the delegated v6 prefix from the dead ISP, so you have a bunch of "no route to host" problems where the host hasn't figured out it needs to invalidate its v6 address from that ISP and switch to using a v6 address from the other ISP. NAT66 is the answer, but due to dogmatic orthodoxy the number of consumer CPE devices that support NAT66 out of the box can be counted on one hand by captain Hook. So, the eventual inevitable answer is that if you're a home user with two ISPs, say Spectrum and ATT fiber, you simply disable IPv6 so that your family will stop calling you every time one ISP drops to ask why everything has gone so screwy again. Matt On Thu, Nov 6, 2025, 11:33 Matt Rienzo via NANOG <nanog@lists.nanog.org> wrote: Yes but that 98% reduction in electricity (do you have a source for that number?) is on the carrier side, not the cell phone side. There is also a good chance that the carrier router is going to consume the same power either way. Matthew Rienzo Network Engineer Southwestern Healthcare, Inc. 812.436.4333 Office 812.893.3576 Mobile From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 11:58 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: [External Sender] RE: my finance department cares deeply about 2% CAUTION: This email originated from outside of the organization. fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> wrote: So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine. On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG < nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto: nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:12 Vasilenko Eduard wrote: The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 6:41 PM, Matthew Petach via NANOG <nanog@lists.nanog.org> wrote: Probably better to just ignore the nameless Internet trolls, rather than feeding them. ^_^; The 98% number is complete nonsense, as anyone who has built a network is aware. Eduard had a very good point that IPv6's multi homing support for multi-ISP hookups is horrifically broken compared to IPv4 with NAT for non-BGP speaking home installations. After years of trying to make it work, at my house we gave up and just disabled IPv6. In v4, primary ISP goes down, health check fails, default gateway VRRP address flips over to the other router, and web pages need a simple reload, and you're back in business with a new NAT translation table entry on the other router. With v6, primary router goes down, you try to flip default router addresses over, but you're not very successful because the default router is a link-local address coming from the RAs, so you start futzing with timing parameters to force the router's RA to invalidate the gateway so hosts stop using it, but then you have downstream devices that haven't stopped using the delegated v6 prefix from the dead ISP, so you have a bunch of "no route to host" problems where the host hasn't figured out it needs to invalidate its v6 address from that ISP and switch to using a v6 address from the other ISP. NAT66 is the answer, but due to dogmatic orthodoxy the number of consumer CPE devices that support NAT66 out of the box can be counted on one hand by captain Hook. So, the eventual inevitable answer is that if you're a home user with two ISPs, say Spectrum and ATT fiber, you simply disable IPv6 so that your family will stop calling you every time one ISP drops to ask why everything has gone so screwy again. Matt On Thu, Nov 6, 2025, 11:33 Matt Rienzo via NANOG <nanog@lists.nanog.org> wrote: Yes but that 98% reduction in electricity (do you have a source for that number?) is on the carrier side, not the cell phone side. There is also a good chance that the carrier router is going to consume the same power either way. Matthew Rienzo Network Engineer Southwestern Healthcare, Inc. 812.436.4333 Office 812.893.3576 Mobile From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 11:58 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: [External Sender] RE: my finance department cares deeply about 2% CAUTION: This email originated from outside of the organization. fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> wrote: So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine. On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG < nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto: nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:12 Vasilenko Eduard wrote: The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] < https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
It depends on what is the benefit for any expense. For example, encryption cost is high, but there is a motivation that many people would accept (and create the pressure on the financial department to tolerate it). For the case of half IPv6 address bits wastage, it was initially "OSI layer violation to put MAC inside IP address just because some IPX politicians have big enough weight" that was later replaces by "randomize IP address to make more difficult to guess it or scan". Number of people who would support this madness would be very small - OTTs have hundreds of ways to de-anonymize users. Hence, it is just a wastage of 2% of Internet for nothing. Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 20:58 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: RE: my finance department cares deeply about 2% fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org> wrote:
So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine.
On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
On 06.11.2025 07:12 Vasilenko Eduard wrote:
The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity.
No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GQ 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3W JNGJSN3R252QI7CWBDOTAL37LNQFIH/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZYN MIDYAXYZMGQJT2VX36DZIEY5XHNYC/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EI7EM7BX...
On 07.11.2025 06:18 Vasilenko Eduard via NANOG wrote:
For example, encryption cost is high, but there is a motivation that many people would accept (and create the pressure on the financial department to tolerate it).
Wrong, encryption is a rather small task comparing to other processes, like JavaScript in the browser on bloated websites.
For the case of half IPv6 address bits wastage, it was initially "OSI layer violation to put MAC inside IP address just because some IPX politicians have big enough weight" that was later replaces by "randomize IP address to make more difficult to guess it or scan". Number of people who would support this madness would be very small - OTTs have hundreds of ways to de-anonymize users. Hence, it is just a wastage of 2% of Internet for nothing.
And no one cares about that waste. The time of saving every bit is over for a long time. Otherwise bloated operating systems, huge computer games or websites with megabytes of data for nothing would not exist.
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 3:06 PM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: On 07.11.2025 06:18 Vasilenko Eduard via NANOG wrote: For example, encryption cost is high, but there is a motivation that many people would accept (and create the pressure on the financial department to tolerate it). Wrong, encryption is a rather small task comparing to other processes, like JavaScript in the browser on bloated websites. For the case of half IPv6 address bits wastage, it was initially "OSI layer violation to put MAC inside IP address just because some IPX politicians have big enough weight" that was later replaces by "randomize IP address to make more difficult to guess it or scan". Number of people who would support this madness would be very small - OTTs have hundreds of ways to de-anonymize users. Hence, it is just a wastage of 2% of Internet for nothing. And no one cares about that waste. The time of saving every bit is over for a long time. Otherwise bloated operating systems, huge computer games or websites with megabytes of data for nothing would not exist. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 3:06 PM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: On 07.11.2025 06:18 Vasilenko Eduard via NANOG wrote: For example, encryption cost is high, but there is a motivation that many people would accept (and create the pressure on the financial department to tolerate it). Wrong, encryption is a rather small task comparing to other processes, like JavaScript in the browser on bloated websites. For the case of half IPv6 address bits wastage, it was initially "OSI layer violation to put MAC inside IP address just because some IPX politicians have big enough weight" that was later replaces by "randomize IP address to make more difficult to guess it or scan". Number of people who would support this madness would be very small - OTTs have hundreds of ways to de-anonymize users. Hence, it is just a wastage of 2% of Internet for nothing. And no one cares about that waste. The time of saving every bit is over for a long time. Otherwise bloated operating systems, huge computer games or websites with megabytes of data for nothing would not exist. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
Hence, it is just a wastage of 2% of Internet for nothing.
Standard internet MTU = 1500 bytes. IPv4 header is 1.33% of the standard 1500 byte packet size. ( Assuming IHL = 5, so no options, 20B) IPv6 header is 40B, so this becomes 2.67%. ( 1.33% * 2 ) You can of course rant on about how this is 1.33% more "wasted", oh noes! But do you make the same argument to the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing? How many more 1500B packets are "wasted" there? There are lots of reasonable complaints about things related to IPv6. Complaining that the header is "wasting" bits on the wire is absolutely NOT one of them. On Fri, Nov 7, 2025 at 1:19 AM Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote:
It depends on what is the benefit for any expense.
For example, encryption cost is high, but there is a motivation that many people would accept (and create the pressure on the financial department to tolerate it).
For the case of half IPv6 address bits wastage, it was initially "OSI layer violation to put MAC inside IP address just because some IPX politicians have big enough weight" that was later replaces by "randomize IP address to make more difficult to guess it or scan". Number of people who would support this madness would be very small - OTTs have hundreds of ways to de-anonymize users. Hence, it is just a wastage of 2% of Internet for nothing. Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 20:58 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: RE: my finance department cares deeply about 2%
fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6.
On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org> wrote:
So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine.
On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote:
Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
On 06.11.2025 07:12 Vasilenko Eduard wrote:
The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity.
No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GQ 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3W JNGJSN3R252QI7CWBDOTAL37LNQFIH/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZYN MIDYAXYZMGQJT2VX36DZIEY5XHNYC/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EI7EM7BX... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/P47JM32L...
Just think of the savings. Call the finance department and implement jumbo frames everywhere, immediately, and without testing. We can decrease that waste more than 6x! Andrew On Fri, Nov 7, 2025 at 11:15 AM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
Hence, it is just a wastage of 2% of Internet for nothing.
Standard internet MTU = 1500 bytes.
IPv4 header is 1.33% of the standard 1500 byte packet size. ( Assuming IHL = 5, so no options, 20B) IPv6 header is 40B, so this becomes 2.67%. ( 1.33% * 2 )
You can of course rant on about how this is 1.33% more "wasted", oh noes! But do you make the same argument to the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing? How many more 1500B packets are "wasted" there?
There are lots of reasonable complaints about things related to IPv6. Complaining that the header is "wasting" bits on the wire is absolutely NOT one of them.
On Fri, Nov 7, 2025 at 1:19 AM Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote:
It depends on what is the benefit for any expense.
For example, encryption cost is high, but there is a motivation that many people would accept (and create the pressure on the financial department to tolerate it).
For the case of half IPv6 address bits wastage, it was initially "OSI layer violation to put MAC inside IP address just because some IPX politicians have big enough weight" that was later replaces by "randomize IP address to make more difficult to guess it or scan". Number of people who would support this madness would be very small - OTTs have hundreds of ways to de-anonymize users. Hence, it is just a wastage of 2% of Internet for nothing. Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 20:58 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: RE: my finance department cares deeply about 2%
fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6.
On 6 November 2025 18:52:07 CET, nanog--- via NANOG < nanog@lists.nanog.org> wrote:
So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine.
On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote:
Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
On 06.11.2025 07:12 Vasilenko Eduard wrote:
The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity.
No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GQ 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3W JNGJSN3R252QI7CWBDOTAL37LNQFIH/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZYN MIDYAXYZMGQJT2VX36DZIEY5XHNYC/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EI7EM7BX...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/P47JM32L...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/4MNK4EWX...
Would this not require supporting Jumbo TCP SYN? ;P Nathan Fowler Director, Information Security Operations Threat Hunting, Countermeasures, and Detection Engineering First Citizens Bank Alabama – Remote Firstcitizens.com Internal -----Original Message----- From: Andrew Kirch via NANOG <nanog@lists.nanog.org> Sent: Friday, November 7, 2025 10:17 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Andrew Kirch <trelane@trelane.net> Subject: [EXTERNAL] Re: my finance department cares deeply about 2% NOTICE: External Sender. Please exercise caution when opening attachments or clicking links. Just think of the savings. Call the finance department and implement jumbo frames everywhere, immediately, and without testing. We can decrease that waste more than 6x! Andrew On Fri, Nov 7, 2025 at 11:15 AM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
Hence, it is just a wastage of 2% of Internet for nothing.
Standard internet MTU = 1500 bytes.
IPv4 header is 1.33% of the standard 1500 byte packet size. ( Assuming IHL = 5, so no options, 20B) IPv6 header is 40B, so this becomes 2.67%. ( 1.33% * 2 )
You can of course rant on about how this is 1.33% more "wasted", oh noes! But do you make the same argument to the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing? How many more 1500B packets are "wasted" there?
There are lots of reasonable complaints about things related to IPv6. Complaining that the header is "wasting" bits on the wire is absolutely NOT one of them.
On Fri, Nov 7, 2025 at 1:19 AM Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote:
It depends on what is the benefit for any expense.
For example, encryption cost is high, but there is a motivation that many people would accept (and create the pressure on the financial department to tolerate it).
For the case of half IPv6 address bits wastage, it was initially "OSI layer violation to put MAC inside IP address just because some IPX politicians have big enough weight" that was later replaces by "randomize IP address to make more difficult to guess it or scan". Number of people who would support this madness would be very small - OTTs have hundreds of ways to de-anonymize users. Hence, it is just a wastage of 2% of Internet for nothing. Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 20:58 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: RE: my finance department cares deeply about 2%
fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6.
So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the
On 6 November 2025 18:52:07 CET, nanog--- via NANOG < nanog@lists.nanog.org> wrote: plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine.
On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG <
Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
On 06.11.2025 07:12 Vasilenko Eduard wrote:
The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity.
No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the
nanog@lists.nanog.org> wrote: header aren't.
The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/ nanog@lists.nanog.org/message/GQ__;!!OgNkHJCYlf_CHg!dEvJjT_OFfRXEk zGQ2dCnkZJGxRYgwYW5anCp5g9pqvGHnJqlLG2VLOOYqoC238TnPEfXH4DsFZF6Jmc R_RKduks9jye$ 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/ nanog@lists.nanog.org/message/3W__;!!OgNkHJCYlf_CHg!dEvJjT_OFfRXEk zGQ2dCnkZJGxRYgwYW5anCp5g9pqvGHnJqlLG2VLOOYqoC238TnPEfXH4DsFZF6Jmc R_RKds_sYQtG$ JNGJSN3R252QI7CWBDOTAL37LNQFIH/
NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/n anog@lists.nanog.org/message/ZYN__;!!OgNkHJCYlf_CHg!dEvJjT_OFfRXEkz GQ2dCnkZJGxRYgwYW5anCp5g9pqvGHnJqlLG2VLOOYqoC238TnPEfXH4DsFZF6JmcR_ RKduJ8UKhd$ MIDYAXYZMGQJT2VX36DZIEY5XHNYC/
NANOG mailing list
https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nano g@lists.nanog.org/message/EI7EM7BXCFKDS3WR7HNRLREHECTMUCR7/__;!!OgNkHJ CYlf_CHg!dEvJjT_OFfRXEkzGQ2dCnkZJGxRYgwYW5anCp5g9pqvGHnJqlLG2VLOOYqoC2 38TnPEfXH4DsFZF6JmcR_RKdgSu7E55$
_______________________________________________ NANOG mailing list
https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nano g@lists.nanog.org/message/P47JM32L2IYAYYSHNGVBRQFWEIMTEFYQ/__;!!OgNkHJ CYlf_CHg!dEvJjT_OFfRXEkzGQ2dCnkZJGxRYgwYW5anCp5g9pqvGHnJqlLG2VLOOYqoC2 38TnPEfXH4DsFZF6JmcR_RKdgH2OUlw$
_______________________________________________ NANOG mailing list
https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nano g@lists.nanog.org/message/4MNK4EWXVHEAXEXYZCLX3JKVPH5Z6QEQ/__;!!OgNkHJ CYlf_CHg!dEvJjT_OFfRXEkzGQ2dCnkZJGxRYgwYW5anCp5g9pqvGHnJqlLG2VLOOYqoC2 38TnPEfXH4DsFZF6JmcR_RKdjUSMPRd$
NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... ---------------------------------------------------------------------- This electronic mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the electronic mail to the intended recipient, be advised that you have received this electronic mail in error and that any use, dissemination, forwarding, printing, or copying of this electronic mail is strictly prohibited. If you have received this electronic mail in error, please immediately notify the sender by return mail. First-Citizens Bank & Trust Company, as well as its divisions, subsidiaries, and affiliates (together, First Citizens) are U.S. financial institutions and provide products and services to non-U.S. clients on a cross-border basis from the United States of America. First Citizens is not licensed or regulated as a bank or any other type of financial institution outside of the United States of America. Please review our International Disclosures at https://www.firstcitizens.com/international-disclosures for more information. Visit us online at www.firstcitizens.com or call 1-888-FC DIRECT (1-888-323-4732). First Citizens Bank. Forever First®. Member FDIC. ---------------------------------------------------------------------------------------------------
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 5:32 PM, ThreatHunt Alerts via NANOG <nanog@lists.nanog.org> wrote: Would this not require supporting Jumbo TCP SYN? +ADs-P Nathan Fowler Director, Information Security Operations Threat Hunting, Countermeasures, and Detection Engineering First Citizens Bank Alabama +IBM- Remote Firstcitizens.com Internal -----Original Message----- From: Andrew Kirch via NANOG +ADw-nanog+AEA-lists.nanog.org+AD4- Sent: Friday, November 7, 2025 10:17 To: North American Network Operators Group +ADw-nanog+AEA-lists.nanog.org+AD4- Cc: Andrew Kirch +ADw-trelane+AEA-trelane.net+AD4- Subject: +AFs-EXTERNAL+AF0- Re: my finance department cares deeply about 2+ACU- NOTICE: External Sender. Please exercise caution when opening attachments or clicking links. Just think of the savings. Call the finance department and implement jumbo frames everywhere, immediately, and without testing. We can decrease that waste more than 6x+ACE- Andrew On Fri, Nov 7, 2025 at 11:15+IC8-AM Tom Beecher via NANOG +ADw-nanog+AEA-lists.nanog.org+AD4- wrote: +AD4- +AD4- +AD4- +AD4- Hence, it is just a wastage of 2+ACU- of Internet for nothing. +AD4- +AD4- +AD4- Standard internet MTU +AD0- 1500 bytes. +AD4- +AD4- IPv4 header is 1.33+ACU- of the standard 1500 byte packet size. ( Assuming +AD4- IHL +AD0- 5, so no options, 20B) +AD4- IPv6 header is 40B, so this becomes 2.67+ACU-. ( 1.33+ACU- +ACo- 2 ) +AD4- +AD4- You can of course rant on about how this is 1.33+ACU- more +ACI-wasted+ACI-, oh noes+ACE- +AD4- But do you make the same argument to the application developers that +AD4- pull 1GB of data over the network when they really only need about +AD4- 200KB for the thing they are doing? How many more 1500B packets are +ACI-wasted+ACI- there? +AD4- +AD4- There are lots of reasonable complaints about things related to IPv6. +AD4- Complaining that the header is +ACI-wasting+ACI- bits on the wire is +AD4- absolutely NOT one of them. +AD4- +AD4- +AD4- +AD4- +AD4- On Fri, Nov 7, 2025 at 1:19+IC8-AM Vasilenko Eduard via NANOG +ADw- +AD4- nanog+AEA-lists.nanog.org+AD4- wrote: +AD4- +AD4- +AD4- It depends on what is the benefit for any expense. +AD4- +AD4- +AD4- +AD4- For example, encryption cost is high, but there is a motivation that +AD4- +AD4- many people would accept (and create the pressure on the financial +AD4- +AD4- department +AD4- to +AD4- +AD4- tolerate it). +AD4- +AD4- +AD4- +AD4- For the case of half IPv6 address bits wastage, it was initially +AD4- +AD4- +ACI-OSI layer violation to put MAC inside IP address just because some +AD4- +AD4- IPX politicians have big enough weight+ACI- that was later replaces by +AD4- +AD4- +ACI-randomize IP address to make more difficult to guess it or scan+ACI-. +AD4- +AD4- Number of people who would support this madness would be very small +AD4- +AD4- - OTTs have hundreds +AD4- of +AD4- +AD4- ways to de-anonymize users. Hence, it is just a wastage of 2+ACU- of +AD4- +AD4- Internet for nothing. +AD4- +AD4- Ed/ +AD4- +AD4- -----Original Message----- +AD4- +AD4- From: nanog--- via NANOG +ADw-nanog+AEA-lists.nanog.org+AD4- +AD4- +AD4- Sent: Thursday, November 6, 2025 20:58 +AD4- +AD4- To: North American Network Operators Group +ADw-nanog+AEA-lists.nanog.org+AD4- +AD4- +AD4- Cc: nanog+AEA-immibis.com +AD4- +AD4- Subject: RE: my finance department cares deeply about 2+ACU- +AD4- +AD4- +AD4- +AD4- fun fact I forgot to mention: if you use ipv6 on cellphone +AD4- +AD4- connections, your site loads more than 2+ACU- faster and uses less than +AD4- +AD4- 98+ACU- as much electricity, due to avoiding the expensive and +AD4- +AD4- computation-hungry NAT process itself, as well as not needing to be +AD4- +AD4- physically routed to that +AD4- big +AD4- +AD4- centralised server and back. So if you care about 2+ACU-, you'll use IPv6. +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- On 6 November 2025 18:52:07 CET, nanog--- via NANOG +ADw- +AD4- nanog+AEA-lists.nanog.org+AD4- +AD4- +AD4- wrote: +AD4- +AD4- +AD4-So you use header compression on all your links, right? No sense +AD4- reducing +AD4- +AD4- your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is +AD4- +AD4- already 5+ACU- of each IP packet header. Speaking of headers I take it +AD4- +AD4- you're using SLIP instead of Ethernet? And you avoid TLS like the +AD4- +AD4- plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as +AD4- +AD4- well - your finance department will thank you. This is asinine. +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4-On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG +ADw- +AD4- +AD4- nanog+AEA-lists.nanog.org+AD4- wrote: +AD4- +AD4- +AD4APg-Tell any financial department that 2+ACU- does not matter and see the +AD4- +AD4- +AD4APg-reaction. +AD4- +AD4- +AD4APg-Ed/ +AD4- +AD4- +AD4APg------Original Message----- +AD4- +AD4- +AD4APg-From: Marco Moock via NANOG +ADw-nanog+AEA-lists.nanog.org+AD4- +AD4- +AD4- +AD4APg-Sent: Thursday, November 6, 2025 14:53 +AD4- +AD4- +AD4APg-To: North American Network Operators Group +ADw-nanog+AEA-lists.nanog.org+AD4- +AD4- +AD4- +AD4APg-Cc: Marco Moock +ADw-mm+AEA-dorfdsl.de+AD4- +AD4- +AD4- +AD4APg-Subject: Re: Artificial Juniper SRX limitations preventing IPv6 +AD4- +AD4- +AD4APg-deployment (and sales) +AD4- +AD4- +AD4APg- +AD4- +AD4- +AD4APg-On 06.11.2025 07:12 Vasilenko Eduard wrote: +AD4- +AD4- +AD4APg- +AD4- +AD4- +AD4APgA+- The issue that 128bits (64+-64) are wasted in every packet. +AD4- +AD4- +AD4APgA+- Formally, for +ACI-privacy+ACI-. Content providers are lathing from such +AD4- +AD4- +AD4APgA+- form or privacy. But it is 2+ACU- of the internet capacity. +AD4- +AD4- +AD4APg- +AD4- +AD4- +AD4APg-No one cares nowadays. The amount of other crap traffic (scrapers, +AD4- +AD4- +AD4APg-AI, +AD4- +AD4- spam, DDoS attacks) is a real problem, the additional bits in the +AD4- +AD4- header aren't. +AD4- +AD4- +AD4APg-The time of slow dialup connections where every bit matters, is over. +AD4- +AD4- +AD4APgBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8- +AD4- +AD4- +AD4APg-NANOG mailing list +AD4- +AD4- +AD4APg-https://urldefense.com/v3/+AF8AXw-https://lists.nanog.org/archives/list/ +AD4- +AD4- +AD4APg-nanog+AEA-lists.nanog.org/message/GQ+AF8AXwA7ACEAIQ-OgNkHJCYlf+AF8-CHg+ACE-dEvJjT+AF8-OFfRXEk +AD4- +AD4- +AD4APg-zGQ2dCnkZJGxRYgwYW5anCp5g9pqvGHnJqlLG2VLOOYqoC238TnPEfXH4DsFZF6Jmc +AD4- +AD4- +AD4APg-R+AF8-RKduks9jye+ACQ- +AD4- +AD4- +AD4APg-5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ +AD4- +AD4- +AD4APgBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8- +AD4- +AD4- +AD4APg-NANOG mailing list +AD4- +AD4- +AD4APg-https://urldefense.com/v3/+AF8AXw-https://lists.nanog.org/archives/list/ +AD4- +AD4- +AD4APg-nanog+AEA-lists.nanog.org/message/3W+AF8AXwA7ACEAIQ-OgNkHJCYlf+AF8-CHg+ACE-dEvJjT+AF8-OFfRXEk +AD4- +AD4- +AD4APg-zGQ2dCnkZJGxRYgwYW5anCp5g9pqvGHnJqlLG2VLOOYqoC238TnPEfXH4DsFZF6Jmc +AD4- +AD4- +AD4APg-R+AF8-RKds+AF8-sYQtG+ACQ- +AD4- +AD4- +AD4APg-JNGJSN3R252QI7CWBDOTAL37LNQFIH/ +AD4- +AD4- +AD4AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBf- +AD4- +AD4- +AD4-NANOG mailing list +AD4- +AD4- +AD4-https://urldefense.com/v3/+AF8AXw-https://lists.nanog.org/archives/list/n +AD4- +AD4- +AD4-anog+AEA-lists.nanog.org/message/ZYN+AF8AXwA7ACEAIQ-OgNkHJCYlf+AF8-CHg+ACE-dEvJjT+AF8-OFfRXEkz +AD4- +AD4- +AD4-GQ2dCnkZJGxRYgwYW5anCp5g9pqvGHnJqlLG2VLOOYqoC238TnPEfXH4DsFZF6JmcR+AF8- +AD4- +AD4- +AD4-RKduJ8UKhd+ACQ- +AD4- +AD4- +AD4-MIDYAXYZMGQJT2VX36DZIEY5XHNYC/ +AD4- +AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- +AD4- +AD4- NANOG mailing list +AD4- +AD4- +AD4- +AD4- +AD4- https://urldefense.com/v3/+AF8AXw-https://lists.nanog.org/archives/list/nano +AD4- g+AEA-lists.nanog.org/message/EI7EM7BXCFKDS3WR7HNRLREHECTMUCR7/+AF8AXwA7ACEAIQ-OgNkHJ +AD4- CYlf+AF8-CHg+ACE-dEvJjT+AF8-OFfRXEkzGQ2dCnkZJGxRYgwYW5anCp5g9pqvGHnJqlLG2VLOOYqoC2 +AD4- 38TnPEfXH4DsFZF6JmcR+AF8-RKdgSu7E55+ACQ- +AD4- +AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- +AD4- +AD4- NANOG mailing list +AD4- +AD4- +AD4- +AD4- +AD4- https://urldefense.com/v3/+AF8AXw-https://lists.nanog.org/archives/list/nano +AD4- g+AEA-lists.nanog.org/message/P47JM32L2IYAYYSHNGVBRQFWEIMTEFYQ/+AF8AXwA7ACEAIQ-OgNkHJ +AD4- CYlf+AF8-CHg+ACE-dEvJjT+AF8-OFfRXEkzGQ2dCnkZJGxRYgwYW5anCp5g9pqvGHnJqlLG2VLOOYqoC2 +AD4- 38TnPEfXH4DsFZF6JmcR+AF8-RKdgH2OUlw+ACQ- +AD4- +AD4- +AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- +AD4- NANOG mailing list +AD4- +AD4- https://urldefense.com/v3/+AF8AXw-https://lists.nanog.org/archives/list/nano +AD4- g+AEA-lists.nanog.org/message/4MNK4EWXVHEAXEXYZCLX3JKVPH5Z6QEQ/+AF8AXwA7ACEAIQ-OgNkHJ +AD4- CYlf+AF8-CHg+ACE-dEvJjT+AF8-OFfRXEkzGQ2dCnkZJGxRYgwYW5anCp5g9pqvGHnJqlLG2VLOOYqoC2 +AD4- 38TnPEfXH4DsFZF6JmcR+AF8-RKdjUSMPRd+ACQ- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- NANOG mailing list https://urldefense.com/v3/+AF8AXw-https://lists.nanog.org/archives/list/nano... ---------------------------------------------------------------------- This electronic mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the electronic mail to the intended recipient, be advised that you have received this electronic mail in error and that any use, dissemination, forwarding, printing, or copying of this electronic mail is strictly prohibited. If you have received this electronic mail in error, please immediately notify the sender by return mail. First-Citizens Bank +ACY- Trust Company, as well as its divisions, subsidiaries, and affiliates (together, First Citizens) are U.S. financial institutions and provide products and services to non-U.S. clients on a cross-border basis from the United States of America. First Citizens is not licensed or regulated as a bank or any other type of financial institution outside of the United States of America. Please review our International Disclosures at https://urldefense.com/v3/+AF8AXw-https://www.firstcitizens.com/internationa... +AFs-firstcitizens+AFs-.+AF0-com+AF0- for more information. Visit us online at https://urldefense.com/v3/+AF8AXw-http://www.firstcitizens.com+AF8AXwA7ACEAI... +AFs-firstcitizens+AFs-.+AF0-com+AF0- or call 1-888-FC DIRECT (1-888-323-4732). First Citizens Bank. Forever First+AK4-. Member FDIC. --------------------------------------------------------------------------------------------------- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- NANOG mailing list https://urldefense.com/v3/+AF8AXw-https://lists.nanog.org/archives/list/nano... +AFs-lists+AFs-.+AF0-nanog+AFs-.+AF0-org+AF0-
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 5:17 PM, Andrew Kirch via NANOG <nanog@lists.nanog.org> wrote: Just think of the savings. Call the finance department and implement jumbo frames everywhere, immediately, and without testing. We can decrease that waste more than 6x! Andrew On Fri, Nov 7, 2025 at 11:15 AM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote: Hence, it is just a wastage of 2% of Internet for nothing. Standard internet MTU = 1500 bytes. IPv4 header is 1.33% of the standard 1500 byte packet size. ( Assuming IHL = 5, so no options, 20B) IPv6 header is 40B, so this becomes 2.67%. ( 1.33% * 2 ) You can of course rant on about how this is 1.33% more "wasted", oh noes! But do you make the same argument to the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing? How many more 1500B packets are "wasted" there? There are lots of reasonable complaints about things related to IPv6. Complaining that the header is "wasting" bits on the wire is absolutely NOT one of them. On Fri, Nov 7, 2025 at 1:19 AM Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote: It depends on what is the benefit for any expense. For example, encryption cost is high, but there is a motivation that many people would accept (and create the pressure on the financial department to tolerate it). For the case of half IPv6 address bits wastage, it was initially "OSI layer violation to put MAC inside IP address just because some IPX politicians have big enough weight" that was later replaces by "randomize IP address to make more difficult to guess it or scan". Number of people who would support this madness would be very small - OTTs have hundreds of ways to de-anonymize users. Hence, it is just a wastage of 2% of Internet for nothing. Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 20:58 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: RE: my finance department cares deeply about 2% fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. On 6 November 2025 18:52:07 CET, nanog--- via NANOG < nanog@lists.nanog.org> wrote: So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine. On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote: Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:12 Vasilenko Eduard wrote: The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] JNGJSN3R252QI7CWBDOTAL37LNQFIH/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] MIDYAXYZMGQJT2VX36DZIEY5XHNYC/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
Hi Tom, You did not read the full thread. 32->64bit address size increase is justified – it is needed anyway. No argue on that point. And yes, it is 2% cost for the whole Internet. Additional 64 bits were wasted not for addressing. Source+Destination – it is 16 bytes wasted for nothing. 16/750=2.13%. 750B is very often reported average packet size. * the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing It is not a good logic: If somebody is doing wrong, then everybody could do wrong too. Eduard From: Tom Beecher <beecher@beecher.cc> Sent: Friday, November 7, 2025 19:10 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: my finance department cares deeply about 2% Hence, it is just a wastage of 2% of Internet for nothing. Standard internet MTU = 1500 bytes. IPv4 header is 1.33% of the standard 1500 byte packet size. ( Assuming IHL = 5, so no options, 20B) IPv6 header is 40B, so this becomes 2.67%. ( 1.33% * 2 ) You can of course rant on about how this is 1.33% more "wasted", oh noes! But do you make the same argument to the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing? How many more 1500B packets are "wasted" there? There are lots of reasonable complaints about things related to IPv6. Complaining that the header is "wasting" bits on the wire is absolutely NOT one of them. On Fri, Nov 7, 2025 at 1:19 AM Vasilenko Eduard via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: It depends on what is the benefit for any expense. For example, encryption cost is high, but there is a motivation that many people would accept (and create the pressure on the financial department to tolerate it). For the case of half IPv6 address bits wastage, it was initially "OSI layer violation to put MAC inside IP address just because some IPX politicians have big enough weight" that was later replaces by "randomize IP address to make more difficult to guess it or scan". Number of people who would support this madness would be very small - OTTs have hundreds of ways to de-anonymize users. Hence, it is just a wastage of 2% of Internet for nothing. Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 20:58 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: nanog@immibis.com<mailto:nanog@immibis.com> Subject: RE: my finance department cares deeply about 2% fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote:
So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine.
On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote:
Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
On 06.11.2025 07:12 Vasilenko Eduard wrote:
The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity.
No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GQ 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3W JNGJSN3R252QI7CWBDOTAL37LNQFIH/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZYN MIDYAXYZMGQJT2VX36DZIEY5XHNYC/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EI7EM7BX... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/P47JM32L...
We can discuss ideal optimisation points, but we cannot reasonably change anything. What we can do, if there is actual desire and realisation of the problem, is to move into IPv6 single stack. No matter how poor IPv6 is, IPv6+IPv4 is worse. So the least bad option on the table is IPv6 only[0] world. But if we keep focusing on how much of youtube is IPv6, we're never going to get to IPv6 single stack, the path to IPv6 single stack isn't of gradual increase of content network IPv6 share. Currently there is absolutely no serious work being done towards ever being IPv6 only. We could also argue that many stakeholders might unintentionally or intentionally want this situation, as they have bought a large amount of IPv4 addresses, which they can a) monetise and b) use to stop competition from entering the market, and these are the same stakeholders who would be most able to force IPv6 only DFZ. [0] long tail is long, surely there will be bunch of edges which are IPv4, but I mean DFZ free IPv4 On Mon, 10 Nov 2025 at 09:40, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
Hi Tom, You did not read the full thread. 32->64bit address size increase is justified – it is needed anyway. No argue on that point. And yes, it is 2% cost for the whole Internet. Additional 64 bits were wasted not for addressing. Source+Destination – it is 16 bytes wasted for nothing. 16/750=2.13%. 750B is very often reported average packet size.
* the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing It is not a good logic: If somebody is doing wrong, then everybody could do wrong too. Eduard From: Tom Beecher <beecher@beecher.cc> Sent: Friday, November 7, 2025 19:10 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: my finance department cares deeply about 2%
Hence, it is just a wastage of 2% of Internet for nothing.
Standard internet MTU = 1500 bytes.
IPv4 header is 1.33% of the standard 1500 byte packet size. ( Assuming IHL = 5, so no options, 20B) IPv6 header is 40B, so this becomes 2.67%. ( 1.33% * 2 )
You can of course rant on about how this is 1.33% more "wasted", oh noes! But do you make the same argument to the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing? How many more 1500B packets are "wasted" there?
There are lots of reasonable complaints about things related to IPv6. Complaining that the header is "wasting" bits on the wire is absolutely NOT one of them.
On Fri, Nov 7, 2025 at 1:19 AM Vasilenko Eduard via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: It depends on what is the benefit for any expense.
For example, encryption cost is high, but there is a motivation that many people would accept (and create the pressure on the financial department to tolerate it).
For the case of half IPv6 address bits wastage, it was initially "OSI layer violation to put MAC inside IP address just because some IPX politicians have big enough weight" that was later replaces by "randomize IP address to make more difficult to guess it or scan". Number of people who would support this madness would be very small - OTTs have hundreds of ways to de-anonymize users. Hence, it is just a wastage of 2% of Internet for nothing. Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 20:58 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: nanog@immibis.com<mailto:nanog@immibis.com> Subject: RE: my finance department cares deeply about 2%
fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6.
On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote:
So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine.
On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote:
Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
On 06.11.2025 07:12 Vasilenko Eduard wrote:
The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity.
No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GQ 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3W JNGJSN3R252QI7CWBDOTAL37LNQFIH/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZYN MIDYAXYZMGQJT2VX36DZIEY5XHNYC/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EI7EM7BX... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/P47JM32L... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CNKQ7DSV...
-- ++ytti
Business could stay IPv4 only. They would probably do because IPv6 is a too big headache. I do not believe dual stack is a big problem because it would be just on the OTT side and Telco. If any business would implement dual stack - it would be there personal problem. Eduard
-----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: Monday, November 10, 2025 10:51 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Tom Beecher <beecher@beecher.cc>; Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: my finance department cares deeply about 2%
We can discuss ideal optimisation points, but we cannot reasonably change anything.
What we can do, if there is actual desire and realisation of the problem, is to move into IPv6 single stack. No matter how poor IPv6 is, IPv6+IPv4 is worse. So the least bad option on the table is IPv6 only[0] world. But if we keep focusing on how much of youtube is IPv6, we're never going to get to IPv6 single stack, the path to IPv6 single stack isn't of gradual increase of content network IPv6 share. Currently there is absolutely no serious work being done towards ever being IPv6 only. We could also argue that many stakeholders might unintentionally or intentionally want this situation, as they have bought a large amount of IPv4 addresses, which they can a) monetise and b) use to stop competition from entering the market, and these are the same stakeholders who would be most able to force IPv6 only DFZ.
[0] long tail is long, surely there will be bunch of edges which are IPv4, but I mean DFZ free IPv4
On Mon, 10 Nov 2025 at 09:40, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
Hi Tom, You did not read the full thread. 32->64bit address size increase is justified – it is needed anyway. No argue
Additional 64 bits were wasted not for addressing. Source+Destination – it is 16 bytes wasted for nothing. 16/750=2.13%. 750B is very often reported average packet size.
* the application developers that pull 1GB of data over the network when
It is not a good logic: If somebody is doing wrong, then everybody could do wrong too. Eduard From: Tom Beecher <beecher@beecher.cc> Sent: Friday, November 7, 2025 19:10 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: my finance department cares deeply about 2%
Hence, it is just a wastage of 2% of Internet for nothing.
Standard internet MTU = 1500 bytes.
IPv4 header is 1.33% of the standard 1500 byte packet size. ( Assuming IHL = 5, so no options, 20B) IPv6 header is 40B, so this becomes 2.67%. ( 1.33% * 2 )
You can of course rant on about how this is 1.33% more "wasted", oh noes! But do you make the same argument to the application developers that pull 1GB of data over the network when they really only need about 200KB for the
on that point. And yes, it is 2% cost for the whole Internet. they really only need about 200KB for the thing they are doing thing they are doing? How many more 1500B packets are "wasted" there?
There are lots of reasonable complaints about things related to IPv6.
Complaining that the header is "wasting" bits on the wire is absolutely NOT one of them.
On Fri, Nov 7, 2025 at 1:19 AM Vasilenko Eduard via NANOG
It depends on what is the benefit for any expense.
For example, encryption cost is high, but there is a motivation that many
<nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: people would accept (and create the pressure on the financial department to tolerate it).
For the case of half IPv6 address bits wastage, it was initially "OSI layer
Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 20:58 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: nanog@immibis.com<mailto:nanog@immibis.com> Subject: RE: my finance department cares deeply about 2%
fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6.
On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote:
So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will
violation to put MAC inside IP address just because some IPX politicians have big enough weight" that was later replaces by "randomize IP address to make more difficult to guess it or scan". Number of people who would support this madness would be very small - OTTs have hundreds of ways to de-anonymize users. Hence, it is just a wastage of 2% of Internet for nothing. thank you. This is asinine.
On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG
<nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote:
Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
On 06.11.2025 07:12 Vasilenko Eduard wrote:
The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity.
No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ GQ 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ 3W JNGJSN3R252QI7CWBDOTAL37LNQFIH/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Z YN MIDYAXYZMGQJT2VX36DZIEY5XHNYC/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EI 7EM7BXCFKDS3WR7HNRLREHECTMUCR7/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/P4 7JM32L2IYAYYSHNGVBRQFWEIMTEFYQ/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CN KQ7DSVH56SSZA53OA5ELOAJCY4DAO2/
-- ++ytti
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 9:57 AM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Business could stay IPv4 only. They would probably do because IPv6 is a too big headache. I do not believe dual stack is a big problem because it would be just on the OTT side and Telco. If any business would implement dual stack - it would be there personal problem. Eduard -----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: Monday, November 10, 2025 10:51 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Tom Beecher <beecher@beecher.cc>; Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: my finance department cares deeply about 2% We can discuss ideal optimisation points, but we cannot reasonably change anything. What we can do, if there is actual desire and realisation of the problem, is to move into IPv6 single stack. No matter how poor IPv6 is, IPv6+IPv4 is worse. So the least bad option on the table is IPv6 only[0] world. But if we keep focusing on how much of youtube is IPv6, we're never going to get to IPv6 single stack, the path to IPv6 single stack isn't of gradual increase of content network IPv6 share. Currently there is absolutely no serious work being done towards ever being IPv6 only. We could also argue that many stakeholders might unintentionally or intentionally want this situation, as they have bought a large amount of IPv4 addresses, which they can a) monetise and b) use to stop competition from entering the market, and these are the same stakeholders who would be most able to force IPv6 only DFZ. [0] long tail is long, surely there will be bunch of edges which are IPv4, but I mean DFZ free IPv4 On Mon, 10 Nov 2025 at 09:40, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Hi Tom, You did not read the full thread. 32->64bit address size increase is justified – it is needed anyway. No argue on that point. And yes, it is 2% cost for the whole Internet. Additional 64 bits were wasted not for addressing. Source+Destination – it is 16 bytes wasted for nothing. 16/750=2.13%. 750B is very often reported average packet size. * the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing It is not a good logic: If somebody is doing wrong, then everybody could do wrong too. Eduard From: Tom Beecher <beecher@beecher.cc> Sent: Friday, November 7, 2025 19:10 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: my finance department cares deeply about 2% Hence, it is just a wastage of 2% of Internet for nothing. Standard internet MTU = 1500 bytes. IPv4 header is 1.33% of the standard 1500 byte packet size. ( Assuming IHL = 5, so no options, 20B) IPv6 header is 40B, so this becomes 2.67%. ( 1.33% * 2 ) You can of course rant on about how this is 1.33% more "wasted", oh noes! But do you make the same argument to the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing? How many more 1500B packets are "wasted" there? There are lots of reasonable complaints about things related to IPv6. Complaining that the header is "wasting" bits on the wire is absolutely NOT one of them. On Fri, Nov 7, 2025 at 1:19 AM Vasilenko Eduard via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: It depends on what is the benefit for any expense. For example, encryption cost is high, but there is a motivation that many people would accept (and create the pressure on the financial department to tolerate it). For the case of half IPv6 address bits wastage, it was initially "OSI layer violation to put MAC inside IP address just because some IPX politicians have big enough weight" that was later replaces by "randomize IP address to make more difficult to guess it or scan". Number of people who would support this madness would be very small - OTTs have hundreds of ways to de-anonymize users. Hence, it is just a wastage of 2% of Internet for nothing. Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 20:58 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: nanog@immibis.com<mailto:nanog@immibis.com> Subject: RE: my finance department cares deeply about 2% fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine. On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:12 Vasilenko Eduard wrote: The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] GQ 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 3W JNGJSN3R252QI7CWBDOTAL37LNQFIH/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] YN MIDYAXYZMGQJT2VX36DZIEY5XHNYC/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 7EM7BXCFKDS3WR7HNRLREHECTMUCR7/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 7JM32L2IYAYYSHNGVBRQFWEIMTEFYQ/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] KQ7DSVH56SSZA53OA5ELOAJCY4DAO2/ -- ++ytti _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:05 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 9:57 AM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Business could stay IPv4 only. They would probably do because IPv6 is a too big headache. I do not believe dual stack is a big problem because it would be just on the OTT side and Telco. If any business would implement dual stack - it would be there personal problem. Eduard -----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: Monday, November 10, 2025 10:51 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Tom Beecher <beecher@beecher.cc>; Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: my finance department cares deeply about 2% We can discuss ideal optimisation points, but we cannot reasonably change anything. What we can do, if there is actual desire and realisation of the problem, is to move into IPv6 single stack. No matter how poor IPv6 is, IPv6+IPv4 is worse. So the least bad option on the table is IPv6 only[0] world. But if we keep focusing on how much of youtube is IPv6, we're never going to get to IPv6 single stack, the path to IPv6 single stack isn't of gradual increase of content network IPv6 share. Currently there is absolutely no serious work being done towards ever being IPv6 only. We could also argue that many stakeholders might unintentionally or intentionally want this situation, as they have bought a large amount of IPv4 addresses, which they can a) monetise and b) use to stop competition from entering the market, and these are the same stakeholders who would be most able to force IPv6 only DFZ. [0] long tail is long, surely there will be bunch of edges which are IPv4, but I mean DFZ free IPv4 On Mon, 10 Nov 2025 at 09:40, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Hi Tom, You did not read the full thread. 32->64bit address size increase is justified – it is needed anyway. No argue on that point. And yes, it is 2% cost for the whole Internet. Additional 64 bits were wasted not for addressing. Source+Destination – it is 16 bytes wasted for nothing. 16/750=2.13%. 750B is very often reported average packet size. * the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing It is not a good logic: If somebody is doing wrong, then everybody could do wrong too. Eduard From: Tom Beecher <beecher@beecher.cc> Sent: Friday, November 7, 2025 19:10 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: my finance department cares deeply about 2% Hence, it is just a wastage of 2% of Internet for nothing. Standard internet MTU = 1500 bytes. IPv4 header is 1.33% of the standard 1500 byte packet size. ( Assuming IHL = 5, so no options, 20B) IPv6 header is 40B, so this becomes 2.67%. ( 1.33% * 2 ) You can of course rant on about how this is 1.33% more "wasted", oh noes! But do you make the same argument to the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing? How many more 1500B packets are "wasted" there? There are lots of reasonable complaints about things related to IPv6. Complaining that the header is "wasting" bits on the wire is absolutely NOT one of them. On Fri, Nov 7, 2025 at 1:19 AM Vasilenko Eduard via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: It depends on what is the benefit for any expense. For example, encryption cost is high, but there is a motivation that many people would accept (and create the pressure on the financial department to tolerate it). For the case of half IPv6 address bits wastage, it was initially "OSI layer violation to put MAC inside IP address just because some IPX politicians have big enough weight" that was later replaces by "randomize IP address to make more difficult to guess it or scan". Number of people who would support this madness would be very small - OTTs have hundreds of ways to de-anonymize users. Hence, it is just a wastage of 2% of Internet for nothing. Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 20:58 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: nanog@immibis.com<mailto:nanog@immibis.com> Subject: RE: my finance department cares deeply about 2% fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine. On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:12 Vasilenko Eduard wrote: The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] GQ 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 3W JNGJSN3R252QI7CWBDOTAL37LNQFIH/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] YN MIDYAXYZMGQJT2VX36DZIEY5XHNYC/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 7EM7BXCFKDS3WR7HNRLREHECTMUCR7/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 7JM32L2IYAYYSHNGVBRQFWEIMTEFYQ/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] KQ7DSVH56SSZA53OA5ELOAJCY4DAO2/ -- ++ytti _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 8:51 AM, Saku Ytti via NANOG <nanog@lists.nanog.org> wrote: We can discuss ideal optimisation points, but we cannot reasonably change anything. What we can do, if there is actual desire and realisation of the problem, is to move into IPv6 single stack. No matter how poor IPv6 is, IPv6+IPv4 is worse. So the least bad option on the table is IPv6 only[0] world. But if we keep focusing on how much of youtube is IPv6, we're never going to get to IPv6 single stack, the path to IPv6 single stack isn't of gradual increase of content network IPv6 share. Currently there is absolutely no serious work being done towards ever being IPv6 only. We could also argue that many stakeholders might unintentionally or intentionally want this situation, as they have bought a large amount of IPv4 addresses, which they can a) monetise and b) use to stop competition from entering the market, and these are the same stakeholders who would be most able to force IPv6 only DFZ. [0] long tail is long, surely there will be bunch of edges which are IPv4, but I mean DFZ free IPv4 On Mon, 10 Nov 2025 at 09:40, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Hi Tom, You did not read the full thread. 32->64bit address size increase is justified – it is needed anyway. No argue on that point. And yes, it is 2% cost for the whole Internet. Additional 64 bits were wasted not for addressing. Source+Destination – it is 16 bytes wasted for nothing. 16/750=2.13%. 750B is very often reported average packet size. * the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing It is not a good logic: If somebody is doing wrong, then everybody could do wrong too. Eduard From: Tom Beecher <beecher@beecher.cc> Sent: Friday, November 7, 2025 19:10 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: my finance department cares deeply about 2% Hence, it is just a wastage of 2% of Internet for nothing. Standard internet MTU = 1500 bytes. IPv4 header is 1.33% of the standard 1500 byte packet size. ( Assuming IHL = 5, so no options, 20B) IPv6 header is 40B, so this becomes 2.67%. ( 1.33% * 2 ) You can of course rant on about how this is 1.33% more "wasted", oh noes! But do you make the same argument to the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing? How many more 1500B packets are "wasted" there? There are lots of reasonable complaints about things related to IPv6. Complaining that the header is "wasting" bits on the wire is absolutely NOT one of them. On Fri, Nov 7, 2025 at 1:19 AM Vasilenko Eduard via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: It depends on what is the benefit for any expense. For example, encryption cost is high, but there is a motivation that many people would accept (and create the pressure on the financial department to tolerate it). For the case of half IPv6 address bits wastage, it was initially "OSI layer violation to put MAC inside IP address just because some IPX politicians have big enough weight" that was later replaces by "randomize IP address to make more difficult to guess it or scan". Number of people who would support this madness would be very small - OTTs have hundreds of ways to de-anonymize users. Hence, it is just a wastage of 2% of Internet for nothing. Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 20:58 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: nanog@immibis.com<mailto:nanog@immibis.com> Subject: RE: my finance department cares deeply about 2% fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine. On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:12 Vasilenko Eduard wrote: The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] JNGJSN3R252QI7CWBDOTAL37LNQFIH/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] MIDYAXYZMGQJT2VX36DZIEY5XHNYC/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] -- ++ytti _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:05 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 8:51 AM, Saku Ytti via NANOG <nanog@lists.nanog.org> wrote: We can discuss ideal optimisation points, but we cannot reasonably change anything. What we can do, if there is actual desire and realisation of the problem, is to move into IPv6 single stack. No matter how poor IPv6 is, IPv6+IPv4 is worse. So the least bad option on the table is IPv6 only[0] world. But if we keep focusing on how much of youtube is IPv6, we're never going to get to IPv6 single stack, the path to IPv6 single stack isn't of gradual increase of content network IPv6 share. Currently there is absolutely no serious work being done towards ever being IPv6 only. We could also argue that many stakeholders might unintentionally or intentionally want this situation, as they have bought a large amount of IPv4 addresses, which they can a) monetise and b) use to stop competition from entering the market, and these are the same stakeholders who would be most able to force IPv6 only DFZ. [0] long tail is long, surely there will be bunch of edges which are IPv4, but I mean DFZ free IPv4 On Mon, 10 Nov 2025 at 09:40, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Hi Tom, You did not read the full thread. 32->64bit address size increase is justified – it is needed anyway. No argue on that point. And yes, it is 2% cost for the whole Internet. Additional 64 bits were wasted not for addressing. Source+Destination – it is 16 bytes wasted for nothing. 16/750=2.13%. 750B is very often reported average packet size. * the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing It is not a good logic: If somebody is doing wrong, then everybody could do wrong too. Eduard From: Tom Beecher <beecher@beecher.cc> Sent: Friday, November 7, 2025 19:10 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: my finance department cares deeply about 2% Hence, it is just a wastage of 2% of Internet for nothing. Standard internet MTU = 1500 bytes. IPv4 header is 1.33% of the standard 1500 byte packet size. ( Assuming IHL = 5, so no options, 20B) IPv6 header is 40B, so this becomes 2.67%. ( 1.33% * 2 ) You can of course rant on about how this is 1.33% more "wasted", oh noes! But do you make the same argument to the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing? How many more 1500B packets are "wasted" there? There are lots of reasonable complaints about things related to IPv6. Complaining that the header is "wasting" bits on the wire is absolutely NOT one of them. On Fri, Nov 7, 2025 at 1:19 AM Vasilenko Eduard via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: It depends on what is the benefit for any expense. For example, encryption cost is high, but there is a motivation that many people would accept (and create the pressure on the financial department to tolerate it). For the case of half IPv6 address bits wastage, it was initially "OSI layer violation to put MAC inside IP address just because some IPX politicians have big enough weight" that was later replaces by "randomize IP address to make more difficult to guess it or scan". Number of people who would support this madness would be very small - OTTs have hundreds of ways to de-anonymize users. Hence, it is just a wastage of 2% of Internet for nothing. Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 20:58 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: nanog@immibis.com<mailto:nanog@immibis.com> Subject: RE: my finance department cares deeply about 2% fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine. On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:12 Vasilenko Eduard wrote: The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] JNGJSN3R252QI7CWBDOTAL37LNQFIH/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] MIDYAXYZMGQJT2VX36DZIEY5XHNYC/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] -- ++ytti _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 8:34 AM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Hi Tom, You did not read the full thread. 32->64bit address size increase is justified – it is needed anyway. No argue on that point. And yes, it is 2% cost for the whole Internet. Additional 64 bits were wasted not for addressing. Source+Destination – it is 16 bytes wasted for nothing. 16/750=2.13%. 750B is very often reported average packet size. * the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing It is not a good logic: If somebody is doing wrong, then everybody could do wrong too. Eduard From: Tom Beecher <beecher@beecher.cc> Sent: Friday, November 7, 2025 19:10 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: my finance department cares deeply about 2% Hence, it is just a wastage of 2% of Internet for nothing. Standard internet MTU = 1500 bytes. IPv4 header is 1.33% of the standard 1500 byte packet size. ( Assuming IHL = 5, so no options, 20B) IPv6 header is 40B, so this becomes 2.67%. ( 1.33% * 2 ) You can of course rant on about how this is 1.33% more "wasted", oh noes! But do you make the same argument to the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing? How many more 1500B packets are "wasted" there? There are lots of reasonable complaints about things related to IPv6. Complaining that the header is "wasting" bits on the wire is absolutely NOT one of them. On Fri, Nov 7, 2025 at 1:19 AM Vasilenko Eduard via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: It depends on what is the benefit for any expense. For example, encryption cost is high, but there is a motivation that many people would accept (and create the pressure on the financial department to tolerate it). For the case of half IPv6 address bits wastage, it was initially "OSI layer violation to put MAC inside IP address just because some IPX politicians have big enough weight" that was later replaces by "randomize IP address to make more difficult to guess it or scan". Number of people who would support this madness would be very small - OTTs have hundreds of ways to de-anonymize users. Hence, it is just a wastage of 2% of Internet for nothing. Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 20:58 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: nanog@immibis.com<mailto:nanog@immibis.com> Subject: RE: my finance department cares deeply about 2% fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine. On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:12 Vasilenko Eduard wrote: The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] JNGJSN3R252QI7CWBDOTAL37LNQFIH/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] MIDYAXYZMGQJT2VX36DZIEY5XHNYC/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:05 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 8:34 AM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Hi Tom, You did not read the full thread. 32->64bit address size increase is justified – it is needed anyway. No argue on that point. And yes, it is 2% cost for the whole Internet. Additional 64 bits were wasted not for addressing. Source+Destination – it is 16 bytes wasted for nothing. 16/750=2.13%. 750B is very often reported average packet size. * the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing It is not a good logic: If somebody is doing wrong, then everybody could do wrong too. Eduard From: Tom Beecher <beecher@beecher.cc> Sent: Friday, November 7, 2025 19:10 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: my finance department cares deeply about 2% Hence, it is just a wastage of 2% of Internet for nothing. Standard internet MTU = 1500 bytes. IPv4 header is 1.33% of the standard 1500 byte packet size. ( Assuming IHL = 5, so no options, 20B) IPv6 header is 40B, so this becomes 2.67%. ( 1.33% * 2 ) You can of course rant on about how this is 1.33% more "wasted", oh noes! But do you make the same argument to the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing? How many more 1500B packets are "wasted" there? There are lots of reasonable complaints about things related to IPv6. Complaining that the header is "wasting" bits on the wire is absolutely NOT one of them. On Fri, Nov 7, 2025 at 1:19 AM Vasilenko Eduard via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: It depends on what is the benefit for any expense. For example, encryption cost is high, but there is a motivation that many people would accept (and create the pressure on the financial department to tolerate it). For the case of half IPv6 address bits wastage, it was initially "OSI layer violation to put MAC inside IP address just because some IPX politicians have big enough weight" that was later replaces by "randomize IP address to make more difficult to guess it or scan". Number of people who would support this madness would be very small - OTTs have hundreds of ways to de-anonymize users. Hence, it is just a wastage of 2% of Internet for nothing. Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 20:58 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: nanog@immibis.com<mailto:nanog@immibis.com> Subject: RE: my finance department cares deeply about 2% fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine. On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Marco Moock <mm@dorfdsl.de<mailto:mm@dorfdsl.de>> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:12 Vasilenko Eduard wrote: The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] JNGJSN3R252QI7CWBDOTAL37LNQFIH/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] MIDYAXYZMGQJT2VX36DZIEY5XHNYC/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 5:10 PM, Tom Beecher via NANOG <nanog@lists.nanog.org> wrote: Hence, it is just a wastage of 2% of Internet for nothing. Standard internet MTU = 1500 bytes. IPv4 header is 1.33% of the standard 1500 byte packet size. ( Assuming IHL = 5, so no options, 20B) IPv6 header is 40B, so this becomes 2.67%. ( 1.33% * 2 ) You can of course rant on about how this is 1.33% more "wasted", oh noes! But do you make the same argument to the application developers that pull 1GB of data over the network when they really only need about 200KB for the thing they are doing? How many more 1500B packets are "wasted" there? There are lots of reasonable complaints about things related to IPv6. Complaining that the header is "wasting" bits on the wire is absolutely NOT one of them. On Fri, Nov 7, 2025 at 1:19 AM Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote: It depends on what is the benefit for any expense. For example, encryption cost is high, but there is a motivation that many people would accept (and create the pressure on the financial department to tolerate it). For the case of half IPv6 address bits wastage, it was initially "OSI layer violation to put MAC inside IP address just because some IPX politicians have big enough weight" that was later replaces by "randomize IP address to make more difficult to guess it or scan". Number of people who would support this madness would be very small - OTTs have hundreds of ways to de-anonymize users. Hence, it is just a wastage of 2% of Internet for nothing. Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 20:58 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: RE: my finance department cares deeply about 2% fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. On 6 November 2025 18:52:07 CET, nanog--- via NANOG <nanog@lists.nanog.org> wrote: So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine. On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote: Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:12 Vasilenko Eduard wrote: The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] JNGJSN3R252QI7CWBDOTAL37LNQFIH/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] MIDYAXYZMGQJT2VX36DZIEY5XHNYC/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
On Thu, 06 Nov 2025 18:58:10 +0100 nanog--- via NANOG <nanog@lists.nanog.org> wrote:
fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6.
NAT is definitely not "computation-hungry" anymore - In many modern stacks there's hardly any penalty for NAT vs not. And by modern I mean "almost anything written after the mid 1990s" "uses less than 98% as much electricity" so it uses 97% as much as ipv4? At 1500 MTU? Does that at all sound right to anyone? "Hey we increased the header so you get reduced data payload, thus taking more packets to do the same work" doesnt really sound like an electrical savings to me.
Am 07.11.2025 um 08:24:35 Uhr schrieb A B via NANOG:
NAT is definitely not "computation-hungry" anymore - In many modern stacks there's hardly any penalty for NAT vs not. And by modern I mean "almost anything written after the mid 1990s"
It is when you have to handle Gigabits of traffic and then thousands of sessions. Certain ISPs with CG-NAT have overloaded routers in prime time. -- Gruß Marco Send unsolicited bulk mail to 1762500275muell@cartoonies.org
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 5:31 PM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: Am 07.11.2025 um 08:24:35 Uhr schrieb A B via NANOG: NAT is definitely not "computation-hungry" anymore - In many modern stacks there's hardly any penalty for NAT vs not. And by modern I mean "almost anything written after the mid 1990s" It is when you have to handle Gigabits of traffic and then thousands of sessions. Certain ISPs with CG-NAT have overloaded routers in prime time. -- Gruß Marco Send unsolicited bulk mail to 1762500275muell@cartoonies.org _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EIJ7RV3C...
On eyeball networks here, we're seeing about 60-70% native IPv6 traffic. Definitely on the services (IE hosted/provided services, not network services) side, It's a mix, but around 50-60%. Mind you, I deal primarily with US facing infrastructure (provider and eyeball) only. In terms of NAT load, that's meant an actual reduction in hardware footprint, via things like edge CPU and RAM usage, etc. Less power, less hardware, less expense - with better throughput overall per amount of hardware, to boot - without having to over-size hardware to compensate. So while I think they meant to say uses more than 2% less, it definitely has been *far more* than 2% savings for us (my org, other orgs I'm involved with, etc), just via NAT reduction. Other simplification benefits for deployment/design have also netted savings. The added benefit of a lot of things just working, and working more reliably, is a bonus, as well. -----Original Message----- From: A B via NANOG <nanog@lists.nanog.org> Sent: Friday, November 7, 2025 11:25 AM To: nanog--- via NANOG <nanog@lists.nanog.org> Cc: A B <ab.nanog@loopw.com> Subject: Re: my finance department cares deeply about 2% On Thu, 06 Nov 2025 18:58:10 +0100 nanog--- via NANOG <nanog@lists.nanog.org> wrote:
fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6.
NAT is definitely not "computation-hungry" anymore - In many modern stacks there's hardly any penalty for NAT vs not. And by modern I mean "almost anything written after the mid 1990s" "uses less than 98% as much electricity" so it uses 97% as much as ipv4? At 1500 MTU? Does that at all sound right to anyone? "Hey we increased the header so you get reduced data payload, thus taking more packets to do the same work" doesnt really sound like an electrical savings to me. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BSXRE26I...
I said what I meant to say. "less than 98% as much" is the same thing as "savings greater than 2%". Perhaps those who call others "internet trolls" should reconsider whether their own behaviour is trolling. In the modern online environment, it is unwise to expose personal information needlessly. I could have used a realistic randomly chosen pseudonym, but I felt it would add no value. Technical content should be evaluated based on its merit, not based on the name attached to it. Though it's regrettable the new mailing list software also makes it hard to see the sender's address. On 7 November 2025 18:53:38 CET, Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote:
On eyeball networks here, we're seeing about 60-70% native IPv6 traffic.
Definitely on the services (IE hosted/provided services, not network services) side, It's a mix, but around 50-60%.
Mind you, I deal primarily with US facing infrastructure (provider and eyeball) only.
In terms of NAT load, that's meant an actual reduction in hardware footprint, via things like edge CPU and RAM usage, etc.
Less power, less hardware, less expense - with better throughput overall per amount of hardware, to boot - without having to over-size hardware to compensate.
So while I think they meant to say uses more than 2% less, it definitely has been *far more* than 2% savings for us (my org, other orgs I'm involved with, etc), just via NAT reduction. Other simplification benefits for deployment/design have also netted savings.
The added benefit of a lot of things just working, and working more reliably, is a bonus, as well.
-----Original Message----- From: A B via NANOG <nanog@lists.nanog.org> Sent: Friday, November 7, 2025 11:25 AM To: nanog--- via NANOG <nanog@lists.nanog.org> Cc: A B <ab.nanog@loopw.com> Subject: Re: my finance department cares deeply about 2%
On Thu, 06 Nov 2025 18:58:10 +0100 nanog--- via NANOG <nanog@lists.nanog.org> wrote:
fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6.
NAT is definitely not "computation-hungry" anymore - In many modern stacks there's hardly any penalty for NAT vs not. And by modern I mean "almost anything written after the mid 1990s"
"uses less than 98% as much electricity" so it uses 97% as much as ipv4? At 1500 MTU? Does that at all sound right to anyone? "Hey we increased the header so you get reduced data payload, thus taking more packets to do the same work" doesnt really sound like an electrical savings to me.
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BSXRE26I... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HBDDZZPC...
On Sat, Nov 8, 2025 at 5:27 AM nanog--- via NANOG <nanog@lists.nanog.org> wrote:
Perhaps those who call others "internet trolls" should reconsider whether their own behaviour is trolling. In the modern online environment, it is unwise to expose personal information needlessly.
I vaguely recall a rule on the mailing list, lightly enforced, that participants were expected to use their own real names. I believe the grounds for it was that this is a professional forum intended to facilitate discussion between professionals. Not some hackernet on the dark web. Did the policy change at some point or am I misremembering it entirely? Regards, Bill Herrin
I vaguely recall a rule on the mailing list, lightly enforced, that participants were expected to use their own real names. I believe the grounds for it was that this is a professional forum intended to facilitate discussion between professionals. Not some hackernet on the dark web.
There is no such rule today, nor has there ever been one that I can ever remember. On Sat, Nov 8, 2025 at 1:50 PM William Herrin via NANOG < nanog@lists.nanog.org> wrote:
On Sat, Nov 8, 2025 at 5:27 AM nanog--- via NANOG <nanog@lists.nanog.org> wrote:
Perhaps those who call others "internet trolls" should reconsider whether their own behaviour is trolling. In the modern online environment, it is unwise to expose personal information needlessly.
I vaguely recall a rule on the mailing list, lightly enforced, that participants were expected to use their own real names. I believe the grounds for it was that this is a professional forum intended to facilitate discussion between professionals. Not some hackernet on the dark web.
Did the policy change at some point or am I misremembering it entirely?
Regards, Bill Herrin _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ASWZTY3T...
On Sat, Nov 8, 2025 at 1:00 PM Tom Beecher <beecher@beecher.cc> wrote:
I vaguely recall a rule on the mailing list, lightly enforced, that participants were expected to use their own real names. I believe the grounds for it was that this is a professional forum intended to facilitate discussion between professionals.
There is no such rule today, nor has there ever been one that I can ever remember.
Hi Tom, Then I must be thinking of a different mailing list. Nevertheless, while I agree that the words should matter more than the speaker, I think there's a degree of professionalism missing from anonymized messages and that matters too. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
I had the same recollection. https://web.archive.org/web/20021209101350/https://nanog.org/listfaq.html Sent from my iPhone
On Nov 8, 2025, at 4:49 PM, William Herrin via NANOG <nanog@lists.nanog.org> wrote:
On Sat, Nov 8, 2025 at 1:00 PM Tom Beecher <beecher@beecher.cc> wrote:
I vaguely recall a rule on the mailing list, lightly enforced, that participants were expected to use their own real names. I believe the grounds for it was that this is a professional forum intended to facilitate discussion between professionals.
There is no such rule today, nor has there ever been one that I can ever remember.
Hi Tom,
Then I must be thinking of a different mailing list.
Nevertheless, while I agree that the words should matter more than the speaker, I think there's a degree of professionalism missing from anonymized messages and that matters too.
Regards, Bill Herrin
-- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YW6HGIXA...
On Sat, Nov 8, 2025 at 2:15 PM Jon Lewis <jlewis@lewis.org> wrote:
I had the same recollection. https://web.archive.org/web/20021209101350/https://nanog.org/listfaq.html
Okay, my memory didn't fail me after all. This time anyway. It was this list. Acceptable Use Policy 6. Postings must be made using real, identifiable names and addresses, rather than aliases. The current AUP seems mute on the matter: https://nanog.org/resources/usage-guidelines/ So, question for the mail admins: was the expectation of real names intentionally removed at some point? When? Why? What should we consider to be the current guidance? Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 9, 2025, at 1:49 AM, William Herrin via NANOG <nanog@lists.nanog.org> wrote: On Sat, Nov 8, 2025 at 2:15 PM Jon Lewis <jlewis@lewis.org> wrote: I had the same recollection. https://urldefense.com/v3/__https://web.archive.org/web/20021209101350/https... [web[.]archive[.]org] Okay, my memory didn't fail me after all. This time anyway. It was this list. Acceptable Use Policy 6. Postings must be made using real, identifiable names and addresses, rather than aliases. The current AUP seems mute on the matter: https://urldefense.com/v3/__https://nanog.org/resources/usage-guidelines/__;... [nanog[.]org] So, question for the mail admins: was the expectation of real names intentionally removed at some point? When? Why? What should we consider to be the current guidance? Regards, Bill Herrin -- For hire. https://urldefense.com/v3/__https://bill.herrin.us/resume/__;!!PtGJab4!7EgpN... [bill[.]herrin[.]us] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 9, 2025, at 1:49 AM, William Herrin via NANOG <nanog@lists.nanog.org> wrote: On Sat, Nov 8, 2025 at 2:15 PM Jon Lewis <jlewis@lewis.org> wrote: I had the same recollection. https://urldefense.com/v3/__https://web.archive.org/web/20021209101350/https... [web[.]archive[.]org] Okay, my memory didn't fail me after all. This time anyway. It was this list. Acceptable Use Policy 6. Postings must be made using real, identifiable names and addresses, rather than aliases. The current AUP seems mute on the matter: https://urldefense.com/v3/__https://nanog.org/resources/usage-guidelines/__;... [nanog[.]org] So, question for the mail admins: was the expectation of real names intentionally removed at some point? When? Why? What should we consider to be the current guidance? Regards, Bill Herrin -- For hire. https://urldefense.com/v3/__https://bill.herrin.us/resume/__;!!PtGJab4!7EgpN... [bill[.]herrin[.]us] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
What should we consider to be the current guidance?
You linked to the currently published mailing list guidelines, therefore you have already answered your own question. There is no current requirement for real names to be used on the mailing list. I do not believe that there should be a requirement reinstated for 'real names' to be used on the mailing list. We have had multiple decades of practical education and experience that such requirements are effectively unenforceable on open mailing lists. To actually do this, NANOG would need to spend some amount of staff time / effort / $$ to setup systems for identification (which could potentially have GDPR/CCPA bits to worry about ), along with enforcement. This is a lot of time / people / $$ costs to incur. The only benefit to this effort/expense would be that someone who gets into an internet argument can address someone with their real name when they rage reply. So yeah, I think it's just fine as it is. On Sat, Nov 8, 2025 at 7:49 PM William Herrin <bill@herrin.us> wrote:
On Sat, Nov 8, 2025 at 2:15 PM Jon Lewis <jlewis@lewis.org> wrote:
I had the same recollection.
https://web.archive.org/web/20021209101350/https://nanog.org/listfaq.html
Okay, my memory didn't fail me after all. This time anyway. It was this list.
Acceptable Use Policy 6. Postings must be made using real, identifiable names and addresses, rather than aliases.
The current AUP seems mute on the matter: https://nanog.org/resources/usage-guidelines/
So, question for the mail admins: was the expectation of real names intentionally removed at some point? When? Why? What should we consider to be the current guidance?
Regards, Bill Herrin
-- For hire. https://bill.herrin.us/resume/
On Mon, Nov 10, 2025 at 6:16 AM Tom Beecher <beecher@beecher.cc> wrote:
What should we consider to be the current guidance?
You linked to the currently published mailing list guidelines, therefore you have already answered your own question. There is no current requirement for real names to be used on the mailing list.
You're on the NANOG Moderation Committee? No? Maybe let someone who is think about it and offer an answer. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Bill, Tom is not on the Moderation Committee. This topic has been discussed before and arrived at the same conclusion that Tom did. ----- Providing an update to the loop issue: The subscribers email address delivery status was disabled, and email address banned temporarily, till they are able to update their autoresponder. The postfix queued messages containing their email address was also flushed out. I cannot stop the emails that are already sent out. I apologize for this happening as long as it did, this started happening around 4:30AM pacific this morning while I was sleeping. Ryan ________________________________ From: William Herrin via NANOG <nanog@lists.nanog.org> Sent: Monday, November 10, 2025 6:34 AM To: Tom Beecher <beecher@beecher.cc> Cc: admins@nanog.org <admins@nanog.org>; nanog@lists.nanog.org <nanog@lists.nanog.org>; William Herrin <bill@herrin.us> Subject: Re: trolling Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. On Mon, Nov 10, 2025 at 6:16 AM Tom Beecher <beecher@beecher.cc> wrote:
What should we consider to be the current guidance?
You linked to the currently published mailing list guidelines, therefore you have already answered your own question. There is no current requirement for real names to be used on the mailing list.
You're on the NANOG Moderation Committee? No? Maybe let someone who is think about it and offer an answer. Regards, Bill Herrin -- For hire. https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbill.herrin.us%2Fresume%2F&data=05%7C02%7Cryan%40rkhtech.org%7Ca6bdaac18aba421650f008de206a4e8b%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638983838145904629%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=LJlC06OkerJR6ZKU%2FlItgmfaJTMDBL9kQ1Ic1Q7NnyI%3D&reserved=0<https://bill.herrin.us/resume/> _______________________________________________ NANOG mailing list https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2FQMRNDCA53YKNTB2CBCSYH5MSGAGTYFXJ%2F&data=05%7C02%7Cryan%40rkhtech.org%7Ca6bdaac18aba421650f008de206a4e8b%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638983838145947401%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=QA%2FwVmxBhLVbrdlXLfGcyh5ifFJR44Si44iqqBqB7gk%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QMRNDCA53YKNTB2CBCSYH5MSGAGTYFXJ/>
Bill- My committee affiliations are not relevant. That being said if I am ever responding on behalf of one of my committee roles I always make that very clear. The information in question is publicly available on the NANOG website. In fact, you found the link yourself. Any plain reading of that webpage answered your direct question as to what the current guidance is. On Mon, Nov 10, 2025 at 9:34 AM William Herrin <bill@herrin.us> wrote:
On Mon, Nov 10, 2025 at 6:16 AM Tom Beecher <beecher@beecher.cc> wrote:
What should we consider to be the current guidance?
You linked to the currently published mailing list guidelines, therefore you have already answered your own question. There is no current requirement for real names to be used on the mailing list.
You're on the NANOG Moderation Committee? No? Maybe let someone who is think about it and offer an answer.
Regards, Bill Herrin
-- For hire. https://bill.herrin.us/resume/
I'd be curious if anyone knows why the requirement was removed? Who thought that was a necessary and good thing? On Mon, Nov 10, 2025 at 8:42 AM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
Bill-
My committee affiliations are not relevant. That being said if I am ever responding on behalf of one of my committee roles I always make that very clear.
The information in question is publicly available on the NANOG website. In fact, you found the link yourself. Any plain reading of that webpage answered your direct question as to what the current guidance is.
On Mon, Nov 10, 2025 at 9:34 AM William Herrin <bill@herrin.us> wrote:
What should we consider to be the current guidance?
You linked to the currently published mailing list guidelines,
On Mon, Nov 10, 2025 at 6:16 AM Tom Beecher <beecher@beecher.cc> wrote: therefore
you have already answered your own question. There is no current requirement for real names to be used on the mailing list.
You're on the NANOG Moderation Committee? No? Maybe let someone who is think about it and offer an answer.
Regards, Bill Herrin
-- For hire. https://bill.herrin.us/resume/
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RWUBHGVR...
I mean, the reference to its previous existence was from 23 years ago. A lot has changed since 2002. I'm not totally sure the archeology is really worth it on this one, especially for a non-binding guideline. On Mon, Nov 10, 2025 at 10:44 AM Dorn Hetzel <dorn@hetzel.org> wrote:
I'd be curious if anyone knows why the requirement was removed? Who thought that was a necessary and good thing?
On Mon, Nov 10, 2025 at 8:42 AM Tom Beecher via NANOG < nanog@lists.nanog.org> wrote:
Bill-
My committee affiliations are not relevant. That being said if I am ever responding on behalf of one of my committee roles I always make that very clear.
The information in question is publicly available on the NANOG website. In fact, you found the link yourself. Any plain reading of that webpage answered your direct question as to what the current guidance is.
On Mon, Nov 10, 2025 at 9:34 AM William Herrin <bill@herrin.us> wrote:
What should we consider to be the current guidance?
You linked to the currently published mailing list guidelines,
On Mon, Nov 10, 2025 at 6:16 AM Tom Beecher <beecher@beecher.cc> wrote: therefore
you have already answered your own question. There is no current requirement for real names to be used on the mailing list.
You're on the NANOG Moderation Committee? No? Maybe let someone who is think about it and offer an answer.
Regards, Bill Herrin
-- For hire. https://bill.herrin.us/resume/
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RWUBHGVR...
Still, it didn't change itself, I don't expect. Some person or persons made that choice at some point in time, and it doesn't seem unreasonable to wonder who and more importantly *why*. What good is served by it? On Mon, Nov 10, 2025, 08:49 Tom Beecher <beecher@beecher.cc> wrote:
I mean, the reference to its previous existence was from 23 years ago. A lot has changed since 2002. I'm not totally sure the archeology is really worth it on this one, especially for a non-binding guideline.
On Mon, Nov 10, 2025 at 10:44 AM Dorn Hetzel <dorn@hetzel.org> wrote:
I'd be curious if anyone knows why the requirement was removed? Who thought that was a necessary and good thing?
On Mon, Nov 10, 2025 at 8:42 AM Tom Beecher via NANOG < nanog@lists.nanog.org> wrote:
Bill-
My committee affiliations are not relevant. That being said if I am ever responding on behalf of one of my committee roles I always make that very clear.
The information in question is publicly available on the NANOG website. In fact, you found the link yourself. Any plain reading of that webpage answered your direct question as to what the current guidance is.
On Mon, Nov 10, 2025 at 9:34 AM William Herrin <bill@herrin.us> wrote:
What should we consider to be the current guidance?
You linked to the currently published mailing list guidelines,
On Mon, Nov 10, 2025 at 6:16 AM Tom Beecher <beecher@beecher.cc> wrote: therefore
you have already answered your own question. There is no current requirement for real names to be used on the mailing list.
You're on the NANOG Moderation Committee? No? Maybe let someone who is think about it and offer an answer.
Regards, Bill Herrin
-- For hire. https://bill.herrin.us/resume/
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RWUBHGVR...
The last reference of the 'Real , identifiable names and addresses" bullet point from the wayback machine was Mar 21, 2008. https://web.archive.org/web/20080321012008/http://nanog.org/listfaq.html The next wayback machine update is April 20, 2008, with a page last update of April 17, 2008. https://web.archive.org/web/20080420085040/http://nanog.org/listfaq.html Quoting the Credits section : The editors of this FAQ include Etaoin Shrdlu, Rachel K. Warren, JC Dill,
Joe Abley, Richard Steenbergen, Marty Hannigan, Gwendolynn Ferch Elydyr, Barry Raveendren Greene, Joe Provo, John Payne, Ginna Musgrove, Doug Clements, and Susan Harris. FAQ contributions are welcome -- please send email to nanog-support@nanog.org <https://web.archive.org/web/20080420085040/mailto:nanog-support@nanog.org> .
Quoting the About section : The NANOG Mail List Committee (MLC)comprises of six community volunteers:
David Barak, Martin Hannigan, Sue Joiner, Aleksandr Pilosov, Brett Watson and Tim Yocum. Aleksandr Pilosov is our Chair. You can reach us at admins@nanog.org <https://web.archive.org/web/20080420085040/mailto:admins@nanog.org>.
If someone cares enough to reach out to any of these folks and ask them why they made the decision 17 years ago, there you go. On Mon, Nov 10, 2025 at 10:52 AM Dorn Hetzel <dorn@hetzel.org> wrote:
Still, it didn't change itself, I don't expect. Some person or persons made that choice at some point in time, and it doesn't seem unreasonable to wonder who and more importantly *why*. What good is served by it?
On Mon, Nov 10, 2025, 08:49 Tom Beecher <beecher@beecher.cc> wrote:
I mean, the reference to its previous existence was from 23 years ago. A lot has changed since 2002. I'm not totally sure the archeology is really worth it on this one, especially for a non-binding guideline.
On Mon, Nov 10, 2025 at 10:44 AM Dorn Hetzel <dorn@hetzel.org> wrote:
I'd be curious if anyone knows why the requirement was removed? Who thought that was a necessary and good thing?
On Mon, Nov 10, 2025 at 8:42 AM Tom Beecher via NANOG < nanog@lists.nanog.org> wrote:
Bill-
My committee affiliations are not relevant. That being said if I am ever responding on behalf of one of my committee roles I always make that very clear.
The information in question is publicly available on the NANOG website. In fact, you found the link yourself. Any plain reading of that webpage answered your direct question as to what the current guidance is.
On Mon, Nov 10, 2025 at 9:34 AM William Herrin <bill@herrin.us> wrote:
> What should we > consider to be the current guidance?
You linked to the currently published mailing list guidelines,
On Mon, Nov 10, 2025 at 6:16 AM Tom Beecher <beecher@beecher.cc> wrote: therefore
you have already answered your own question. There is no current requirement for real names to be used on the mailing list.
You're on the NANOG Moderation Committee? No? Maybe let someone who is think about it and offer an answer.
Regards, Bill Herrin
-- For hire. https://bill.herrin.us/resume/
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RWUBHGVR...
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 8, 2025, at 11:15 PM, Jon Lewis via NANOG <nanog@lists.nanog.org> wrote: I had the same recollection. https://urldefense.com/v3/__https://web.archive.org/web/20021209101350/https... [web[.]archive[.]org] Sent from my iPhone On Nov 8, 2025, at 4:49 PM, William Herrin via NANOG <nanog@lists.nanog.org> wrote: On Sat, Nov 8, 2025 at 1:00 PM Tom Beecher <beecher@beecher.cc> wrote: I vaguely recall a rule on the mailing list, lightly enforced, that participants were expected to use their own real names. I believe the grounds for it was that this is a professional forum intended to facilitate discussion between professionals. There is no such rule today, nor has there ever been one that I can ever remember. Hi Tom, Then I must be thinking of a different mailing list. Nevertheless, while I agree that the words should matter more than the speaker, I think there's a degree of professionalism missing from anonymized messages and that matters too. Regards, Bill Herrin -- For hire. https://urldefense.com/v3/__https://bill.herrin.us/resume/__;!!PtGJab4!7jrOD... [bill[.]herrin[.]us] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 8, 2025, at 11:15 PM, Jon Lewis via NANOG <nanog@lists.nanog.org> wrote: I had the same recollection. https://urldefense.com/v3/__https://web.archive.org/web/20021209101350/https... [web[.]archive[.]org] Sent from my iPhone On Nov 8, 2025, at 4:49 PM, William Herrin via NANOG <nanog@lists.nanog.org> wrote: On Sat, Nov 8, 2025 at 1:00 PM Tom Beecher <beecher@beecher.cc> wrote: I vaguely recall a rule on the mailing list, lightly enforced, that participants were expected to use their own real names. I believe the grounds for it was that this is a professional forum intended to facilitate discussion between professionals. There is no such rule today, nor has there ever been one that I can ever remember. Hi Tom, Then I must be thinking of a different mailing list. Nevertheless, while I agree that the words should matter more than the speaker, I think there's a degree of professionalism missing from anonymized messages and that matters too. Regards, Bill Herrin -- For hire. https://urldefense.com/v3/__https://bill.herrin.us/resume/__;!!PtGJab4!7jrOD... [bill[.]herrin[.]us] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 8, 2025, at 10:49 PM, William Herrin via NANOG <nanog@lists.nanog.org> wrote: On Sat, Nov 8, 2025 at 1:00 PM Tom Beecher <beecher@beecher.cc> wrote: I vaguely recall a rule on the mailing list, lightly enforced, that participants were expected to use their own real names. I believe the grounds for it was that this is a professional forum intended to facilitate discussion between professionals. There is no such rule today, nor has there ever been one that I can ever remember. Hi Tom, Then I must be thinking of a different mailing list. Nevertheless, while I agree that the words should matter more than the speaker, I think there's a degree of professionalism missing from anonymized messages and that matters too. Regards, Bill Herrin -- For hire. https://urldefense.com/v3/__https://bill.herrin.us/resume/__;!!PtGJab4!4eUyT... [bill[.]herrin[.]us] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 8, 2025, at 10:49 PM, William Herrin via NANOG <nanog@lists.nanog.org> wrote: On Sat, Nov 8, 2025 at 1:00 PM Tom Beecher <beecher@beecher.cc> wrote: I vaguely recall a rule on the mailing list, lightly enforced, that participants were expected to use their own real names. I believe the grounds for it was that this is a professional forum intended to facilitate discussion between professionals. There is no such rule today, nor has there ever been one that I can ever remember. Hi Tom, Then I must be thinking of a different mailing list. Nevertheless, while I agree that the words should matter more than the speaker, I think there's a degree of professionalism missing from anonymized messages and that matters too. Regards, Bill Herrin -- For hire. https://urldefense.com/v3/__https://bill.herrin.us/resume/__;!!PtGJab4!4eUyT... [bill[.]herrin[.]us] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 8, 2025, at 10:00 PM, Tom Beecher via NANOG <nanog@lists.nanog.org> wrote: I vaguely recall a rule on the mailing list, lightly enforced, that participants were expected to use their own real names. I believe the grounds for it was that this is a professional forum intended to facilitate discussion between professionals. Not some hackernet on the dark web. There is no such rule today, nor has there ever been one that I can ever remember. On Sat, Nov 8, 2025 at 1:50 PM William Herrin via NANOG < nanog@lists.nanog.org> wrote: On Sat, Nov 8, 2025 at 5:27 AM nanog--- via NANOG <nanog@lists.nanog.org> wrote: Perhaps those who call others "internet trolls" should reconsider whether their own behaviour is trolling. In the modern online environment, it is unwise to expose personal information needlessly. I vaguely recall a rule on the mailing list, lightly enforced, that participants were expected to use their own real names. I believe the grounds for it was that this is a professional forum intended to facilitate discussion between professionals. Not some hackernet on the dark web. Did the policy change at some point or am I misremembering it entirely? Regards, Bill Herrin _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 8, 2025, at 10:00 PM, Tom Beecher via NANOG <nanog@lists.nanog.org> wrote: I vaguely recall a rule on the mailing list, lightly enforced, that participants were expected to use their own real names. I believe the grounds for it was that this is a professional forum intended to facilitate discussion between professionals. Not some hackernet on the dark web. There is no such rule today, nor has there ever been one that I can ever remember. On Sat, Nov 8, 2025 at 1:50 PM William Herrin via NANOG < nanog@lists.nanog.org> wrote: On Sat, Nov 8, 2025 at 5:27 AM nanog--- via NANOG <nanog@lists.nanog.org> wrote: Perhaps those who call others "internet trolls" should reconsider whether their own behaviour is trolling. In the modern online environment, it is unwise to expose personal information needlessly. I vaguely recall a rule on the mailing list, lightly enforced, that participants were expected to use their own real names. I believe the grounds for it was that this is a professional forum intended to facilitate discussion between professionals. Not some hackernet on the dark web. Did the policy change at some point or am I misremembering it entirely? Regards, Bill Herrin _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 8, 2025, at 7:50 PM, William Herrin via NANOG <nanog@lists.nanog.org> wrote: On Sat, Nov 8, 2025 at 5:27 AM nanog--- via NANOG <nanog@lists.nanog.org> wrote: Perhaps those who call others "internet trolls" should reconsider whether their own behaviour is trolling. In the modern online environment, it is unwise to expose personal information needlessly. I vaguely recall a rule on the mailing list, lightly enforced, that participants were expected to use their own real names. I believe the grounds for it was that this is a professional forum intended to facilitate discussion between professionals. Not some hackernet on the dark web. Did the policy change at some point or am I misremembering it entirely? Regards, Bill Herrin _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I think he wants us to know that he is OOO and won't check emails :) Le lun. 10 nov. 2025 à 15:44, Endre Szabo via NANOG <nanog@lists.nanog.org> a écrit :
Oh boy, this is going to be a long week without Samaneh.
On Mon, Nov 10, 2025 at 12:06:20+0000, Samaneh Tajalizadehkhoob via NANOG wrote:
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ND34P657...
Kinda funny someone in charge of "Security, Stability and Resiliency Research" for ICANN, didn't have the forethought to realize setting an autoresponder on an address subscribed to mailing lists is an extremely bad idea. Much secure, much stable, many unchecked emails. Wonder how long until an admin at ICANN fixes this Monday AM flood. Regards, Andrew Paolucci Sent with Proton Mail secure email. On Monday, November 10th, 2025 at 9:44 AM, Endre Szabo via NANOG <nanog@lists.nanog.org> wrote:
Oh boy, this is going to be a long week without Samaneh.
On Mon, Nov 10, 2025 at 12:06:20+0000, Samaneh Tajalizadehkhoob via NANOG wrote:
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ND34P657...
Kinda funny someone in charge of "Security, Stability and Resiliency Research" for ICANN, didn't have the forethought to realize setting an autoresponder on an address subscribed to mailing lists is an extremely bad idea.
Don’t get personal, it never reflects particularly well. Many UIs don’t allow users of an email system to configure a selective auto-reply, so you don’t know whether the person didn’t think about it at all or was prevented from applying an appropriate solution due to technical limitations.
Wonder how long until an admin at ICANN fixes this Monday AM flood.
Also, speaking about technical limitations - which mailserver in the world does send one auto-reply PER MESSAGE to the same sender? I haven’t seen this in ages, most seem to be sending only once or at worst once every day or so. Giorgio
I wonder about people subscribing their main personal or business email address to mailing lists. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Giorgio Bonfiglio via NANOG" <nanog@lists.nanog.org> To: "North American Network Operators Group" <nanog@lists.nanog.org> Cc: "Giorgio Bonfiglio" <me@grg.pw> Sent: Monday, November 10, 2025 9:14:26 AM Subject: Re: [Ext] trolling
Kinda funny someone in charge of "Security, Stability and Resiliency Research" for ICANN, didn't have the forethought to realize setting an autoresponder on an address subscribed to mailing lists is an extremely bad idea.
Don’t get personal, it never reflects particularly well. Many UIs don’t allow users of an email system to configure a selective auto-reply, so you don’t know whether the person didn’t think about it at all or was prevented from applying an appropriate solution due to technical limitations.
Wonder how long until an admin at ICANN fixes this Monday AM flood.
Also, speaking about technical limitations - which mailserver in the world does send one auto-reply PER MESSAGE to the same sender? I haven’t seen this in ages, most seem to be sending only once or at worst once every day or so. Giorgio _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/542HFJXB...
On 10/11/2025 17:14, Giorgio Bonfiglio via NANOG wrote:
Also, speaking about technical limitations - which mailserver in the world does send one auto-reply PER MESSAGE to the same sender? I haven’t seen this in ages, most seem to be sending only once or at worst once every day or so.
That indeed is the question. Perhaps ICANN needs to reexamine this area? Regards, Hank
On Mon, Nov 10, 2025 at 15:14:26+0000, Giorgio Bonfiglio via NANOG wrote:
Also, speaking about technical limitations - which mailserver in the world does send one auto-reply PER MESSAGE to the same sender? I haven’t seen this in ages, most seem to be sending only once or at worst once every day or so.
Oh, I know the answer to this one! It's a niche player in the market, and it's well known for not following standards or best practices. Like, they could have ignored messages with List-* headers, for example, right? The server in question is called Microsoft Exchange.
Endre, Exchange only sends one reply to each sender (https://learn.microsoft.com/en-us/troubleshoot/exchange/client-connectivity/...), and it's also configurable too (https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/under...). Ryan Hamel ________________________________ From: Endre Szabo via NANOG <nanog@lists.nanog.org> Sent: Monday, November 10, 2025 10:50 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Endre Szabo <endre.szabo@nanog-list-sfegrr.redir.email> Subject: Re: [Ext] trolling Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. On Mon, Nov 10, 2025 at 15:14:26+0000, Giorgio Bonfiglio via NANOG wrote:
Also, speaking about technical limitations - which mailserver in the world does send one auto-reply PER MESSAGE to the same sender? I haven’t seen this in ages, most seem to be sending only once or at worst once every day or so.
Oh, I know the answer to this one! It's a niche player in the market, and it's well known for not following standards or best practices. Like, they could have ignored messages with List-* headers, for example, right? The server in question is called Microsoft Exchange. _______________________________________________ NANOG mailing list https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2FBUZSGS4UJJTCCBMVNGCFM7UDKQSDQTDA%2F&data=05%7C02%7Cryan%40rkhtech.org%7C264e6deb8b38433e14b908de20eea624%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638984406549222502%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qLAd5BzYaaHxVcKz7oQhVd%2BzuDn49FbCu8Q4RRHhZrw%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BUZSGS4UJJTCCBMVNGCFM7UDKQSDQTDA/>
Can confirm on that one, Exchange / Outlook are the ones that play extremely well in this scenario. Microsoft learned these lessons very early on.... One hilarious example was internal to them in 1997, for instance (not the same type of problem, but still one of many things that they learned well early in exchange's life). For all MS's faults, Exchange really is a damn good product at the end of the day if it's set up per documentation (ie: not a single server) and you actually use any of its functionality. It's the most set-it-and-forget-it and self-healing system outside of normal patching I've ever had to deal with at scale (largest of 70k users, smallest of 100 users). -----Original Message----- From: Ryan Hamel via NANOG <nanog@lists.nanog.org> Sent: Tuesday, November 11, 2025 2:16 AM To: nanog@lists.nanog.org Cc: Ryan Hamel <ryan@rkhtech.org> Subject: Re: [Ext] trolling Endre, Exchange only sends one reply to each sender (https://learn.microsoft.com/en-us/troubleshoot/exchange/client-connectivity/...), and it's also configurable too (https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/under...). Ryan Hamel ________________________________ From: Endre Szabo via NANOG <nanog@lists.nanog.org> Sent: Monday, November 10, 2025 10:50 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Endre Szabo <endre.szabo@nanog-list-sfegrr.redir.email> Subject: Re: [Ext] trolling Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. On Mon, Nov 10, 2025 at 15:14:26+0000, Giorgio Bonfiglio via NANOG wrote:
Also, speaking about technical limitations - which mailserver in the world does send one auto-reply PER MESSAGE to the same sender? I haven't seen this in ages, most seem to be sending only once or at worst once every day or so.
Oh, I know the answer to this one! It's a niche player in the market, and it's well known for not following standards or best practices. Like, they could have ignored messages with List-* headers, for example, right? The server in question is called Microsoft Exchange. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BUZSGS4UJJTCCBMVNGCFM7UDKQSDQTDA/<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BUZSGS4UJJTCCBMVNGCFM7UDKQSDQTDA/> _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BRXFVZBO...
agree Gary. There's a reason my day job moved their 280k+ employees (plus countless non-human mailboxes) from Lotus Notes to Microsoft. It's been working much, much better since the move. On Tue, Nov 11, 2025 at 9:35 AM Gary Sparkes via NANOG < nanog@lists.nanog.org> wrote:
Can confirm on that one, Exchange / Outlook are the ones that play extremely well in this scenario. Microsoft learned these lessons very early on.... One hilarious example was internal to them in 1997, for instance (not the same type of problem, but still one of many things that they learned well early in exchange's life).
For all MS's faults, Exchange really is a damn good product at the end of the day if it's set up per documentation (ie: not a single server) and you actually use any of its functionality. It's the most set-it-and-forget-it and self-healing system outside of normal patching I've ever had to deal with at scale (largest of 70k users, smallest of 100 users).
-----Original Message----- From: Ryan Hamel via NANOG <nanog@lists.nanog.org> Sent: Tuesday, November 11, 2025 2:16 AM To: nanog@lists.nanog.org Cc: Ryan Hamel <ryan@rkhtech.org> Subject: Re: [Ext] trolling
Endre,
Exchange only sends one reply to each sender ( https://learn.microsoft.com/en-us/troubleshoot/exchange/client-connectivity/...), and it's also configurable too ( https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/under... ).
Ryan Hamel
________________________________ From: Endre Szabo via NANOG <nanog@lists.nanog.org> Sent: Monday, November 10, 2025 10:50 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Endre Szabo <endre.szabo@nanog-list-sfegrr.redir.email> Subject: Re: [Ext] trolling
Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments.
On Mon, Nov 10, 2025 at 15:14:26+0000, Giorgio Bonfiglio via NANOG wrote:
Also, speaking about technical limitations - which mailserver in the world does send one auto-reply PER MESSAGE to the same sender? I haven't seen this in ages, most seem to be sending only once or at worst once every day or so.
Oh, I know the answer to this one! It's a niche player in the market, and it's well known for not following standards or best practices. Like, they could have ignored messages with List-* headers, for example, right? The server in question is called Microsoft Exchange.
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BUZSGS4U... < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BUZSGS4U...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BRXFVZBO... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QULMBW6O...
On Tue, Nov 11, 2025 at 7:35 AM Gary Sparkes via NANOG < nanog@lists.nanog.org> wrote:
For all MS's faults, Exchange really is a damn good product at the end of the day if it's set up per documentation (ie: not a single server) and you actually use any of its functionality. It's the most set-it-and-forget-it and self-healing system outside of normal patching I've ever had to deal with at scale (largest of 70k users, smallest of 100 users).
Never spent 27 hours watching eseutil check and fix their annoying binary blob of a mailstore before being able to bring email back online, have you? ;) -A
Not when the 3 other members of the DAG and the LAG copy making doing that a pointless exercise 😉 From: Aaron C. de Bruyn <aaron@heyaaron.com> Sent: Wednesday, November 12, 2025 10:39 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Gary Sparkes <gary@kisaracorporation.com> Subject: Re: [Ext] trolling On Tue, Nov 11, 2025 at 7:35 AM Gary Sparkes via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: For all MS's faults, Exchange really is a damn good product at the end of the day if it's set up per documentation (ie: not a single server) and you actually use any of its functionality. It's the most set-it-and-forget-it and self-healing system outside of normal patching I've ever had to deal with at scale (largest of 70k users, smallest of 100 users). Never spent 27 hours watching eseutil check and fix their annoying binary blob of a mailstore before being able to bring email back online, have you? ;) -A
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 8, 2025, at 7:50 PM, William Herrin via NANOG <nanog@lists.nanog.org> wrote: On Sat, Nov 8, 2025 at 5:27 AM nanog--- via NANOG <nanog@lists.nanog.org> wrote: Perhaps those who call others "internet trolls" should reconsider whether their own behaviour is trolling. In the modern online environment, it is unwise to expose personal information needlessly. I vaguely recall a rule on the mailing list, lightly enforced, that participants were expected to use their own real names. I believe the grounds for it was that this is a professional forum intended to facilitate discussion between professionals. Not some hackernet on the dark web. Did the policy change at some point or am I misremembering it entirely? Regards, Bill Herrin _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 8, 2025, at 2:27 PM, nanog--- via NANOG <nanog@lists.nanog.org> wrote: I said what I meant to say. "less than 98% as much" is the same thing as "savings greater than 2%". Perhaps those who call others "internet trolls" should reconsider whether their own behaviour is trolling. In the modern online environment, it is unwise to expose personal information needlessly. I could have used a realistic randomly chosen pseudonym, but I felt it would add no value. Technical content should be evaluated based on its merit, not based on the name attached to it. Though it's regrettable the new mailing list software also makes it hard to see the sender's address. On 7 November 2025 18:53:38 CET, Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote: On eyeball networks here, we're seeing about 60-70% native IPv6 traffic. Definitely on the services (IE hosted/provided services, not network services) side, It's a mix, but around 50-60%. Mind you, I deal primarily with US facing infrastructure (provider and eyeball) only. In terms of NAT load, that's meant an actual reduction in hardware footprint, via things like edge CPU and RAM usage, etc. Less power, less hardware, less expense - with better throughput overall per amount of hardware, to boot - without having to over-size hardware to compensate. So while I think they meant to say uses more than 2% less, it definitely has been *far more* than 2% savings for us (my org, other orgs I'm involved with, etc), just via NAT reduction. Other simplification benefits for deployment/design have also netted savings. The added benefit of a lot of things just working, and working more reliably, is a bonus, as well. -----Original Message----- From: A B via NANOG <nanog@lists.nanog.org> Sent: Friday, November 7, 2025 11:25 AM To: nanog--- via NANOG <nanog@lists.nanog.org> Cc: A B <ab.nanog@loopw.com> Subject: Re: my finance department cares deeply about 2% On Thu, 06 Nov 2025 18:58:10 +0100 nanog--- via NANOG <nanog@lists.nanog.org> wrote: fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. NAT is definitely not "computation-hungry" anymore - In many modern stacks there's hardly any penalty for NAT vs not. And by modern I mean "almost anything written after the mid 1990s" "uses less than 98% as much electricity" so it uses 97% as much as ipv4? At 1500 MTU? Does that at all sound right to anyone? "Hey we increased the header so you get reduced data payload, thus taking more packets to do the same work" doesnt really sound like an electrical savings to me. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 8, 2025, at 2:27 PM, nanog--- via NANOG <nanog@lists.nanog.org> wrote: I said what I meant to say. "less than 98% as much" is the same thing as "savings greater than 2%". Perhaps those who call others "internet trolls" should reconsider whether their own behaviour is trolling. In the modern online environment, it is unwise to expose personal information needlessly. I could have used a realistic randomly chosen pseudonym, but I felt it would add no value. Technical content should be evaluated based on its merit, not based on the name attached to it. Though it's regrettable the new mailing list software also makes it hard to see the sender's address. On 7 November 2025 18:53:38 CET, Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote: On eyeball networks here, we're seeing about 60-70% native IPv6 traffic. Definitely on the services (IE hosted/provided services, not network services) side, It's a mix, but around 50-60%. Mind you, I deal primarily with US facing infrastructure (provider and eyeball) only. In terms of NAT load, that's meant an actual reduction in hardware footprint, via things like edge CPU and RAM usage, etc. Less power, less hardware, less expense - with better throughput overall per amount of hardware, to boot - without having to over-size hardware to compensate. So while I think they meant to say uses more than 2% less, it definitely has been *far more* than 2% savings for us (my org, other orgs I'm involved with, etc), just via NAT reduction. Other simplification benefits for deployment/design have also netted savings. The added benefit of a lot of things just working, and working more reliably, is a bonus, as well. -----Original Message----- From: A B via NANOG <nanog@lists.nanog.org> Sent: Friday, November 7, 2025 11:25 AM To: nanog--- via NANOG <nanog@lists.nanog.org> Cc: A B <ab.nanog@loopw.com> Subject: Re: my finance department cares deeply about 2% On Thu, 06 Nov 2025 18:58:10 +0100 nanog--- via NANOG <nanog@lists.nanog.org> wrote: fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. NAT is definitely not "computation-hungry" anymore - In many modern stacks there's hardly any penalty for NAT vs not. And by modern I mean "almost anything written after the mid 1990s" "uses less than 98% as much electricity" so it uses 97% as much as ipv4? At 1500 MTU? Does that at all sound right to anyone? "Hey we increased the header so you get reduced data payload, thus taking more packets to do the same work" doesnt really sound like an electrical savings to me. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 6:53 PM, Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote: On eyeball networks here, we're seeing about 60-70% native IPv6 traffic. Definitely on the services (IE hosted/provided services, not network services) side, It's a mix, but around 50-60%. Mind you, I deal primarily with US facing infrastructure (provider and eyeball) only. In terms of NAT load, that's meant an actual reduction in hardware footprint, via things like edge CPU and RAM usage, etc. Less power, less hardware, less expense - with better throughput overall per amount of hardware, to boot - without having to over-size hardware to compensate. So while I think they meant to say uses more than 2% less, it definitely has been *far more* than 2% savings for us (my org, other orgs I'm involved with, etc), just via NAT reduction. Other simplification benefits for deployment/design have also netted savings. The added benefit of a lot of things just working, and working more reliably, is a bonus, as well. -----Original Message----- From: A B via NANOG <nanog@lists.nanog.org> Sent: Friday, November 7, 2025 11:25 AM To: nanog--- via NANOG <nanog@lists.nanog.org> Cc: A B <ab.nanog@loopw.com> Subject: Re: my finance department cares deeply about 2% On Thu, 06 Nov 2025 18:58:10 +0100 nanog--- via NANOG <nanog@lists.nanog.org> wrote: fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. NAT is definitely not "computation-hungry" anymore - In many modern stacks there's hardly any penalty for NAT vs not. And by modern I mean "almost anything written after the mid 1990s" "uses less than 98% as much electricity" so it uses 97% as much as ipv4? At 1500 MTU? Does that at all sound right to anyone? "Hey we increased the header so you get reduced data payload, thus taking more packets to do the same work" doesnt really sound like an electrical savings to me. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 6:53 PM, Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote: On eyeball networks here, we're seeing about 60-70% native IPv6 traffic. Definitely on the services (IE hosted/provided services, not network services) side, It's a mix, but around 50-60%. Mind you, I deal primarily with US facing infrastructure (provider and eyeball) only. In terms of NAT load, that's meant an actual reduction in hardware footprint, via things like edge CPU and RAM usage, etc. Less power, less hardware, less expense - with better throughput overall per amount of hardware, to boot - without having to over-size hardware to compensate. So while I think they meant to say uses more than 2% less, it definitely has been *far more* than 2% savings for us (my org, other orgs I'm involved with, etc), just via NAT reduction. Other simplification benefits for deployment/design have also netted savings. The added benefit of a lot of things just working, and working more reliably, is a bonus, as well. -----Original Message----- From: A B via NANOG <nanog@lists.nanog.org> Sent: Friday, November 7, 2025 11:25 AM To: nanog--- via NANOG <nanog@lists.nanog.org> Cc: A B <ab.nanog@loopw.com> Subject: Re: my finance department cares deeply about 2% On Thu, 06 Nov 2025 18:58:10 +0100 nanog--- via NANOG <nanog@lists.nanog.org> wrote: fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. NAT is definitely not "computation-hungry" anymore - In many modern stacks there's hardly any penalty for NAT vs not. And by modern I mean "almost anything written after the mid 1990s" "uses less than 98% as much electricity" so it uses 97% as much as ipv4? At 1500 MTU? Does that at all sound right to anyone? "Hey we increased the header so you get reduced data payload, thus taking more packets to do the same work" doesnt really sound like an electrical savings to me. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
On Fri, Nov 7, 2025, 11:28 A B via NANOG
"uses less than 98% as much electricity" so it uses 97% as much as ipv4? At 1500 MTU? Does that at all sound right to anyone? "Hey we increased the header so you get reduced data payload, thus taking more packets to do the same work" doesnt really sound like an electrical savings to me.
I'm not 100% confident on those actual figures, but there's a couple ways this is possible. 1. IPv4 IP hdr is *variable length* at 20-60 bytes. You have to shift and mask the IHL to get that length. Buffer read-in aside, that right there is two ops that aren't present on IPv6 since it's fixed-len (40 bytes). In the wild, most (I'd wager all) IPv4 headers are 20 bytes on Internet traffic, but *they require more computation* (see #2). 2. IHL aside, IPv4 has *many* other header fields that require a ton of extra cycles for the same reason. DSCP/ECN, IP flags, frag offset, *and* parsing of all the IP options. (After calculating the offset and stripping off padding, of course.) They may not be used, at least commonly, but they still have to be parsed. 2.b. IPv6 just has (Version/)Traffic Class/Flow Label that needs shifting/masking (and you already processed the version). No padding, no offsets, no variable-length buffers, no IP options that need to be iterated, etc. 3. As stated before, IPv6 also has no Internet Checksum in its header. That's significantly less cycles as well. (Obviously it still has the frame check sequence for Ethernet II, plus whatever payload checksumming at layer 4 if any, but both of those are going to be present regardless of net addr family.)
So 97% as much electricity does at least seem *feasible/plausible* to me. Sure, you're potentially pushing more packets, but compared to e.g. TCP chattiness overhead it's a drop in the bucket. YMMV, but a quick sampling on my gateway shows a significantly vast amount - most, I'd wager - of my traffic doesn't seem to break 800 bytes/ea., even for QUIC and HTTPS/HTTP2.
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 8, 2025, at 4:30 PM, brent saner via NANOG <nanog@lists.nanog.org> wrote: On Fri, Nov 7, 2025, 11:28 A B via NANOG "uses less than 98% as much electricity" so it uses 97% as much as ipv4? At 1500 MTU? Does that at all sound right to anyone? "Hey we increased the header so you get reduced data payload, thus taking more packets to do the same work" doesnt really sound like an electrical savings to me. I'm not 100% confident on those actual figures, but there's a couple ways this is possible. 1. IPv4 IP hdr is *variable length* at 20-60 bytes. You have to shift and mask the IHL to get that length. Buffer read-in aside, that right there is two ops that aren't present on IPv6 since it's fixed-len (40 bytes). In the wild, most (I'd wager all) IPv4 headers are 20 bytes on Internet traffic, but *they require more computation* (see #2). 2. IHL aside, IPv4 has *many* other header fields that require a ton of extra cycles for the same reason. DSCP/ECN, IP flags, frag offset, *and* parsing of all the IP options. (After calculating the offset and stripping off padding, of course.) They may not be used, at least commonly, but they still have to be parsed. 2.b. IPv6 just has (Version/)Traffic Class/Flow Label that needs shifting/masking (and you already processed the version). No padding, no offsets, no variable-length buffers, no IP options that need to be iterated, etc. 3. As stated before, IPv6 also has no Internet Checksum in its header. That's significantly less cycles as well. (Obviously it still has the frame check sequence for Ethernet II, plus whatever payload checksumming at layer 4 if any, but both of those are going to be present regardless of net addr family.) So 97% as much electricity does at least seem *feasible/plausible* to me. Sure, you're potentially pushing more packets, but compared to e.g. TCP chattiness overhead it's a drop in the bucket. YMMV, but a quick sampling on my gateway shows a significantly vast amount - most, I'd wager - of my traffic doesn't seem to break 800 bytes/ea., even for QUIC and HTTPS/HTTP2. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 8, 2025, at 4:30 PM, brent saner via NANOG <nanog@lists.nanog.org> wrote: On Fri, Nov 7, 2025, 11:28 A B via NANOG "uses less than 98% as much electricity" so it uses 97% as much as ipv4? At 1500 MTU? Does that at all sound right to anyone? "Hey we increased the header so you get reduced data payload, thus taking more packets to do the same work" doesnt really sound like an electrical savings to me. I'm not 100% confident on those actual figures, but there's a couple ways this is possible. 1. IPv4 IP hdr is *variable length* at 20-60 bytes. You have to shift and mask the IHL to get that length. Buffer read-in aside, that right there is two ops that aren't present on IPv6 since it's fixed-len (40 bytes). In the wild, most (I'd wager all) IPv4 headers are 20 bytes on Internet traffic, but *they require more computation* (see #2). 2. IHL aside, IPv4 has *many* other header fields that require a ton of extra cycles for the same reason. DSCP/ECN, IP flags, frag offset, *and* parsing of all the IP options. (After calculating the offset and stripping off padding, of course.) They may not be used, at least commonly, but they still have to be parsed. 2.b. IPv6 just has (Version/)Traffic Class/Flow Label that needs shifting/masking (and you already processed the version). No padding, no offsets, no variable-length buffers, no IP options that need to be iterated, etc. 3. As stated before, IPv6 also has no Internet Checksum in its header. That's significantly less cycles as well. (Obviously it still has the frame check sequence for Ethernet II, plus whatever payload checksumming at layer 4 if any, but both of those are going to be present regardless of net addr family.) So 97% as much electricity does at least seem *feasible/plausible* to me. Sure, you're potentially pushing more packets, but compared to e.g. TCP chattiness overhead it's a drop in the bucket. YMMV, but a quick sampling on my gateway shows a significantly vast amount - most, I'd wager - of my traffic doesn't seem to break 800 bytes/ea., even for QUIC and HTTPS/HTTP2. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 5:24 PM, A B via NANOG <nanog@lists.nanog.org> wrote: On Thu, 06 Nov 2025 18:58:10 +0100 nanog--- via NANOG <nanog@lists.nanog.org> wrote: fun fact I forgot to mention: if you use ipv6 on cellphone connections, your site loads more than 2% faster and uses less than 98% as much electricity, due to avoiding the expensive and computation-hungry NAT process itself, as well as not needing to be physically routed to that big centralised server and back. So if you care about 2%, you'll use IPv6. NAT is definitely not "computation-hungry" anymore - In many modern stacks there's hardly any penalty for NAT vs not. And by modern I mean "almost anything written after the mid 1990s" "uses less than 98% as much electricity" so it uses 97% as much as ipv4? At 1500 MTU? Does that at all sound right to anyone? "Hey we increased the header so you get reduced data payload, thus taking more packets to do the same work" doesnt really sound like an electrical savings to me. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
On Thu, 6 Nov 2025 at 19:52, nanog--- via NANOG <nanog@lists.nanog.org> wrote:
So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine.
IPv6 is kind of riddled with these changes for sake of change, which just made things worse. - removing checksum (no way to know when LSR/L2 transit has broken memory, mangling frames) - mandating multicast for L2 disco (not actually implemented, linux, cisco, juniper... doesn't even join the /mandatory/ group by default, switches do not have scale to handle it under adverse condition). In reality good 'ol flooding is used, because cure was worse than the disease - forcing ipsec into it, later removed - the whole lunacy of massive network sizes, making it impossible to make secure L2 disco without complicated and expensive protection logic which rarely exists. All while technically SLAAC and DAD would allow using arbitrarily small, or if you actually force L2 address in L3 address you could do stateless (no ND), which is also not implemented anywhere - whole next-header woe with TCP/UDP at the bottom, lucily in practice situation remains same as in IPV4, you cannot use those options and no new functionality can be added by introducing new ones, outside of controlled small environments, which might just as well run IPv42, when interop is not relevant. While in reality only utility needed or gained is more addresses, which is sufficient to fix the actual problem we had. But we keep trying to add opinionated solutions for problems that may or may not exist, adding disagreements and reducing motivation to implement and migrate. -- ++ytti
On 07.11.2025 10:09 Saku Ytti via NANOG wrote:
On Thu, 6 Nov 2025 at 19:52, nanog--- via NANOG <nanog@lists.nanog.org> wrote:
So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine.
IPv6 is kind of riddled with these changes for sake of change, which just made things worse.
- removing checksum (no way to know when LSR/L2 transit has broken memory, mangling frames)
UDP and TCP have checksums. Other applications have signature mechanisms to verify the data, e.g. gpg, certificates etc. IPsec exists which also provides such mechanisms if needed.
On Fri, 7 Nov 2025 at 16:10, Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
UDP and TCP have checksums. Other applications have signature mechanisms to verify the data, e.g. gpg, certificates etc. IPsec exists which also provides such mechanisms if needed.
Transit doesn't verify UDP/TCP checksum. So with IPv6 you have no way of knowing when bad memory is mangling your packets, which very likely is happening right now on some people on this very mailing list, which they could diagnose by looking at IP checksums failing for packets coming in from LSR or L2 transit to the L3 edge. Even digging up UDP/TCP from IPv6 can be very tricky, it is easy to exhaust ex Nokia FP resources and stall the CPU by stacking headers, in Juniper this doesn't happen, because Trio will eventually just discard packets with too many stacked headers. Which is problematic, as end host has no problem dealing with large stack of headers, so this can be made to evade some type of ACL, such as permy any host SMTP1 smtp, deny any any smtp. To stop residential from sending email outside approved email GW. -- ++ytti
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 5:53 PM, Saku Ytti via NANOG <nanog@lists.nanog.org> wrote: On Fri, 7 Nov 2025 at 16:10, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: UDP and TCP have checksums. Other applications have signature mechanisms to verify the data, e.g. gpg, certificates etc. IPsec exists which also provides such mechanisms if needed. Transit doesn't verify UDP/TCP checksum. So with IPv6 you have no way of knowing when bad memory is mangling your packets, which very likely is happening right now on some people on this very mailing list, which they could diagnose by looking at IP checksums failing for packets coming in from LSR or L2 transit to the L3 edge. Even digging up UDP/TCP from IPv6 can be very tricky, it is easy to exhaust ex Nokia FP resources and stall the CPU by stacking headers, in Juniper this doesn't happen, because Trio will eventually just discard packets with too many stacked headers. Which is problematic, as end host has no problem dealing with large stack of headers, so this can be made to evade some type of ACL, such as permy any host SMTP1 smtp, deny any any smtp. To stop residential from sending email outside approved email GW. -- ++ytti _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 5:53 PM, Saku Ytti via NANOG <nanog@lists.nanog.org> wrote: On Fri, 7 Nov 2025 at 16:10, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: UDP and TCP have checksums. Other applications have signature mechanisms to verify the data, e.g. gpg, certificates etc. IPsec exists which also provides such mechanisms if needed. Transit doesn't verify UDP/TCP checksum. So with IPv6 you have no way of knowing when bad memory is mangling your packets, which very likely is happening right now on some people on this very mailing list, which they could diagnose by looking at IP checksums failing for packets coming in from LSR or L2 transit to the L3 edge. Even digging up UDP/TCP from IPv6 can be very tricky, it is easy to exhaust ex Nokia FP resources and stall the CPU by stacking headers, in Juniper this doesn't happen, because Trio will eventually just discard packets with too many stacked headers. Which is problematic, as end host has no problem dealing with large stack of headers, so this can be made to evade some type of ACL, such as permy any host SMTP1 smtp, deny any any smtp. To stop residential from sending email outside approved email GW. -- ++ytti _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 3:10 PM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: On 07.11.2025 10:09 Saku Ytti via NANOG wrote: On Thu, 6 Nov 2025 at 19:52, nanog--- via NANOG <nanog@lists.nanog.org> wrote: So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine. IPv6 is kind of riddled with these changes for sake of change, which just made things worse. - removing checksum (no way to know when LSR/L2 transit has broken memory, mangling frames) UDP and TCP have checksums. Other applications have signature mechanisms to verify the data, e.g. gpg, certificates etc. IPsec exists which also provides such mechanisms if needed. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 6, 2025, at 6:52 PM, nanog--- via NANOG <nanog@lists.nanog.org> wrote: So you use header compression on all your links, right? No sense reducing your 1Gbps main uplink to 0.98Gbps. The checksum (removed in v6) is already 5% of each IP packet header. Speaking of headers I take it you're using SLIP instead of Ethernet? And you avoid TLS like the plague? I hope you replaced your 15W LED bulbs with 14.7W bulbs as well - your finance department will thank you. This is asinine. On 6 November 2025 13:11:16 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:12 Vasilenko Eduard wrote: The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 6, 2025, at 1:11 PM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Tell any financial department that 2% does not matter and see the reaction. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 14:53 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:12 Vasilenko Eduard wrote: The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 6, 2025, at 12:53 PM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: On 06.11.2025 07:12 Vasilenko Eduard wrote: The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. No one cares nowadays. The amount of other crap traffic (scrapers, AI, spam, DDoS attacks) is a real problem, the additional bits in the header aren't. The time of slow dialup connections where every bit matters, is over. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 6, 2025, at 8:12 AM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: The issue that 128bits (64+64) are wasted in every packet. Formally, for "privacy". Content providers are lathing from such form or privacy. But it is 2% of the internet capacity. Eduard -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 10:07 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 06:27 Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote: I do not understand what you are talking about. IPv6 is mostly using SLAAC. SLAAC is 64 bit addressing architecture. (by the way, 64 bit is enough for addressing of everything) Even if somebody use DHCP, he typically makes subnet "SLAAC compatible", it means: use 64 bits for addressing. Where is the issue there? Unless the A-bit is set for the prefix in the RA, no machine will do autoconfiguration using SLAAC. -- kind regards Marco Send spam to abfall1762406841@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 6, 2025, at 8:06 AM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: On 06.11.2025 06:27 Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote: I do not understand what you are talking about. IPv6 is mostly using SLAAC. SLAAC is 64 bit addressing architecture. (by the way, 64 bit is enough for addressing of everything) Even if somebody use DHCP, he typically makes subnet "SLAAC compatible", it means: use 64 bits for addressing. Where is the issue there? Unless the A-bit is set for the prefix in the RA, no machine will do autoconfiguration using SLAAC. -- kind regards Marco Send spam to abfall1762406841@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/H7IGODXA...
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 6, 2025, at 7:27 AM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: I do not understand what you are talking about. IPv6 is mostly using SLAAC. SLAAC is 64 bit addressing architecture. (by the way, 64 bit is enough for addressing of everything) Even if somebody use DHCP, he typically makes subnet "SLAAC compatible", it means: use 64 bits for addressing. Eduard -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Wednesday, November 5, 2025 17:35 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) Am 05.11.2025 um 13:03:46 Uhr schrieb Vasilenko Eduard: Are you aware that EUI64 is only one way to generate the addresses and that the 64 bits can be randomly filled or be static? Do you mean that random garbage (for privacy) did return 2% resources to the Internet? These 16 bytes (8 for source and 8 for destination) are still used not for IP addressing. Does it matter for what it is used, if it is not IP addressing? IPv6 is 64+bit architecture (a few bits are used inside subnet) I do not understand what you are talking about. For IPv6, the subnets that are connected to links should always be /64. Various ways exist to fill the other 64 bit. If you want NAT really hard, you can use it with IPv6 too. fd00::/8 exist. Then it is better to use NTP. But IETF makes everything possible to block it too. Anyway, if NAT (in any form) is blocked then there is no practical solution for ISP redundancy: There is and I pointed that out. The NAT "redundancy" "solutions" do not offer redundancy. They are a cripple solution. -- Gruß Marco Send unsolicited bulk mail to 1762344226muell@cartoonies.org _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
On Wed, Nov 5, 2025 at 8:04 AM Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote:
Anyway, if NAT (in any form) is blocked then there is no practical solution for ISP redundancy: https://datatracker.ietf.org/doc/html/draft-fbnvv-v6ops-site-multihoming-03 Read it to understand what the mess is going there - it is really complicated.
This problem exists today. If I need public IP addresses at a smaller remote office (VPN Citrix whatever), I either have to get them from one ISP, the other, do some weird multiple IP's on a host with source routing thing, or BGP. Isn't BGP traditionally the solution for multi-homing/redundancy? At which point you have two options: 1. the IPv6 routing table is small ~256k routes, so just take a full table 2. use a prefix length filter appropriate for your given situation Routers that can handle multiple 256k route tables are not expensive if you're willing to live with something other than the big players at a branch office. Andrew
Am 05.11.2025 um 09:58:29 Uhr schrieb Andrew Kirch via NANOG:
Isn't BGP traditionally the solution for multi-homing/redundancy? At which point you have two options: 1. the IPv6 routing table is small ~256k routes, so just take a full table 2. use a prefix length filter appropriate for your given situation
Why do you need a full table in that case? 2 default routes should be enough if the ISP allows that. -- Gruß Marco Send unsolicited bulk mail to 1762333109muell@cartoonies.org
On Wed, Nov 5, 2025 at 6:00 AM Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote:
Hi Tim, Multi-prefix, SP address delegation through the site, absence of NAT.
Absence of NAT seems like a feature to me. Fixing things to work with NAT has been, and continues to be incredibly expensive. NAT provides little to no value in IPv6 because it is not scarcity driven. Eliminating NAT is a net-benefit of IPv6. Andrew
Absence of NAT seems like a feature to me. Only if IETF would fix multi-hop multi-prefix solution for the business site. Home Networking WG did fail. SHIM6 failed too. Till that time, NAT is the only solution for business. Wed/ -----Original Message----- From: Andrew Kirch via NANOG <nanog@lists.nanog.org> Sent: Wednesday, November 5, 2025 17:50 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Andrew Kirch <trelane@trelane.net> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
On Wed, Nov 5, 2025 at 6:00 AM Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote:
Hi Tim, Multi-prefix, SP address delegation through the site, absence of NAT.
Absence of NAT seems like a feature to me. Fixing things to work with NAT has been, and continues to be incredibly expensive. NAT provides little to no value in IPv6 because it is not scarcity driven. Eliminating NAT is a net-benefit of IPv6. Andrew _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VN6EHSOE...
On 06.11.2025 06:13 Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
Absence of NAT seems like a feature to me. Only if IETF would fix multi-hop multi-prefix solution for the business site. Home Networking WG did fail. SHIM6 failed too. Till that time, NAT is the only solution for business.
You seem to have no experience with real redundancy. Those NAT solutions cannot provide it. You can reach the same situation with NAT66 like with NAT44, if you really want. Real redundancy solutions exist and certain businesses use it. -- kind regards Marco Send spam to abfall1762406007@stinkedores.dorfdsl.de
You seem to have no experience with real redundancy. The first time I configured Cisco 2500 with ISP redundancy in 1998. It worked fine: If the link to the primary ISP was down, the office (50 employees company) still have connectivity through the other link. And yes, the office network was not flat - it had many subnets.
Or what you mean by "redundancy"? IETF is doing everything possible to prevent NAT66. Eduard -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 10:08 To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 06:13 Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
Absence of NAT seems like a feature to me. Only if IETF would fix multi-hop multi-prefix solution for the business site. Home Networking WG did fail. SHIM6 failed too. Till that time, NAT is the only solution for business.
You seem to have no experience with real redundancy. Those NAT solutions cannot provide it. You can reach the same situation with NAT66 like with NAT44, if you really want. Real redundancy solutions exist and certain businesses use it. -- kind regards Marco Send spam to abfall1762406007@stinkedores.dorfdsl.de
On 06.11.2025 07:18 Vasilenko Eduard wrote:
The first time I configured Cisco 2500 with ISP redundancy in 1998. It worked fine: If the link to the primary ISP was down, the office (50 employees company) still have connectivity through the other link. And yes, the office network was not flat - it had many subnets.
In case of failure all the connections fail and need to be restablished. That is not something I call redundancy. If you host services inside such a network, both IP addresses must be present in the DNS and that means clients can use any and take some time until they notice the failing connection. An established connection will break this way too. Redundancy is different and means your network is connected by 2 ISP - independent of their address ranges.
Hi Marco, You are asking too much for 30M of business worldwide. Just outgoing connections redundancy is enough for 99% of them. Older times, they have DMZ and their own Web server. It does not make sense now - server may be in the cloud, but mostly it is not needed - they have an account on some platform. Eduard -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 14:08 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:18 Vasilenko Eduard wrote:
The first time I configured Cisco 2500 with ISP redundancy in 1998. It worked fine: If the link to the primary ISP was down, the office (50 employees company) still have connectivity through the other link. And yes, the office network was not flat - it had many subnets.
In case of failure all the connections fail and need to be restablished. That is not something I call redundancy. If you host services inside such a network, both IP addresses must be present in the DNS and that means clients can use any and take some time until they notice the failing connection. An established connection will break this way too. Redundancy is different and means your network is connected by 2 ISP - independent of their address ranges. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JKKZN4DX...
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 6, 2025, at 12:16 PM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Hi Marco, You are asking too much for 30M of business worldwide. Just outgoing connections redundancy is enough for 99% of them. Older times, they have DMZ and their own Web server. It does not make sense now - server may be in the cloud, but mostly it is not needed - they have an account on some platform. Eduard -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 14:08 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 07:18 Vasilenko Eduard wrote: The first time I configured Cisco 2500 with ISP redundancy in 1998. It worked fine: If the link to the primary ISP was down, the office (50 employees company) still have connectivity through the other link. And yes, the office network was not flat - it had many subnets. In case of failure all the connections fail and need to be restablished. That is not something I call redundancy. If you host services inside such a network, both IP addresses must be present in the DNS and that means clients can use any and take some time until they notice the failing connection. An established connection will break this way too. Redundancy is different and means your network is connected by 2 ISP - independent of their address ranges. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 6, 2025, at 12:07 PM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: On 06.11.2025 07:18 Vasilenko Eduard wrote: The first time I configured Cisco 2500 with ISP redundancy in 1998. It worked fine: If the link to the primary ISP was down, the office (50 employees company) still have connectivity through the other link. And yes, the office network was not flat - it had many subnets. In case of failure all the connections fail and need to be restablished. That is not something I call redundancy. If you host services inside such a network, both IP addresses must be present in the DNS and that means clients can use any and take some time until they notice the failing connection. An established connection will break this way too. Redundancy is different and means your network is connected by 2 ISP - independent of their address ranges. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 6, 2025, at 8:18 AM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: You seem to have no experience with real redundancy. The first time I configured Cisco 2500 with ISP redundancy in 1998. It worked fine: If the link to the primary ISP was down, the office (50 employees company) still have connectivity through the other link. And yes, the office network was not flat - it had many subnets. Or what you mean by "redundancy"? IETF is doing everything possible to prevent NAT66. Eduard -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 10:08 To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 06.11.2025 06:13 Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Absence of NAT seems like a feature to me. Only if IETF would fix multi-hop multi-prefix solution for the business site. Home Networking WG did fail. SHIM6 failed too. Till that time, NAT is the only solution for business. You seem to have no experience with real redundancy. Those NAT solutions cannot provide it. You can reach the same situation with NAT66 like with NAT44, if you really want. Real redundancy solutions exist and certain businesses use it. -- kind regards Marco Send spam to abfall1762406007@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 6, 2025, at 8:08 AM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote: On 06.11.2025 06:13 Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Absence of NAT seems like a feature to me. Only if IETF would fix multi-hop multi-prefix solution for the business site. Home Networking WG did fail. SHIM6 failed too. Till that time, NAT is the only solution for business. You seem to have no experience with real redundancy. Those NAT solutions cannot provide it. You can reach the same situation with NAT66 like with NAT44, if you really want. Real redundancy solutions exist and certain businesses use it. -- kind regards Marco Send spam to abfall1762406007@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DZAUF66Y...
MAC addresses are not inside IPv6 addresses. That is just one of many possible ways to assign addresses. It's not a layer violation because it is completely optional. On 5 November 2025 12:00:13 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
Hi Tim, Multi-prefix, SP address delegation through the site, absence of NAT. Many things. Try to organize the primary and redundant connection to the SP (that is needed for every business).
The fact that every subnet is /64 is convenient. Just if has a payment 16/750=2% of the overall Internet capacity (750B is the average packet size). The decision to violate OSI model and put MAC address inside IP address was very questionable. Eduard -----Original Message----- From: tim--- via NANOG <nanog@lists.nanog.org> Sent: Wednesday, November 5, 2025 12:59 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: tim@pelican.org Subject: RE: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
On Wednesday, 5 November, 2025 06:26, "Vasilenko Eduard via NANOG" <nanog@lists.nanog.org> said:
There is no possibility of canceling the "subnet" concept for business. IPv6 subnet complexity is too much burden for businesses.
I'm genuinely curious as to what you mean by this, Eduard.
For me, one of the benefits of v6 at the design stage is that subnetting is substantially *easier*. You don't have to worry about trying to carve up your address space to get the right number of hosts in the right places, or trade off bits of host-mask against bits of net-mask.
All the subnets (and I mean LAN-type subnets here, obviously, not linknets) are /64s, there will *always* be enough host addresses. Stop thinking about host counts - it's irrelevant to the design. Simplification step 1.
Now your design can purely think about how many subnets do I need, where do I need them, what do I need them for. Even a basic home-level allocation of a /56 lets you either have a flat '00' - 'ff' subnet space that you can assign a function to each value of with loads to spare, or split out into a 'location' nibble and a 'function' nibble.
A business with a /48 can encode all kinds of useful information into the 16 bits of 'subnet' available - business units, security zones, multiple levels of geographical hierarchy.
Or if you don't want to be that complex, you can still just work upwards from 2001:db8:1234:0::/64, 2001:db8:1234:1::/64, in the same way you did for 192.168.0.0/24, 192.168.1.0/24.
There are challenges to adopting v6, sure, but I'm not clear how 'subnetting' is one of them.
Cheers, Tim.
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BK74QBTI... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/42TWWH73...
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 6, 2025, at 1:03 PM, nanog--- via NANOG <nanog@lists.nanog.org> wrote: MAC addresses are not inside IPv6 addresses. That is just one of many possible ways to assign addresses. It's not a layer violation because it is completely optional. On 5 November 2025 12:00:13 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Hi Tim, Multi-prefix, SP address delegation through the site, absence of NAT. Many things. Try to organize the primary and redundant connection to the SP (that is needed for every business). The fact that every subnet is /64 is convenient. Just if has a payment 16/750=2% of the overall Internet capacity (750B is the average packet size). The decision to violate OSI model and put MAC address inside IP address was very questionable. Eduard -----Original Message----- From: tim--- via NANOG <nanog@lists.nanog.org> Sent: Wednesday, November 5, 2025 12:59 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: tim@pelican.org Subject: RE: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On Wednesday, 5 November, 2025 06:26, "Vasilenko Eduard via NANOG" <nanog@lists.nanog.org> said: There is no possibility of canceling the "subnet" concept for business. IPv6 subnet complexity is too much burden for businesses. I'm genuinely curious as to what you mean by this, Eduard. For me, one of the benefits of v6 at the design stage is that subnetting is substantially *easier*. You don't have to worry about trying to carve up your address space to get the right number of hosts in the right places, or trade off bits of host-mask against bits of net-mask. All the subnets (and I mean LAN-type subnets here, obviously, not linknets) are /64s, there will *always* be enough host addresses. Stop thinking about host counts - it's irrelevant to the design. Simplification step 1. Now your design can purely think about how many subnets do I need, where do I need them, what do I need them for. Even a basic home-level allocation of a /56 lets you either have a flat '00' - 'ff' subnet space that you can assign a function to each value of with loads to spare, or split out into a 'location' nibble and a 'function' nibble. A business with a /48 can encode all kinds of useful information into the 16 bits of 'subnet' available - business units, security zones, multiple levels of geographical hierarchy. Or if you don't want to be that complex, you can still just work upwards from 2001:db8:1234:0::/64, 2001:db8:1234:1::/64, in the same way you did for 192.168.0.0/24, 192.168.1.0/24. There are challenges to adopting v6, sure, but I'm not clear how 'subnetting' is one of them. Cheers, Tim. _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
Am 05.11.2025 um 06:26:39 Uhr schrieb Vasilenko Eduard:
There is a big misunderstanding about IPv6 on mobile (and the majority of residential broadband): it is NOT an IPv6. The primary difference between IPv4 and IPv6 is the first hop: IPv6 has enormous flexibility and complexity here.
Residential customers get PPP or even a direct ethernet connection. Then DHCPv6-PD is being used. Works fine and is being used by millions of people here in Germany. Business connections might get different protocols, but they are set up by people who should know how to set them up.
But MBB/FBB completely disabled all IPv6 features on the first hop;
Explain that further.
it is possible because L2 P2P connection is emulated here (PPP or GTP tunnel). Such castrated IPv6 works perfectly fine (for residential/mobile) because it is even simpler than IPv4. The big address space of IPv6 (64 bits) is a value here.
There is no possibility of canceling the "subnet" concept for business.
It is available in IPv6 too. RFCs say they should get a /48, so 2^16 subnets. In case they need more, they can request more from the RIR. I've seen large enterprises where 10.0.0.0/8 isn't enough. And their NAT crap is just a PITA for everyone who has to do with their network.
IPv6 subnet complexity is too much burden for businesses.
It is less complex than IPv4 subnetting, especially when partial NAT is involved. If network engineers can't handle IPv6 subnetting, they should apply for another job.
Hence, IPv4 will stay for business forever.
I have serious doubt it will stay when IPv6 will be mandatory (remember how fast businesses implemented TLS or DKIM when the big players requested that?).
IMHO: the world would finally accept: "reduced IPv6 for subscribers, IPv4 for businesses". IMHO: the full IPv6 (it was called "Next Generation" 3 decades ago) has no future. Eduard
I have serious doubt there will be another protocol that replaces it. IPv6 is now already present in most protocol stacks (I know that devices without it exist), at carrier networks and at many ISPs. A new protocol needs time to be implemented and shares the same problem as IPv4: There are people who do not want it and there is no "IPv4 with longer addresses that is backward compatible" (and cannot be). -- Gruß Marco Send unsolicited bulk mail to 1762320399muell@cartoonies.org
Try to propagate the ISP prefix over a few hops of the routed network (on the site of some business). DHCPv6-PD or whatever. Then read the documents of the closed IETF WG "Home Networking" to understand what a mess is it. Yes, a small number of businesses have a shortage inside 10/8. But even for them, IPv6 would be a much bigger challenge. The majority of businesses have no problem with a 10/8 size.
I have serious doubt there will be another protocol that replaces it. I do not believe too. Businesses would just stay on IPv4. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Wednesday, November 5, 2025 14:11 To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
Am 05.11.2025 um 06:26:39 Uhr schrieb Vasilenko Eduard:
There is a big misunderstanding about IPv6 on mobile (and the majority of residential broadband): it is NOT an IPv6. The primary difference between IPv4 and IPv6 is the first hop: IPv6 has enormous flexibility and complexity here.
Residential customers get PPP or even a direct ethernet connection. Then DHCPv6-PD is being used. Works fine and is being used by millions of people here in Germany. Business connections might get different protocols, but they are set up by people who should know how to set them up.
But MBB/FBB completely disabled all IPv6 features on the first hop;
Explain that further.
it is possible because L2 P2P connection is emulated here (PPP or GTP tunnel). Such castrated IPv6 works perfectly fine (for residential/mobile) because it is even simpler than IPv4. The big address space of IPv6 (64 bits) is a value here.
There is no possibility of canceling the "subnet" concept for business.
It is available in IPv6 too. RFCs say they should get a /48, so 2^16 subnets. In case they need more, they can request more from the RIR. I've seen large enterprises where 10.0.0.0/8 isn't enough. And their NAT crap is just a PITA for everyone who has to do with their network.
IPv6 subnet complexity is too much burden for businesses.
It is less complex than IPv4 subnetting, especially when partial NAT is involved. If network engineers can't handle IPv6 subnetting, they should apply for another job.
Hence, IPv4 will stay for business forever.
I have serious doubt it will stay when IPv6 will be mandatory (remember how fast businesses implemented TLS or DKIM when the big players requested that?).
IMHO: the world would finally accept: "reduced IPv6 for subscribers, IPv4 for businesses". IMHO: the full IPv6 (it was called "Next Generation" 3 decades ago) has no future. Eduard
I have serious doubt there will be another protocol that replaces it. IPv6 is now already present in most protocol stacks (I know that devices without it exist), at carrier networks and at many ISPs. A new protocol needs time to be implemented and shares the same problem as IPv4: There are people who do not want it and there is no "IPv4 with longer addresses that is backward compatible" (and cannot be). -- Gruß Marco Send unsolicited bulk mail to 1762320399muell@cartoonies.org
On 11/5/25 08:12, Vasilenko Eduard via NANOG wrote:
Try to propagate the ISP prefix over a few hops of the routed network (on the site of some business). DHCPv6-PD or whatever. Then read the documents of the closed IETF WG "Home Networking" to understand what a mess is it.
DHCPv6-PD with static memory at the delegating router is not the only way to propagate prefixes. It is an option, and it is the least-common-denominator option that is intended to make things usable for plug-and-play home users, but for people who have more complex network typologies yet still require a high degree of address agility, there are other ways to go about things. In fact, that's one of the reasons why people even bothered to make RIPng. If you have a complex network architecture and don't want to have to re-number, either acquire a truly static prefix from your provider (marrying you to your provider) or justify getting your own GUA prefix from an RIR and find a service provider that will route it for you. That's no different than IPv4 modulo the use of NAT. If you REALLY want to be able to switch globally-routable prefixes at the drop of a hat, that's what NPT at the edge and ULA in the network is for. No, it's not an option that you are encouraged to use and for various good reasons, but it does exist and solves that problem in a way that is no worse than NAT44 and in a way that can be substantially lighter weight (in particular, it can easily be made stateless). And if you REALLY, REALLY want straight up NAT66, it exists, and it works basically the same way as the NAT44 we're all used to and groan about. None of this is new. This has been the state of affairs for a couple decades, basically. -- Brandon Martin
Hi Marting, All your messages are true. But these are not all the complexities. Read here (if you like) https://datatracker.ietf.org/doc/html/draft-fbnvv-v6ops-site-multihoming-03. to see how deep is the rabbit hole and why it is better not to touch it. Ed/ -----Original Message----- From: Brandon Martin via NANOG <nanog@lists.nanog.org> Sent: Wednesday, November 5, 2025 18:55 To: nanog@lists.nanog.org Cc: Brandon Martin <lists.nanog@monmotha.net> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 11/5/25 08:12, Vasilenko Eduard via NANOG wrote:
Try to propagate the ISP prefix over a few hops of the routed network (on the site of some business). DHCPv6-PD or whatever. Then read the documents of the closed IETF WG "Home Networking" to understand what a mess is it.
DHCPv6-PD with static memory at the delegating router is not the only way to propagate prefixes. It is an option, and it is the least-common-denominator option that is intended to make things usable for plug-and-play home users, but for people who have more complex network typologies yet still require a high degree of address agility, there are other ways to go about things. In fact, that's one of the reasons why people even bothered to make RIPng. If you have a complex network architecture and don't want to have to re-number, either acquire a truly static prefix from your provider (marrying you to your provider) or justify getting your own GUA prefix from an RIR and find a service provider that will route it for you. That's no different than IPv4 modulo the use of NAT. If you REALLY want to be able to switch globally-routable prefixes at the drop of a hat, that's what NPT at the edge and ULA in the network is for. No, it's not an option that you are encouraged to use and for various good reasons, but it does exist and solves that problem in a way that is no worse than NAT44 and in a way that can be substantially lighter weight (in particular, it can easily be made stateless). And if you REALLY, REALLY want straight up NAT66, it exists, and it works basically the same way as the NAT44 we're all used to and groan about. None of this is new. This has been the state of affairs for a couple decades, basically. -- Brandon Martin _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DDOM67P4...
On 11/6/25 01:33, Vasilenko Eduard wrote:
Hi Marting, All your messages are true. But these are not all the complexities. Read here (if you like)https://datatracker.ietf.org/doc/html/draft-fbnvv-v6ops-site-multihoming-03. to see how deep is the rabbit hole and why it is better not to touch it.
While I have not read that entire draft, I'm familiar with most of the challenges it espouses, and they are indeed issues to deal with. However, what you seem to be missing is that, IF you are willing to deal with what is essentially the status quo in IPv4 when not doing true multi-homing using BGP or similar (broken end-to-end connectivity and/or address translation that changes without notification to hosts behind the border router), you can do the SAME THING in IPv6. We try not to because IPv6 lets us do things in potentially BETTER ways, specifically in ways that attempt to preserve end-to-end connectivity and notify hosts about addressing changes, but that's up to you as a network administrator. Indeed, that draft mentions both ULA+NPT66 and ULA+NAT66 as options and discusses the upsides and downsides of them noting that they basically mimic the present-day situation with IPv4 including the known downsides. Only if you want to dynamically change the addressing that hosts see on their interfaces do you run into issues that are unique to IPv6 (unless you're one of the presumably vanishingly few people doing that with public IPv4 addresses from multiple carriers). There are upsides to making that work, but you don't have to, and you, as network administrator, get to choose what you do. In fact, the only mechanisms that paper mentions that AREN'T essentially identical to the status quo with IPv4 are the PA-based mechanism using adjustable RA timers on the LAN and NPT44, and both of these are only because either you can't do it at all with IPv4 (the former) or because there's no interest (the former again, plus NPT44 is a thing just not commonly used in this application due to address-space runout). There are also approaches commonly referred to collectively as "SD-WAN" that aren't discussed in that draft that are ALSO used with IPv4 and that are directly applicable to IPv6. The most obvious one is to tunnel all your traffic to a (hopefully) nearby endpoint with true (BGP-based) multi-homed connectivity and use some hidden mechanism to choose which local connection (for which BGP-based multi-homing is presumably not viable) sees the tunneled traffic. There's multiple ways to approach a problem, and the one I'm generally least fond of is "proclaim the problem intractable", but I guess the "your network, your choice" philosophy applies there, too. The number of approaches available on IPv6 to solve this problem is indeed higher than at least the practical number of approaches available on IPv4 due to the more flexible nature of IPv6, but the solutions themselves don't necessarily have higher complexity. -- Brandon Martin
In-line comments. -----Original Message----- From: Brandon Martin via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 18:43 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Brandon Martin <lists.nanog@monmotha.net> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 11/6/25 01:33, Vasilenko Eduard wrote:
Hi Marting, All your messages are true. But these are not all the complexities. Read here (if you like)https://datatracker.ietf.org/doc/html/draft-fbnvv-v6ops-site-multihoming-03. to see how deep is the rabbit hole and why it is better not to touch it.
While I have not read that entire draft, I'm familiar with most of the challenges it espouses, and they are indeed issues to deal with. However, what you seem to be missing is that, IF you are willing to deal with what is essentially the status quo in IPv4 when not doing true multi-homing using BGP or similar (broken end-to-end connectivity and/or address translation that changes without notification to hosts behind the border router), you can do the SAME THING in IPv6. [EV:] Not at all. One very big company has blocked DHCP on all mobiles (inside chipset). Hence, it is not possible to delegate IPv6 prefix behind mobile link. Hence, E2E IPv6 story is broken. At the same time, IETF doing everything possible to block NAT in any form. NAT is the primary method for SMB/SOHO in IPv4. Another one big company (or the same?) has blocked DHCP on the major mobile OS. You have to use IPX-style SLAAC. And so on. IPv6 is very aggressive in the attempt to "change the world". Telco people has found a work-around for this: they have put subscriber inside the tunnel and disabled all complexities because it is P2P. We try not to because IPv6 lets us do things in potentially BETTER ways, specifically in ways that attempt to preserve end-to-end connectivity and notify hosts about addressing changes, but that's up to you as a network administrator. [EV:] You see - it is what I am talking about. Small group of people know how would be "BETTER". IMHO: this group already isolated themselves. Indeed, that draft mentions both ULA+NPT66 and ULA+NAT66 as options and discusses the upsides and downsides of them noting that they basically mimic the present-day situation with IPv4 including the known downsides. [EV:] The draft would be never published because it mentions all options, but IETF consensus is "to be silent about any form of NAT and cancel it from all documents". It one of the 3 major factors that push me to believe that IPv6 would not be accepted by businesses. Actually, IPv6 IETF people are effectively blocking themselves. Only if you want to dynamically change the addressing that hosts see on their interfaces do you run into issues that are unique to IPv6 (unless you're one of the presumably vanishingly few people doing that with public IPv4 addresses from multiple carriers). There are upsides to making that work, but you don't have to, and you, as network administrator, get to choose what you do. [EV:] For the IPv6 mandatory E2E story, you have to have dynamic IP addresses, because you have to renumber your network automatically after the uplink is lost, because the prefix was delegated from the Telco. IPv6 addresses are ephemeral for small businesses and many branches of big businesses. In fact, the only mechanisms that paper mentions that AREN'T essentially identical to the status quo with IPv4 are the PA-based mechanism using adjustable RA timers on the LAN and NPT44, and both of these are only because either you can't do it at all with IPv4 (the former) or because there's no interest (the former again, plus NPT44 is a thing just not commonly used in this application due to address-space runout). [EV:] Of cause not identical. IPv6 is much more complex - it has much more options and a few order of magnitudes more challenges. There are also approaches commonly referred to collectively as "SD-WAN" that aren't discussed in that draft that are ALSO used with IPv4 and that are directly applicable to IPv6. The most obvious one is to tunnel all your traffic to a (hopefully) nearby endpoint with true (BGP-based) multi-homed connectivity and use some hidden mechanism to choose which local connection (for which BGP-based multi-homing is presumably not viable) sees the tunneled traffic. [EV:] They are discussed - It is section 5.3 (more general). Yet, the specific corner case "SD-WAN" was not mentioned - it is a point for improvement, people may search specifically for it. There's multiple ways to approach a problem, and the one I'm generally least fond of is "proclaim the problem intractable", but I guess the "your network, your choice" philosophy applies there, too. [EV:] I predict that business people would choose to stay on IPv4. The number of approaches available on IPv6 to solve this problem is indeed higher than at least the practical number of approaches available on IPv4 due to the more flexible nature of IPv6, but the solutions themselves don't necessarily have higher complexity. -- Brandon Martin _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZE6YQY2T...
One very big company has blocked DHCP on all mobiles (inside chipset). Hence, it is not possible to delegate IPv6 prefix behind mobile link. Hence, E2E IPv6 story is broken.
Why don't you name the company / companies involved in this? That is just a random statement with nothing to back it up. While I get your argument about businesses moving towards ipv6 slowly, the bottom line is that forget the complexities, 95% of businesses have a less complicated setup than me. They plug in the router from the provider, they get ipv4+ipv6 and their network just works. a coffee shop or a flower shop doesn't need or care about BGP. The bottom line is NAT is shit. The only reason it ever needed to exist is because we ran out of ipv4. It really is that simple. Port forwarding (in the context of NAT44) should die a slow death. On Fri, Nov 7, 2025 at 2:06 AM Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote:
In-line comments.
-----Original Message----- From: Brandon Martin via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 18:43 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Brandon Martin <lists.nanog@monmotha.net> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
On 11/6/25 01:33, Vasilenko Eduard wrote:
Hi Marting, All your messages are true. But these are not all the complexities. Read here (if you like) https://datatracker.ietf.org/doc/html/draft-fbnvv-v6ops-site-multihoming-03 . to see how deep is the rabbit hole and why it is better not to touch it.
While I have not read that entire draft, I'm familiar with most of the challenges it espouses, and they are indeed issues to deal with.
However, what you seem to be missing is that, IF you are willing to deal with what is essentially the status quo in IPv4 when not doing true multi-homing using BGP or similar (broken end-to-end connectivity and/or address translation that changes without notification to hosts behind the border router), you can do the SAME THING in IPv6. [EV:] Not at all. One very big company has blocked DHCP on all mobiles (inside chipset). Hence, it is not possible to delegate IPv6 prefix behind mobile link. Hence, E2E IPv6 story is broken. At the same time, IETF doing everything possible to block NAT in any form. NAT is the primary method for SMB/SOHO in IPv4. Another one big company (or the same?) has blocked DHCP on the major mobile OS. You have to use IPX-style SLAAC. And so on. IPv6 is very aggressive in the attempt to "change the world". Telco people has found a work-around for this: they have put subscriber inside the tunnel and disabled all complexities because it is P2P.
We try not to because IPv6 lets us do things in potentially BETTER ways, specifically in ways that attempt to preserve end-to-end connectivity and notify hosts about addressing changes, but that's up to you as a network administrator. [EV:] You see - it is what I am talking about. Small group of people know how would be "BETTER". IMHO: this group already isolated themselves.
Indeed, that draft mentions both ULA+NPT66 and ULA+NAT66 as options and discusses the upsides and downsides of them noting that they basically mimic the present-day situation with IPv4 including the known downsides. [EV:] The draft would be never published because it mentions all options, but IETF consensus is "to be silent about any form of NAT and cancel it from all documents". It one of the 3 major factors that push me to believe that IPv6 would not be accepted by businesses. Actually, IPv6 IETF people are effectively blocking themselves.
Only if you want to dynamically change the addressing that hosts see on their interfaces do you run into issues that are unique to IPv6 (unless you're one of the presumably vanishingly few people doing that with public IPv4 addresses from multiple carriers). There are upsides to making that work, but you don't have to, and you, as network administrator, get to choose what you do. [EV:] For the IPv6 mandatory E2E story, you have to have dynamic IP addresses, because you have to renumber your network automatically after the uplink is lost, because the prefix was delegated from the Telco. IPv6 addresses are ephemeral for small businesses and many branches of big businesses.
In fact, the only mechanisms that paper mentions that AREN'T essentially identical to the status quo with IPv4 are the PA-based mechanism using adjustable RA timers on the LAN and NPT44, and both of these are only because either you can't do it at all with IPv4 (the former) or because there's no interest (the former again, plus NPT44 is a thing just not commonly used in this application due to address-space runout). [EV:] Of cause not identical. IPv6 is much more complex - it has much more options and a few order of magnitudes more challenges.
There are also approaches commonly referred to collectively as "SD-WAN" that aren't discussed in that draft that are ALSO used with IPv4 and that are directly applicable to IPv6. The most obvious one is to tunnel all your traffic to a (hopefully) nearby endpoint with true (BGP-based) multi-homed connectivity and use some hidden mechanism to choose which local connection (for which BGP-based multi-homing is presumably not viable) sees the tunneled traffic. [EV:] They are discussed - It is section 5.3 (more general). Yet, the specific corner case "SD-WAN" was not mentioned - it is a point for improvement, people may search specifically for it.
There's multiple ways to approach a problem, and the one I'm generally least fond of is "proclaim the problem intractable", but I guess the "your network, your choice" philosophy applies there, too. [EV:] I predict that business people would choose to stay on IPv4.
The number of approaches available on IPv6 to solve this problem is indeed higher than at least the practical number of approaches available on IPv4 due to the more flexible nature of IPv6, but the solutions themselves don't necessarily have higher complexity.
-- Brandon Martin _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZE6YQY2T... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MOY3VCUH...
On 2025-11-07 07:37, Javier J via NANOG wrote:
One very big company has blocked DHCP on all mobiles (inside chipset). Hence, it is not possible to delegate IPv6 prefix behind mobile link. Hence, E2E IPv6 story is broken.
Why don't you name the company / companies involved in this? That is just a random statement with nothing to back it up. While I get your argument about businesses moving towards ipv6 slowly, the bottom line is that forget the complexities, 95% of businesses have a less complicated setup than me. They plug in the router from the provider, they get ipv4+ipv6 and their network just works. a coffee shop or a flower shop doesn't need or care about BGP.
The bottom line is NAT is shit. The only reason it ever needed to exist is because we ran out of ipv4. It really is that simple.
Port forwarding (in the context of NAT44) should die a slow death. It already is. Isn't it? :-)
On Fri, Nov 7, 2025 at 2:06 AM Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote:
In-line comments.
-----Original Message----- From: Brandon Martin via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 18:43 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Brandon Martin <lists.nanog@monmotha.net> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
On 11/6/25 01:33, Vasilenko Eduard wrote:
Hi Marting, All your messages are true. But these are not all the complexities. Read here (if you like) https://datatracker.ietf.org/doc/html/draft-fbnvv-v6ops-site-multihoming-03 . to see how deep is the rabbit hole and why it is better not to touch it.
While I have not read that entire draft, I'm familiar with most of the challenges it espouses, and they are indeed issues to deal with.
However, what you seem to be missing is that, IF you are willing to deal with what is essentially the status quo in IPv4 when not doing true multi-homing using BGP or similar (broken end-to-end connectivity and/or address translation that changes without notification to hosts behind the border router), you can do the SAME THING in IPv6. [EV:] Not at all. One very big company has blocked DHCP on all mobiles (inside chipset). Hence, it is not possible to delegate IPv6 prefix behind mobile link. Hence, E2E IPv6 story is broken. At the same time, IETF doing everything possible to block NAT in any form. NAT is the primary method for SMB/SOHO in IPv4. Another one big company (or the same?) has blocked DHCP on the major mobile OS. You have to use IPX-style SLAAC. And so on. IPv6 is very aggressive in the attempt to "change the world". Telco people has found a work-around for this: they have put subscriber inside the tunnel and disabled all complexities because it is P2P.
We try not to because IPv6 lets us do things in potentially BETTER ways, specifically in ways that attempt to preserve end-to-end connectivity and notify hosts about addressing changes, but that's up to you as a network administrator. [EV:] You see - it is what I am talking about. Small group of people know how would be "BETTER". IMHO: this group already isolated themselves.
Indeed, that draft mentions both ULA+NPT66 and ULA+NAT66 as options and discusses the upsides and downsides of them noting that they basically mimic the present-day situation with IPv4 including the known downsides. [EV:] The draft would be never published because it mentions all options, but IETF consensus is "to be silent about any form of NAT and cancel it from all documents". It one of the 3 major factors that push me to believe that IPv6 would not be accepted by businesses. Actually, IPv6 IETF people are effectively blocking themselves.
Only if you want to dynamically change the addressing that hosts see on their interfaces do you run into issues that are unique to IPv6 (unless you're one of the presumably vanishingly few people doing that with public IPv4 addresses from multiple carriers). There are upsides to making that work, but you don't have to, and you, as network administrator, get to choose what you do. [EV:] For the IPv6 mandatory E2E story, you have to have dynamic IP addresses, because you have to renumber your network automatically after the uplink is lost, because the prefix was delegated from the Telco. IPv6 addresses are ephemeral for small businesses and many branches of big businesses.
In fact, the only mechanisms that paper mentions that AREN'T essentially identical to the status quo with IPv4 are the PA-based mechanism using adjustable RA timers on the LAN and NPT44, and both of these are only because either you can't do it at all with IPv4 (the former) or because there's no interest (the former again, plus NPT44 is a thing just not commonly used in this application due to address-space runout). [EV:] Of cause not identical. IPv6 is much more complex - it has much more options and a few order of magnitudes more challenges.
There are also approaches commonly referred to collectively as "SD-WAN" that aren't discussed in that draft that are ALSO used with IPv4 and that are directly applicable to IPv6. The most obvious one is to tunnel all your traffic to a (hopefully) nearby endpoint with true (BGP-based) multi-homed connectivity and use some hidden mechanism to choose which local connection (for which BGP-based multi-homing is presumably not viable) sees the tunneled traffic. [EV:] They are discussed - It is section 5.3 (more general). Yet, the specific corner case "SD-WAN" was not mentioned - it is a point for improvement, people may search specifically for it.
There's multiple ways to approach a problem, and the one I'm generally least fond of is "proclaim the problem intractable", but I guess the "your network, your choice" philosophy applies there, too. [EV:] I predict that business people would choose to stay on IPv4.
The number of approaches available on IPv6 to solve this problem is indeed higher than at least the practical number of approaches available on IPv4 due to the more flexible nature of IPv6, but the solutions themselves don't necessarily have higher complexity.
-- Brandon Martin _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZE6YQY2T... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MOY3VCUH...
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/WTPLHRHM...
Port forwarding (in the context of NAT44) should die a slow death. It already is. Isn't it? :-)
It is in everything I touch :-) On Fri, Nov 7, 2025 at 3:22 PM Chris via NANOG <nanog@lists.nanog.org> wrote:
One very big company has blocked DHCP on all mobiles (inside chipset). Hence, it is not possible to delegate IPv6 prefix behind mobile link. Hence, E2E IPv6 story is broken.
Why don't you name the company / companies involved in this? That is just a random statement with nothing to back it up. While I get your argument about businesses moving towards ipv6 slowly,
bottom line is that forget the complexities, 95% of businesses have a less complicated setup than me. They plug in the router from the provider,
On 2025-11-07 07:37, Javier J via NANOG wrote: the they
get ipv4+ipv6 and their network just works. a coffee shop or a flower shop doesn't need or care about BGP.
The bottom line is NAT is shit. The only reason it ever needed to exist is because we ran out of ipv4. It really is that simple.
Port forwarding (in the context of NAT44) should die a slow death. It already is. Isn't it? :-)
On Fri, Nov 7, 2025 at 2:06 AM Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote:
In-line comments.
-----Original Message----- From: Brandon Martin via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 18:43 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Brandon Martin <lists.nanog@monmotha.net> Subject: Re: Artificial Juniper SRX limitations preventing IPv6
(and sales)
On 11/6/25 01:33, Vasilenko Eduard wrote:
Hi Marting, All your messages are true. But these are not all the complexities. Read here (if you like)
https://datatracker.ietf.org/doc/html/draft-fbnvv-v6ops-site-multihoming-03
.
to see how deep is the rabbit hole and why it is better not to touch it.
While I have not read that entire draft, I'm familiar with most of the challenges it espouses, and they are indeed issues to deal with.
However, what you seem to be missing is that, IF you are willing to deal with what is essentially the status quo in IPv4 when not doing true multi-homing using BGP or similar (broken end-to-end connectivity and/or address translation that changes without notification to hosts behind
border router), you can do the SAME THING in IPv6. [EV:] Not at all. One very big company has blocked DHCP on all mobiles (inside chipset). Hence, it is not possible to delegate IPv6 prefix behind mobile link. Hence, E2E IPv6 story is broken. At the same time, IETF doing everything possible to block NAT in any
NAT is the primary method for SMB/SOHO in IPv4. Another one big company (or the same?) has blocked DHCP on the major mobile OS. You have to use IPX-style SLAAC. And so on. IPv6 is very aggressive in the attempt to "change the world". Telco people has found a work-around for this: they have put subscriber inside the tunnel and disabled all complexities because it is P2P.
We try not to because IPv6 lets us do things in potentially BETTER ways, specifically in ways that attempt to preserve end-to-end connectivity and notify hosts about addressing changes, but that's up to you as a network administrator. [EV:] You see - it is what I am talking about. Small group of people know how would be "BETTER". IMHO: this group already isolated themselves.
Indeed, that draft mentions both ULA+NPT66 and ULA+NAT66 as options and discusses the upsides and downsides of them noting that they basically mimic the present-day situation with IPv4 including the known downsides. [EV:] The draft would be never published because it mentions all
but IETF consensus is "to be silent about any form of NAT and cancel it from all documents". It one of the 3 major factors that push me to believe that IPv6 would not be accepted by businesses. Actually, IPv6 IETF people are effectively blocking themselves.
Only if you want to dynamically change the addressing that hosts see on their interfaces do you run into issues that are unique to IPv6 (unless you're one of the presumably vanishingly few people doing that with
IPv4 addresses from multiple carriers). There are upsides to making
work, but you don't have to, and you, as network administrator, get to choose what you do. [EV:] For the IPv6 mandatory E2E story, you have to have dynamic IP addresses, because you have to renumber your network automatically after the uplink is lost, because the prefix was delegated from the Telco. IPv6 addresses are ephemeral for small businesses and many branches of big businesses.
In fact, the only mechanisms that paper mentions that AREN'T essentially identical to the status quo with IPv4 are the PA-based mechanism using adjustable RA timers on the LAN and NPT44, and both of these are only because either you can't do it at all with IPv4 (the former) or because there's no interest (the former again, plus NPT44 is a thing just not commonly used in this application due to address-space runout). [EV:] Of cause not identical. IPv6 is much more complex - it has much more options and a few order of magnitudes more challenges.
There are also approaches commonly referred to collectively as "SD-WAN" that aren't discussed in that draft that are ALSO used with IPv4 and
deployment the form. options, public that that
are directly applicable to IPv6. The most obvious one is to tunnel all your traffic to a (hopefully) nearby endpoint with true (BGP-based) multi-homed connectivity and use some hidden mechanism to choose which local connection (for which BGP-based multi-homing is presumably not viable) sees the tunneled traffic. [EV:] They are discussed - It is section 5.3 (more general). Yet, the specific corner case "SD-WAN" was not mentioned - it is a point for improvement, people may search specifically for it.
There's multiple ways to approach a problem, and the one I'm generally least fond of is "proclaim the problem intractable", but I guess the "your network, your choice" philosophy applies there, too. [EV:] I predict that business people would choose to stay on IPv4.
The number of approaches available on IPv6 to solve this problem is indeed higher than at least the practical number of approaches available on IPv4 due to the more flexible nature of IPv6, but the solutions themselves don't necessarily have higher complexity.
-- Brandon Martin _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZE6YQY2T...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MOY3VCUH...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/WTPLHRHM... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LOG7TKVA...
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 9:57 PM, Javier J via NANOG <nanog@lists.nanog.org> wrote: Port forwarding (in the context of NAT44) should die a slow death. It already is. Isn't it? :-) It is in everything I touch :-) On Fri, Nov 7, 2025 at 3:22 PM Chris via NANOG <nanog@lists.nanog.org> wrote: On 2025-11-07 07:37, Javier J via NANOG wrote: One very big company has blocked DHCP on all mobiles (inside chipset). Hence, it is not possible to delegate IPv6 prefix behind mobile link. Hence, E2E IPv6 story is broken. Why don't you name the company / companies involved in this? That is just a random statement with nothing to back it up. While I get your argument about businesses moving towards ipv6 slowly, the bottom line is that forget the complexities, 95% of businesses have a less complicated setup than me. They plug in the router from the provider, they get ipv4+ipv6 and their network just works. a coffee shop or a flower shop doesn't need or care about BGP. The bottom line is NAT is shit. The only reason it ever needed to exist is because we ran out of ipv4. It really is that simple. Port forwarding (in the context of NAT44) should die a slow death. It already is. Isn't it? :-) On Fri, Nov 7, 2025 at 2:06 AM Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote: In-line comments. -----Original Message----- From: Brandon Martin via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 18:43 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Brandon Martin <lists.nanog@monmotha.net> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 11/6/25 01:33, Vasilenko Eduard wrote: Hi Marting, All your messages are true. But these are not all the complexities. Read here (if you like) https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-fbnv... [datatracker[.]ietf[.]org] . to see how deep is the rabbit hole and why it is better not to touch it. While I have not read that entire draft, I'm familiar with most of the challenges it espouses, and they are indeed issues to deal with. However, what you seem to be missing is that, IF you are willing to deal with what is essentially the status quo in IPv4 when not doing true multi-homing using BGP or similar (broken end-to-end connectivity and/or address translation that changes without notification to hosts behind the border router), you can do the SAME THING in IPv6. [EV:] Not at all. One very big company has blocked DHCP on all mobiles (inside chipset). Hence, it is not possible to delegate IPv6 prefix behind mobile link. Hence, E2E IPv6 story is broken. At the same time, IETF doing everything possible to block NAT in any form. NAT is the primary method for SMB/SOHO in IPv4. Another one big company (or the same?) has blocked DHCP on the major mobile OS. You have to use IPX-style SLAAC. And so on. IPv6 is very aggressive in the attempt to "change the world". Telco people has found a work-around for this: they have put subscriber inside the tunnel and disabled all complexities because it is P2P. We try not to because IPv6 lets us do things in potentially BETTER ways, specifically in ways that attempt to preserve end-to-end connectivity and notify hosts about addressing changes, but that's up to you as a network administrator. [EV:] You see - it is what I am talking about. Small group of people know how would be "BETTER". IMHO: this group already isolated themselves. Indeed, that draft mentions both ULA+NPT66 and ULA+NAT66 as options and discusses the upsides and downsides of them noting that they basically mimic the present-day situation with IPv4 including the known downsides. [EV:] The draft would be never published because it mentions all options, but IETF consensus is "to be silent about any form of NAT and cancel it from all documents". It one of the 3 major factors that push me to believe that IPv6 would not be accepted by businesses. Actually, IPv6 IETF people are effectively blocking themselves. Only if you want to dynamically change the addressing that hosts see on their interfaces do you run into issues that are unique to IPv6 (unless you're one of the presumably vanishingly few people doing that with public IPv4 addresses from multiple carriers). There are upsides to making that work, but you don't have to, and you, as network administrator, get to choose what you do. [EV:] For the IPv6 mandatory E2E story, you have to have dynamic IP addresses, because you have to renumber your network automatically after the uplink is lost, because the prefix was delegated from the Telco. IPv6 addresses are ephemeral for small businesses and many branches of big businesses. In fact, the only mechanisms that paper mentions that AREN'T essentially identical to the status quo with IPv4 are the PA-based mechanism using adjustable RA timers on the LAN and NPT44, and both of these are only because either you can't do it at all with IPv4 (the former) or because there's no interest (the former again, plus NPT44 is a thing just not commonly used in this application due to address-space runout). [EV:] Of cause not identical. IPv6 is much more complex - it has much more options and a few order of magnitudes more challenges. There are also approaches commonly referred to collectively as "SD-WAN" that aren't discussed in that draft that are ALSO used with IPv4 and that are directly applicable to IPv6. The most obvious one is to tunnel all your traffic to a (hopefully) nearby endpoint with true (BGP-based) multi-homed connectivity and use some hidden mechanism to choose which local connection (for which BGP-based multi-homing is presumably not viable) sees the tunneled traffic. [EV:] They are discussed - It is section 5.3 (more general). Yet, the specific corner case "SD-WAN" was not mentioned - it is a point for improvement, people may search specifically for it. There's multiple ways to approach a problem, and the one I'm generally least fond of is "proclaim the problem intractable", but I guess the "your network, your choice" philosophy applies there, too. [EV:] I predict that business people would choose to stay on IPv4. The number of approaches available on IPv6 to solve this problem is indeed higher than at least the practical number of approaches available on IPv4 due to the more flexible nature of IPv6, but the solutions themselves don't necessarily have higher complexity. -- Brandon Martin _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 9:57 PM, Javier J via NANOG <nanog@lists.nanog.org> wrote: Port forwarding (in the context of NAT44) should die a slow death. It already is. Isn't it? :-) It is in everything I touch :-) On Fri, Nov 7, 2025 at 3:22 PM Chris via NANOG <nanog@lists.nanog.org> wrote: On 2025-11-07 07:37, Javier J via NANOG wrote: One very big company has blocked DHCP on all mobiles (inside chipset). Hence, it is not possible to delegate IPv6 prefix behind mobile link. Hence, E2E IPv6 story is broken. Why don't you name the company / companies involved in this? That is just a random statement with nothing to back it up. While I get your argument about businesses moving towards ipv6 slowly, the bottom line is that forget the complexities, 95% of businesses have a less complicated setup than me. They plug in the router from the provider, they get ipv4+ipv6 and their network just works. a coffee shop or a flower shop doesn't need or care about BGP. The bottom line is NAT is shit. The only reason it ever needed to exist is because we ran out of ipv4. It really is that simple. Port forwarding (in the context of NAT44) should die a slow death. It already is. Isn't it? :-) On Fri, Nov 7, 2025 at 2:06 AM Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote: In-line comments. -----Original Message----- From: Brandon Martin via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 18:43 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Brandon Martin <lists.nanog@monmotha.net> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 11/6/25 01:33, Vasilenko Eduard wrote: Hi Marting, All your messages are true. But these are not all the complexities. Read here (if you like) https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-fbnv... [datatracker[.]ietf[.]org] . to see how deep is the rabbit hole and why it is better not to touch it. While I have not read that entire draft, I'm familiar with most of the challenges it espouses, and they are indeed issues to deal with. However, what you seem to be missing is that, IF you are willing to deal with what is essentially the status quo in IPv4 when not doing true multi-homing using BGP or similar (broken end-to-end connectivity and/or address translation that changes without notification to hosts behind the border router), you can do the SAME THING in IPv6. [EV:] Not at all. One very big company has blocked DHCP on all mobiles (inside chipset). Hence, it is not possible to delegate IPv6 prefix behind mobile link. Hence, E2E IPv6 story is broken. At the same time, IETF doing everything possible to block NAT in any form. NAT is the primary method for SMB/SOHO in IPv4. Another one big company (or the same?) has blocked DHCP on the major mobile OS. You have to use IPX-style SLAAC. And so on. IPv6 is very aggressive in the attempt to "change the world". Telco people has found a work-around for this: they have put subscriber inside the tunnel and disabled all complexities because it is P2P. We try not to because IPv6 lets us do things in potentially BETTER ways, specifically in ways that attempt to preserve end-to-end connectivity and notify hosts about addressing changes, but that's up to you as a network administrator. [EV:] You see - it is what I am talking about. Small group of people know how would be "BETTER". IMHO: this group already isolated themselves. Indeed, that draft mentions both ULA+NPT66 and ULA+NAT66 as options and discusses the upsides and downsides of them noting that they basically mimic the present-day situation with IPv4 including the known downsides. [EV:] The draft would be never published because it mentions all options, but IETF consensus is "to be silent about any form of NAT and cancel it from all documents". It one of the 3 major factors that push me to believe that IPv6 would not be accepted by businesses. Actually, IPv6 IETF people are effectively blocking themselves. Only if you want to dynamically change the addressing that hosts see on their interfaces do you run into issues that are unique to IPv6 (unless you're one of the presumably vanishingly few people doing that with public IPv4 addresses from multiple carriers). There are upsides to making that work, but you don't have to, and you, as network administrator, get to choose what you do. [EV:] For the IPv6 mandatory E2E story, you have to have dynamic IP addresses, because you have to renumber your network automatically after the uplink is lost, because the prefix was delegated from the Telco. IPv6 addresses are ephemeral for small businesses and many branches of big businesses. In fact, the only mechanisms that paper mentions that AREN'T essentially identical to the status quo with IPv4 are the PA-based mechanism using adjustable RA timers on the LAN and NPT44, and both of these are only because either you can't do it at all with IPv4 (the former) or because there's no interest (the former again, plus NPT44 is a thing just not commonly used in this application due to address-space runout). [EV:] Of cause not identical. IPv6 is much more complex - it has much more options and a few order of magnitudes more challenges. There are also approaches commonly referred to collectively as "SD-WAN" that aren't discussed in that draft that are ALSO used with IPv4 and that are directly applicable to IPv6. The most obvious one is to tunnel all your traffic to a (hopefully) nearby endpoint with true (BGP-based) multi-homed connectivity and use some hidden mechanism to choose which local connection (for which BGP-based multi-homing is presumably not viable) sees the tunneled traffic. [EV:] They are discussed - It is section 5.3 (more general). Yet, the specific corner case "SD-WAN" was not mentioned - it is a point for improvement, people may search specifically for it. There's multiple ways to approach a problem, and the one I'm generally least fond of is "proclaim the problem intractable", but I guess the "your network, your choice" philosophy applies there, too. [EV:] I predict that business people would choose to stay on IPv4. The number of approaches available on IPv6 to solve this problem is indeed higher than at least the practical number of approaches available on IPv4 due to the more flexible nature of IPv6, but the solutions themselves don't necessarily have higher complexity. -- Brandon Martin _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
Hi all. I've let Samaneh know re the messages and she was just getting on a flight. She will fix as soon as she lands and gets near a computer. She send profuse apologies. - merike
On Nov 10, 2025, at 8:55 AM, Merike Kaeo via NANOG <nanog@lists.nanog.org> wrote:
Hi all.
I've let Samaneh know re the messages and she was just getting on a flight. She will fix as soon as she lands and gets near a computer. She send profuse apologies.
Thanks. I tried calling and leaving a message but I’m near certain it went to the wrong place.
The subscribers email address delivery status was disabled, and email address banned temporarily, till they are able to update their autoresponder. The postfix queued messages containing their email address was also flushed out. I cannot stop the emails that are already sent out. I apologize for this happening as long as it did, this started happening around 4:30AM pacific this morning while I was sleeping. Ryan Hamel ________________________________ From: Daniel Seagraves via NANOG <nanog@lists.nanog.org> Sent: Monday, November 10, 2025 7:07 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Daniel Seagraves <dseagrav@humancapitaldev.com> Subject: Re: Samaneh's away messages Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments.
On Nov 10, 2025, at 8:55 AM, Merike Kaeo via NANOG <nanog@lists.nanog.org> wrote:
Hi all.
I've let Samaneh know re the messages and she was just getting on a flight. She will fix as soon as she lands and gets near a computer. She send profuse apologies.
Thanks. I tried calling and leaving a message but I’m near certain it went to the wrong place. _______________________________________________ NANOG mailing list https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2FRCYS6JDEV33DKBTEABDW7KIEA2YOFFRQ%2F&data=05%7C02%7Cryan%40rkhtech.org%7Cce1bd8e36c4d4c35f11f08de206ae9bc%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638983840782587673%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=KSB%2BBp8VFuNYxFEHJrufOzftvHmEQJJOSZzff%2BoVWLw%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RCYS6JDEV33DKBTEABDW7KIEA2YOFFRQ/>
Thanks for all your help, Ryan! Don’t sweat it, clients/devices have easy ways to suppress notifications. I’m sure we all knew it would get taken cared of at some point this morning. Regards, Cory -------- Original Message -------- On Monday, 11/10/25 at 09:22 Ryan Hamel via NANOG <nanog@lists.nanog.org> wrote: The subscribers email address delivery status was disabled, and email address banned temporarily, till they are able to update their autoresponder. The postfix queued messages containing their email address was also flushed out. I cannot stop the emails that are already sent out. I apologize for this happening as long as it did, this started happening around 4:30AM pacific this morning while I was sleeping. Ryan Hamel ________________________________ From: Daniel Seagraves via NANOG <nanog@lists.nanog.org> Sent: Monday, November 10, 2025 7:07 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Daniel Seagraves <dseagrav@humancapitaldev.com> Subject: Re: Samaneh's away messages Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments.
On Nov 10, 2025, at 8:55 AM, Merike Kaeo via NANOG <nanog@lists.nanog.org> wrote:
Hi all.
I've let Samaneh know re the messages and she was just getting on a flight. She will fix as soon as she lands and gets near a computer. She send profuse apologies.
Thanks. I tried calling and leaving a message but I’m near certain it went to the wrong place. _______________________________________________ NANOG mailing list https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2FRCYS6JDEV33DKBTEABDW7KIEA2YOFFRQ%2F&data=05%7C02%7Cryan%40rkhtech.org%7Cce1bd8e36c4d4c35f11f08de206ae9bc%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638983840782587673%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=KSB%2BBp8VFuNYxFEHJrufOzftvHmEQJJOSZzff%2BoVWLw%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RCYS6JDEV33DKBTEABDW7KIEA2YOFFRQ/> _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7EWRIDIL...
Hi Marting, All your messages are true. But these are not all the complexities. Read here (if you like) https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-fbnv... [datatracker[.]ietf[.]org] . to see how deep is the rabbit hole and why it is better not to touch it. While I have not read that entire draft, I'm familiar with most of the challenges it espouses, and they are indeed issues to deal with. However, what you seem to be missing is that, IF you are willing to deal with what is essentially the status quo in IPv4 when not doing true multi-homing using BGP or similar (broken end-to-end connectivity and/or address translation that changes without notification to hosts behind the border router), you can do the SAME THING in IPv6. [EV:] Not at all. One very big company has blocked DHCP on all mobiles (inside chipset). Hence, it is not possible to delegate IPv6 prefix behind mobile link. Hence, E2E IPv6 story is broken. At the same time, IETF doing everything possible to block NAT in any form. NAT is the primary method for SMB/SOHO in IPv4. Another one big company (or the same?) has blocked DHCP on the major mobile OS. You have to use IPX-style SLAAC. And so on. IPv6 is very aggressive in the attempt to "change the world". Telco people has found a work-around for this: they have put subscriber inside the tunnel and disabled all complexities because it is P2P. We try not to because IPv6 lets us do things in potentially BETTER ways, specifically in ways that attempt to preserve end-to-end connectivity and notify hosts about addressing changes, but that's up to you as a network administrator. [EV:] You see - it is what I am talking about. Small group of people know how would be "BETTER". IMHO: this group already isolated themselves. Indeed, that draft mentions both ULA+NPT66 and ULA+NAT66 as options and discusses the upsides and downsides of them noting that they basically mimic the present-day situation with IPv4 including the known downsides. [EV:] The draft would be never published because it mentions all options, but IETF consensus is "to be silent about any form of NAT and cancel it from all documents". It one of the 3 major factors that push me to believe that IPv6 would not be accepted by businesses. Actually, IPv6 IETF people are effectively blocking themselves. Only if you want to dynamically change the addressing that hosts see on
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 9:21 PM, Chris via NANOG <nanog@lists.nanog.org> wrote: On 2025-11-07 07:37, Javier J via NANOG wrote: One very big company has blocked DHCP on all mobiles (inside chipset). Hence, it is not possible to delegate IPv6 prefix behind mobile link. Hence, E2E IPv6 story is broken. Why don't you name the company / companies involved in this? That is just a random statement with nothing to back it up. While I get your argument about businesses moving towards ipv6 slowly, the bottom line is that forget the complexities, 95% of businesses have a less complicated setup than me. They plug in the router from the provider, they get ipv4+ipv6 and their network just works. a coffee shop or a flower shop doesn't need or care about BGP. The bottom line is NAT is shit. The only reason it ever needed to exist is because we ran out of ipv4. It really is that simple. Port forwarding (in the context of NAT44) should die a slow death. It already is. Isn't it? :-) On Fri, Nov 7, 2025 at 2:06 AM Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote: In-line comments. -----Original Message----- From: Brandon Martin via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 18:43 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Brandon Martin <lists.nanog@monmotha.net> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 11/6/25 01:33, Vasilenko Eduard wrote: their interfaces do you run into issues that are unique to IPv6 (unless you're one of the presumably vanishingly few people doing that with public IPv4 addresses from multiple carriers). There are upsides to making that work, but you don't have to, and you, as network administrator, get to choose what you do. [EV:] For the IPv6 mandatory E2E story, you have to have dynamic IP addresses, because you have to renumber your network automatically after the uplink is lost, because the prefix was delegated from the Telco. IPv6 addresses are ephemeral for small businesses and many branches of big businesses. In fact, the only mechanisms that paper mentions that AREN'T essentially identical to the status quo with IPv4 are the PA-based mechanism using adjustable RA timers on the LAN and NPT44, and both of these are only because either you can't do it at all with IPv4 (the former) or because there's no interest (the former again, plus NPT44 is a thing just not commonly used in this application due to address-space runout). [EV:] Of cause not identical. IPv6 is much more complex - it has much more options and a few order of magnitudes more challenges. There are also approaches commonly referred to collectively as "SD-WAN" that aren't discussed in that draft that are ALSO used with IPv4 and that are directly applicable to IPv6. The most obvious one is to tunnel all your traffic to a (hopefully) nearby endpoint with true (BGP-based) multi-homed connectivity and use some hidden mechanism to choose which local connection (for which BGP-based multi-homing is presumably not viable) sees the tunneled traffic. [EV:] They are discussed - It is section 5.3 (more general). Yet, the specific corner case "SD-WAN" was not mentioned - it is a point for improvement, people may search specifically for it. There's multiple ways to approach a problem, and the one I'm generally least fond of is "proclaim the problem intractable", but I guess the "your network, your choice" philosophy applies there, too. [EV:] I predict that business people would choose to stay on IPv4. The number of approaches available on IPv6 to solve this problem is indeed higher than at least the practical number of approaches available on IPv4 due to the more flexible nature of IPv6, but the solutions themselves don't necessarily have higher complexity. -- Brandon Martin _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 9:21 PM, Chris via NANOG <nanog@lists.nanog.org> wrote: On 2025-11-07 07:37, Javier J via NANOG wrote: One very big company has blocked DHCP on all mobiles (inside chipset). Hence, it is not possible to delegate IPv6 prefix behind mobile link. Hence, E2E IPv6 story is broken. Why don't you name the company / companies involved in this? That is just a random statement with nothing to back it up. While I get your argument about businesses moving towards ipv6 slowly, the bottom line is that forget the complexities, 95% of businesses have a less complicated setup than me. They plug in the router from the provider, they get ipv4+ipv6 and their network just works. a coffee shop or a flower shop doesn't need or care about BGP. The bottom line is NAT is shit. The only reason it ever needed to exist is because we ran out of ipv4. It really is that simple. Port forwarding (in the context of NAT44) should die a slow death. It already is. Isn't it? :-) On Fri, Nov 7, 2025 at 2:06 AM Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote: In-line comments. -----Original Message----- From: Brandon Martin via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 18:43 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Brandon Martin <lists.nanog@monmotha.net> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 11/6/25 01:33, Vasilenko Eduard wrote: Hi Marting, All your messages are true. But these are not all the complexities. Read here (if you like) https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-fbnv... [datatracker[.]ietf[.]org] . to see how deep is the rabbit hole and why it is better not to touch it. While I have not read that entire draft, I'm familiar with most of the challenges it espouses, and they are indeed issues to deal with. However, what you seem to be missing is that, IF you are willing to deal with what is essentially the status quo in IPv4 when not doing true multi-homing using BGP or similar (broken end-to-end connectivity and/or address translation that changes without notification to hosts behind the border router), you can do the SAME THING in IPv6. [EV:] Not at all. One very big company has blocked DHCP on all mobiles (inside chipset). Hence, it is not possible to delegate IPv6 prefix behind mobile link. Hence, E2E IPv6 story is broken. At the same time, IETF doing everything possible to block NAT in any form. NAT is the primary method for SMB/SOHO in IPv4. Another one big company (or the same?) has blocked DHCP on the major mobile OS. You have to use IPX-style SLAAC. And so on. IPv6 is very aggressive in the attempt to "change the world". Telco people has found a work-around for this: they have put subscriber inside the tunnel and disabled all complexities because it is P2P. We try not to because IPv6 lets us do things in potentially BETTER ways, specifically in ways that attempt to preserve end-to-end connectivity and notify hosts about addressing changes, but that's up to you as a network administrator. [EV:] You see - it is what I am talking about. Small group of people know how would be "BETTER". IMHO: this group already isolated themselves. Indeed, that draft mentions both ULA+NPT66 and ULA+NAT66 as options and discusses the upsides and downsides of them noting that they basically mimic the present-day situation with IPv4 including the known downsides. [EV:] The draft would be never published because it mentions all options, but IETF consensus is "to be silent about any form of NAT and cancel it from all documents". It one of the 3 major factors that push me to believe that IPv6 would not be accepted by businesses. Actually, IPv6 IETF people are effectively blocking themselves. Only if you want to dynamically change the addressing that hosts see on their interfaces do you run into issues that are unique to IPv6 (unless you're one of the presumably vanishingly few people doing that with public IPv4 addresses from multiple carriers). There are upsides to making that work, but you don't have to, and you, as network administrator, get to choose what you do. [EV:] For the IPv6 mandatory E2E story, you have to have dynamic IP addresses, because you have to renumber your network automatically after the uplink is lost, because the prefix was delegated from the Telco. IPv6 addresses are ephemeral for small businesses and many branches of big businesses. In fact, the only mechanisms that paper mentions that AREN'T essentially identical to the status quo with IPv4 are the PA-based mechanism using adjustable RA timers on the LAN and NPT44, and both of these are only because either you can't do it at all with IPv4 (the former) or because there's no interest (the former again, plus NPT44 is a thing just not commonly used in this application due to address-space runout). [EV:] Of cause not identical. IPv6 is much more complex - it has much more options and a few order of magnitudes more challenges. There are also approaches commonly referred to collectively as "SD-WAN" that aren't discussed in that draft that are ALSO used with IPv4 and that are directly applicable to IPv6. The most obvious one is to tunnel all your traffic to a (hopefully) nearby endpoint with true (BGP-based) multi-homed connectivity and use some hidden mechanism to choose which local connection (for which BGP-based multi-homing is presumably not viable) sees the tunneled traffic. [EV:] They are discussed - It is section 5.3 (more general). Yet, the specific corner case "SD-WAN" was not mentioned - it is a point for improvement, people may search specifically for it. There's multiple ways to approach a problem, and the one I'm generally least fond of is "proclaim the problem intractable", but I guess the "your network, your choice" philosophy applies there, too. [EV:] I predict that business people would choose to stay on IPv4. The number of approaches available on IPv6 to solve this problem is indeed higher than at least the practical number of approaches available on IPv4 due to the more flexible nature of IPv6, but the solutions themselves don't necessarily have higher complexity. -- Brandon Martin _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 4:37 PM, Javier J via NANOG <nanog@lists.nanog.org> wrote: One very big company has blocked DHCP on all mobiles (inside chipset). Hence, it is not possible to delegate IPv6 prefix behind mobile link. Hence, E2E IPv6 story is broken. Why don't you name the company / companies involved in this? That is just a random statement with nothing to back it up. While I get your argument about businesses moving towards ipv6 slowly, the bottom line is that forget the complexities, 95% of businesses have a less complicated setup than me. They plug in the router from the provider, they get ipv4+ipv6 and their network just works. a coffee shop or a flower shop doesn't need or care about BGP. The bottom line is NAT is shit. The only reason it ever needed to exist is because we ran out of ipv4. It really is that simple. Port forwarding (in the context of NAT44) should die a slow death. On Fri, Nov 7, 2025 at 2:06 AM Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote: In-line comments. -----Original Message----- From: Brandon Martin via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 18:43 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Brandon Martin <lists.nanog@monmotha.net> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 11/6/25 01:33, Vasilenko Eduard wrote: Hi Marting, All your messages are true. But these are not all the complexities. Read here (if you like) https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-fbnv... [datatracker[.]ietf[.]org] . to see how deep is the rabbit hole and why it is better not to touch it. While I have not read that entire draft, I'm familiar with most of the challenges it espouses, and they are indeed issues to deal with. However, what you seem to be missing is that, IF you are willing to deal with what is essentially the status quo in IPv4 when not doing true multi-homing using BGP or similar (broken end-to-end connectivity and/or address translation that changes without notification to hosts behind the border router), you can do the SAME THING in IPv6. [EV:] Not at all. One very big company has blocked DHCP on all mobiles (inside chipset). Hence, it is not possible to delegate IPv6 prefix behind mobile link. Hence, E2E IPv6 story is broken. At the same time, IETF doing everything possible to block NAT in any form. NAT is the primary method for SMB/SOHO in IPv4. Another one big company (or the same?) has blocked DHCP on the major mobile OS. You have to use IPX-style SLAAC. And so on. IPv6 is very aggressive in the attempt to "change the world". Telco people has found a work-around for this: they have put subscriber inside the tunnel and disabled all complexities because it is P2P. We try not to because IPv6 lets us do things in potentially BETTER ways, specifically in ways that attempt to preserve end-to-end connectivity and notify hosts about addressing changes, but that's up to you as a network administrator. [EV:] You see - it is what I am talking about. Small group of people know how would be "BETTER". IMHO: this group already isolated themselves. Indeed, that draft mentions both ULA+NPT66 and ULA+NAT66 as options and discusses the upsides and downsides of them noting that they basically mimic the present-day situation with IPv4 including the known downsides. [EV:] The draft would be never published because it mentions all options, but IETF consensus is "to be silent about any form of NAT and cancel it from all documents". It one of the 3 major factors that push me to believe that IPv6 would not be accepted by businesses. Actually, IPv6 IETF people are effectively blocking themselves. Only if you want to dynamically change the addressing that hosts see on their interfaces do you run into issues that are unique to IPv6 (unless you're one of the presumably vanishingly few people doing that with public IPv4 addresses from multiple carriers). There are upsides to making that work, but you don't have to, and you, as network administrator, get to choose what you do. [EV:] For the IPv6 mandatory E2E story, you have to have dynamic IP addresses, because you have to renumber your network automatically after the uplink is lost, because the prefix was delegated from the Telco. IPv6 addresses are ephemeral for small businesses and many branches of big businesses. In fact, the only mechanisms that paper mentions that AREN'T essentially identical to the status quo with IPv4 are the PA-based mechanism using adjustable RA timers on the LAN and NPT44, and both of these are only because either you can't do it at all with IPv4 (the former) or because there's no interest (the former again, plus NPT44 is a thing just not commonly used in this application due to address-space runout). [EV:] Of cause not identical. IPv6 is much more complex - it has much more options and a few order of magnitudes more challenges. There are also approaches commonly referred to collectively as "SD-WAN" that aren't discussed in that draft that are ALSO used with IPv4 and that are directly applicable to IPv6. The most obvious one is to tunnel all your traffic to a (hopefully) nearby endpoint with true (BGP-based) multi-homed connectivity and use some hidden mechanism to choose which local connection (for which BGP-based multi-homing is presumably not viable) sees the tunneled traffic. [EV:] They are discussed - It is section 5.3 (more general). Yet, the specific corner case "SD-WAN" was not mentioned - it is a point for improvement, people may search specifically for it. There's multiple ways to approach a problem, and the one I'm generally least fond of is "proclaim the problem intractable", but I guess the "your network, your choice" philosophy applies there, too. [EV:] I predict that business people would choose to stay on IPv4. The number of approaches available on IPv6 to solve this problem is indeed higher than at least the practical number of approaches available on IPv4 due to the more flexible nature of IPv6, but the solutions themselves don't necessarily have higher complexity. -- Brandon Martin _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 8:05 AM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: In-line comments. -----Original Message----- From: Brandon Martin via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 18:43 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Brandon Martin <lists.nanog@monmotha.net> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 11/6/25 01:33, Vasilenko Eduard wrote: Hi Marting, All your messages are true. But these are not all the complexities. Read here (if you like)https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-fbnv... [datatracker[.]ietf[.]org]. to see how deep is the rabbit hole and why it is better not to touch it. While I have not read that entire draft, I'm familiar with most of the challenges it espouses, and they are indeed issues to deal with. However, what you seem to be missing is that, IF you are willing to deal with what is essentially the status quo in IPv4 when not doing true multi-homing using BGP or similar (broken end-to-end connectivity and/or address translation that changes without notification to hosts behind the border router), you can do the SAME THING in IPv6. [EV:] Not at all. One very big company has blocked DHCP on all mobiles (inside chipset). Hence, it is not possible to delegate IPv6 prefix behind mobile link. Hence, E2E IPv6 story is broken. At the same time, IETF doing everything possible to block NAT in any form. NAT is the primary method for SMB/SOHO in IPv4. Another one big company (or the same?) has blocked DHCP on the major mobile OS. You have to use IPX-style SLAAC. And so on. IPv6 is very aggressive in the attempt to "change the world". Telco people has found a work-around for this: they have put subscriber inside the tunnel and disabled all complexities because it is P2P. We try not to because IPv6 lets us do things in potentially BETTER ways, specifically in ways that attempt to preserve end-to-end connectivity and notify hosts about addressing changes, but that's up to you as a network administrator. [EV:] You see - it is what I am talking about. Small group of people know how would be "BETTER". IMHO: this group already isolated themselves. Indeed, that draft mentions both ULA+NPT66 and ULA+NAT66 as options and discusses the upsides and downsides of them noting that they basically mimic the present-day situation with IPv4 including the known downsides. [EV:] The draft would be never published because it mentions all options, but IETF consensus is "to be silent about any form of NAT and cancel it from all documents". It one of the 3 major factors that push me to believe that IPv6 would not be accepted by businesses. Actually, IPv6 IETF people are effectively blocking themselves. Only if you want to dynamically change the addressing that hosts see on their interfaces do you run into issues that are unique to IPv6 (unless you're one of the presumably vanishingly few people doing that with public IPv4 addresses from multiple carriers). There are upsides to making that work, but you don't have to, and you, as network administrator, get to choose what you do. [EV:] For the IPv6 mandatory E2E story, you have to have dynamic IP addresses, because you have to renumber your network automatically after the uplink is lost, because the prefix was delegated from the Telco. IPv6 addresses are ephemeral for small businesses and many branches of big businesses. In fact, the only mechanisms that paper mentions that AREN'T essentially identical to the status quo with IPv4 are the PA-based mechanism using adjustable RA timers on the LAN and NPT44, and both of these are only because either you can't do it at all with IPv4 (the former) or because there's no interest (the former again, plus NPT44 is a thing just not commonly used in this application due to address-space runout). [EV:] Of cause not identical. IPv6 is much more complex - it has much more options and a few order of magnitudes more challenges. There are also approaches commonly referred to collectively as "SD-WAN" that aren't discussed in that draft that are ALSO used with IPv4 and that are directly applicable to IPv6. The most obvious one is to tunnel all your traffic to a (hopefully) nearby endpoint with true (BGP-based) multi-homed connectivity and use some hidden mechanism to choose which local connection (for which BGP-based multi-homing is presumably not viable) sees the tunneled traffic. [EV:] They are discussed - It is section 5.3 (more general). Yet, the specific corner case "SD-WAN" was not mentioned - it is a point for improvement, people may search specifically for it. There's multiple ways to approach a problem, and the one I'm generally least fond of is "proclaim the problem intractable", but I guess the "your network, your choice" philosophy applies there, too. [EV:] I predict that business people would choose to stay on IPv4. The number of approaches available on IPv6 to solve this problem is indeed higher than at least the practical number of approaches available on IPv4 due to the more flexible nature of IPv6, but the solutions themselves don't necessarily have higher complexity. -- Brandon Martin _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 6, 2025, at 4:43 PM, Brandon Martin via NANOG <nanog@lists.nanog.org> wrote: On 11/6/25 01:33, Vasilenko Eduard wrote: Hi Marting, All your messages are true. But these are not all the complexities. Read here (if you like)https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-fbnv... [datatracker[.]ietf[.]org]. to see how deep is the rabbit hole and why it is better not to touch it. While I have not read that entire draft, I'm familiar with most of the challenges it espouses, and they are indeed issues to deal with. However, what you seem to be missing is that, IF you are willing to deal with what is essentially the status quo in IPv4 when not doing true multi-homing using BGP or similar (broken end-to-end connectivity and/or address translation that changes without notification to hosts behind the border router), you can do the SAME THING in IPv6. We try not to because IPv6 lets us do things in potentially BETTER ways, specifically in ways that attempt to preserve end-to-end connectivity and notify hosts about addressing changes, but that's up to you as a network administrator. Indeed, that draft mentions both ULA+NPT66 and ULA+NAT66 as options and discusses the upsides and downsides of them noting that they basically mimic the present-day situation with IPv4 including the known downsides. Only if you want to dynamically change the addressing that hosts see on their interfaces do you run into issues that are unique to IPv6 (unless you're one of the presumably vanishingly few people doing that with public IPv4 addresses from multiple carriers). There are upsides to making that work, but you don't have to, and you, as network administrator, get to choose what you do. In fact, the only mechanisms that paper mentions that AREN'T essentially identical to the status quo with IPv4 are the PA-based mechanism using adjustable RA timers on the LAN and NPT44, and both of these are only because either you can't do it at all with IPv4 (the former) or because there's no interest (the former again, plus NPT44 is a thing just not commonly used in this application due to address-space runout). There are also approaches commonly referred to collectively as "SD-WAN" that aren't discussed in that draft that are ALSO used with IPv4 and that are directly applicable to IPv6. The most obvious one is to tunnel all your traffic to a (hopefully) nearby endpoint with true (BGP-based) multi-homed connectivity and use some hidden mechanism to choose which local connection (for which BGP-based multi-homing is presumably not viable) sees the tunneled traffic. There's multiple ways to approach a problem, and the one I'm generally least fond of is "proclaim the problem intractable", but I guess the "your network, your choice" philosophy applies there, too. The number of approaches available on IPv6 to solve this problem is indeed higher than at least the practical number of approaches available on IPv4 due to the more flexible nature of IPv6, but the solutions themselves don't necessarily have higher complexity. -- Brandon Martin _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 6, 2025, at 7:33 AM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Hi Marting, All your messages are true. But these are not all the complexities. Read here (if you like) https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-fbnv... [datatracker[.]ietf[.]org]. to see how deep is the rabbit hole and why it is better not to touch it. Ed/ -----Original Message----- From: Brandon Martin via NANOG <nanog@lists.nanog.org> Sent: Wednesday, November 5, 2025 18:55 To: nanog@lists.nanog.org Cc: Brandon Martin <lists.nanog@monmotha.net> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) On 11/5/25 08:12, Vasilenko Eduard via NANOG wrote: Try to propagate the ISP prefix over a few hops of the routed network (on the site of some business). DHCPv6-PD or whatever. Then read the documents of the closed IETF WG "Home Networking" to understand what a mess is it. DHCPv6-PD with static memory at the delegating router is not the only way to propagate prefixes. It is an option, and it is the least-common-denominator option that is intended to make things usable for plug-and-play home users, but for people who have more complex network typologies yet still require a high degree of address agility, there are other ways to go about things. In fact, that's one of the reasons why people even bothered to make RIPng. If you have a complex network architecture and don't want to have to re-number, either acquire a truly static prefix from your provider (marrying you to your provider) or justify getting your own GUA prefix from an RIR and find a service provider that will route it for you. That's no different than IPv4 modulo the use of NAT. If you REALLY want to be able to switch globally-routable prefixes at the drop of a hat, that's what NPT at the edge and ULA in the network is for. No, it's not an option that you are encouraged to use and for various good reasons, but it does exist and solves that problem in a way that is no worse than NAT44 and in a way that can be substantially lighter weight (in particular, it can easily be made stateless). And if you REALLY, REALLY want straight up NAT66, it exists, and it works basically the same way as the NAT44 we're all used to and groan about. None of this is new. This has been the state of affairs for a couple decades, basically. -- Brandon Martin _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
request a static prefix from your ISP On 5 November 2025 14:12:30 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
Try to propagate the ISP prefix over a few hops of the routed network (on the site of some business). DHCPv6-PD or whatever. Then read the documents of the closed IETF WG "Home Networking" to understand what a mess is it.
Yes, a small number of businesses have a shortage inside 10/8. But even for them, IPv6 would be a much bigger challenge. The majority of businesses have no problem with a 10/8 size.
I have serious doubt there will be another protocol that replaces it. I do not believe too. Businesses would just stay on IPv4. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Wednesday, November 5, 2025 14:11 To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
Am 05.11.2025 um 06:26:39 Uhr schrieb Vasilenko Eduard:
There is a big misunderstanding about IPv6 on mobile (and the majority of residential broadband): it is NOT an IPv6. The primary difference between IPv4 and IPv6 is the first hop: IPv6 has enormous flexibility and complexity here.
Residential customers get PPP or even a direct ethernet connection. Then DHCPv6-PD is being used. Works fine and is being used by millions of people here in Germany. Business connections might get different protocols, but they are set up by people who should know how to set them up.
But MBB/FBB completely disabled all IPv6 features on the first hop;
Explain that further.
it is possible because L2 P2P connection is emulated here (PPP or GTP tunnel). Such castrated IPv6 works perfectly fine (for residential/mobile) because it is even simpler than IPv4. The big address space of IPv6 (64 bits) is a value here.
There is no possibility of canceling the "subnet" concept for business.
It is available in IPv6 too. RFCs say they should get a /48, so 2^16 subnets. In case they need more, they can request more from the RIR.
I've seen large enterprises where 10.0.0.0/8 isn't enough. And their NAT crap is just a PITA for everyone who has to do with their network.
IPv6 subnet complexity is too much burden for businesses.
It is less complex than IPv4 subnetting, especially when partial NAT is involved. If network engineers can't handle IPv6 subnetting, they should apply for another job.
Hence, IPv4 will stay for business forever.
I have serious doubt it will stay when IPv6 will be mandatory (remember how fast businesses implemented TLS or DKIM when the big players requested that?).
IMHO: the world would finally accept: "reduced IPv6 for subscribers, IPv4 for businesses". IMHO: the full IPv6 (it was called "Next Generation" 3 decades ago) has no future. Eduard
I have serious doubt there will be another protocol that replaces it. IPv6 is now already present in most protocol stacks (I know that devices without it exist), at carrier networks and at many ISPs. A new protocol needs time to be implemented and shares the same problem as IPv4: There are people who do not want it and there is no "IPv4 with longer addresses that is backward compatible" (and cannot be).
-- Gruß Marco
Send unsolicited bulk mail to 1762320399muell@cartoonies.org _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VLR65KJZ...
How many businesses could deal with BGP? How bigger is the cost of a BGP connection to the Telco? Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 15:04 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: RE: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) request a static prefix from your ISP On 5 November 2025 14:12:30 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
Try to propagate the ISP prefix over a few hops of the routed network (on the site of some business). DHCPv6-PD or whatever. Then read the documents of the closed IETF WG "Home Networking" to understand what a mess is it.
Yes, a small number of businesses have a shortage inside 10/8. But even for them, IPv6 would be a much bigger challenge. The majority of businesses have no problem with a 10/8 size.
I have serious doubt there will be another protocol that replaces it. I do not believe too. Businesses would just stay on IPv4. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Wednesday, November 5, 2025 14:11 To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)
Am 05.11.2025 um 06:26:39 Uhr schrieb Vasilenko Eduard:
There is a big misunderstanding about IPv6 on mobile (and the majority of residential broadband): it is NOT an IPv6. The primary difference between IPv4 and IPv6 is the first hop: IPv6 has enormous flexibility and complexity here.
Residential customers get PPP or even a direct ethernet connection. Then DHCPv6-PD is being used. Works fine and is being used by millions of people here in Germany. Business connections might get different protocols, but they are set up by people who should know how to set them up.
But MBB/FBB completely disabled all IPv6 features on the first hop;
Explain that further.
it is possible because L2 P2P connection is emulated here (PPP or GTP tunnel). Such castrated IPv6 works perfectly fine (for residential/mobile) because it is even simpler than IPv4. The big address space of IPv6 (64 bits) is a value here.
There is no possibility of canceling the "subnet" concept for business.
It is available in IPv6 too. RFCs say they should get a /48, so 2^16 subnets. In case they need more, they can request more from the RIR.
I've seen large enterprises where 10.0.0.0/8 isn't enough. And their NAT crap is just a PITA for everyone who has to do with their network.
IPv6 subnet complexity is too much burden for businesses.
It is less complex than IPv4 subnetting, especially when partial NAT is involved. If network engineers can't handle IPv6 subnetting, they should apply for another job.
Hence, IPv4 will stay for business forever.
I have serious doubt it will stay when IPv6 will be mandatory (remember how fast businesses implemented TLS or DKIM when the big players requested that?).
IMHO: the world would finally accept: "reduced IPv6 for subscribers, IPv4 for businesses". IMHO: the full IPv6 (it was called "Next Generation" 3 decades ago) has no future. Eduard
I have serious doubt there will be another protocol that replaces it. IPv6 is now already present in most protocol stacks (I know that devices without it exist), at carrier networks and at many ISPs. A new protocol needs time to be implemented and shares the same problem as IPv4: There are people who do not want it and there is no "IPv4 with longer addresses that is backward compatible" (and cannot be).
-- Gruß Marco
Send unsolicited bulk mail to 1762320399muell@cartoonies.org _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VLR 65KJZ3GB6REMTBPP7DAOQ5G2XP5OU/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/XVCSPKIV...
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 7:35 AM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: How many businesses could deal with BGP? How bigger is the cost of a BGP connection to the Telco? Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Thursday, November 6, 2025 15:04 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: RE: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) request a static prefix from your ISP On 5 November 2025 14:12:30 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Try to propagate the ISP prefix over a few hops of the routed network (on the site of some business). DHCPv6-PD or whatever. Then read the documents of the closed IETF WG "Home Networking" to understand what a mess is it. Yes, a small number of businesses have a shortage inside 10/8. But even for them, IPv6 would be a much bigger challenge. The majority of businesses have no problem with a 10/8 size. I have serious doubt there will be another protocol that replaces it. I do not believe too. Businesses would just stay on IPv4. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Wednesday, November 5, 2025 14:11 To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) Am 05.11.2025 um 06:26:39 Uhr schrieb Vasilenko Eduard: There is a big misunderstanding about IPv6 on mobile (and the majority of residential broadband): it is NOT an IPv6. The primary difference between IPv4 and IPv6 is the first hop: IPv6 has enormous flexibility and complexity here. Residential customers get PPP or even a direct ethernet connection. Then DHCPv6-PD is being used. Works fine and is being used by millions of people here in Germany. Business connections might get different protocols, but they are set up by people who should know how to set them up. But MBB/FBB completely disabled all IPv6 features on the first hop; Explain that further. it is possible because L2 P2P connection is emulated here (PPP or GTP tunnel). Such castrated IPv6 works perfectly fine (for residential/mobile) because it is even simpler than IPv4. The big address space of IPv6 (64 bits) is a value here. There is no possibility of canceling the "subnet" concept for business. It is available in IPv6 too. RFCs say they should get a /48, so 2^16 subnets. In case they need more, they can request more from the RIR. I've seen large enterprises where 10.0.0.0/8 isn't enough. And their NAT crap is just a PITA for everyone who has to do with their network. IPv6 subnet complexity is too much burden for businesses. It is less complex than IPv4 subnetting, especially when partial NAT is involved. If network engineers can't handle IPv6 subnetting, they should apply for another job. Hence, IPv4 will stay for business forever. I have serious doubt it will stay when IPv6 will be mandatory (remember how fast businesses implemented TLS or DKIM when the big players requested that?). IMHO: the world would finally accept: "reduced IPv6 for subscribers, IPv4 for businesses". IMHO: the full IPv6 (it was called "Next Generation" 3 decades ago) has no future. Eduard I have serious doubt there will be another protocol that replaces it. IPv6 is now already present in most protocol stacks (I know that devices without it exist), at carrier networks and at many ISPs. A new protocol needs time to be implemented and shares the same problem as IPv4: There are people who do not want it and there is no "IPv4 with longer addresses that is backward compatible" (and cannot be). -- Gruß Marco Send unsolicited bulk mail to 1762320399muell@cartoonies.org _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 65KJZ3GB6REMTBPP7DAOQ5G2XP5OU/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 6, 2025, at 1:03 PM, nanog--- via NANOG <nanog@lists.nanog.org> wrote: request a static prefix from your ISP On 5 November 2025 14:12:30 CET, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Try to propagate the ISP prefix over a few hops of the routed network (on the site of some business). DHCPv6-PD or whatever. Then read the documents of the closed IETF WG "Home Networking" to understand what a mess is it. Yes, a small number of businesses have a shortage inside 10/8. But even for them, IPv6 would be a much bigger challenge. The majority of businesses have no problem with a 10/8 size. I have serious doubt there will be another protocol that replaces it. I do not believe too. Businesses would just stay on IPv4. Ed/ -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Wednesday, November 5, 2025 14:11 To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: Artificial Juniper SRX limitations preventing IPv6 deployment (and sales) Am 05.11.2025 um 06:26:39 Uhr schrieb Vasilenko Eduard: There is a big misunderstanding about IPv6 on mobile (and the majority of residential broadband): it is NOT an IPv6. The primary difference between IPv4 and IPv6 is the first hop: IPv6 has enormous flexibility and complexity here. Residential customers get PPP or even a direct ethernet connection. Then DHCPv6-PD is being used. Works fine and is being used by millions of people here in Germany. Business connections might get different protocols, but they are set up by people who should know how to set them up. But MBB/FBB completely disabled all IPv6 features on the first hop; Explain that further. it is possible because L2 P2P connection is emulated here (PPP or GTP tunnel). Such castrated IPv6 works perfectly fine (for residential/mobile) because it is even simpler than IPv4. The big address space of IPv6 (64 bits) is a value here. There is no possibility of canceling the "subnet" concept for business. It is available in IPv6 too. RFCs say they should get a /48, so 2^16 subnets. In case they need more, they can request more from the RIR. I've seen large enterprises where 10.0.0.0/8 isn't enough. And their NAT crap is just a PITA for everyone who has to do with their network. IPv6 subnet complexity is too much burden for businesses. It is less complex than IPv4 subnetting, especially when partial NAT is involved. If network engineers can't handle IPv6 subnetting, they should apply for another job. Hence, IPv4 will stay for business forever. I have serious doubt it will stay when IPv6 will be mandatory (remember how fast businesses implemented TLS or DKIM when the big players requested that?). IMHO: the world would finally accept: "reduced IPv6 for subscribers, IPv4 for businesses". IMHO: the full IPv6 (it was called "Next Generation" 3 decades ago) has no future. Eduard I have serious doubt there will be another protocol that replaces it. IPv6 is now already present in most protocol stacks (I know that devices without it exist), at carrier networks and at many ISPs. A new protocol needs time to be implemented and shares the same problem as IPv4: There are people who do not want it and there is no "IPv4 with longer addresses that is backward compatible" (and cannot be). -- Gruß Marco Send unsolicited bulk mail to 1762320399muell@cartoonies.org _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]
Thus spake Marco Moock via NANOG (nanog@lists.nanog.org) on Sun, Nov 02, 2025 at 10:29:09AM +0100:
IIRC I've read that certain US government contracts require IPv6 compatibility.
Perhaps to Saku's point, we have also updated some of our language to indicate dual-stack is no longer wanted. In some of the recent procurements we have issued, we say things like the solution must work with IPv6 in the absence of IPv4. That catches a variety of corner cases, mostly of poor IPv6 QA. Dale -- Dale W. Carder Energy Sciences Network (ESnet) AS293
participants (34)
-
A B -
Aaron C. de Bruyn -
Andrew Kirch -
Andrew Paolucci -
Brandon Martin -
brent saner -
Chris -
Cory Sell -
Dale W. Carder -
Daniel Seagraves -
Dorn Hetzel -
Endre Szabo -
Gary Sparkes -
Giorgio Bonfiglio -
Hank Nussbacher -
Javier J -
Jon Lewis -
Marco Moock -
Matt Rienzo -
Matthew Petach -
Merike Kaeo -
Mike Hammett -
nanog＠immibis.com -
Nick Hilliard -
Romain -
Ryan Hamel -
Saku Ytti -
Samaneh Tajalizadehkhoob -
ThreatHunt Alerts -
tim＠pelican.org -
Tom Beecher -
Vasilenko Eduard -
William Herrin -
Zach Hanna