Re: Re: Re: [Ext] [External Sender] RE: my finance department cares deeply about 2%

[Samaneh Tajalizadehkhoob via NANOG <nanog () 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 () lists nanog 
org/message/GQ__;!!PtGJab4!_WNIxgmHi49_WEpzSmhbstsYvggqQJ9crnkwwh4nDT2mdG6RLVHeoLIUxgz2CKVR5V7dpooQzRFkqCnk88txt6CUzUU$ 
[lists[.]nanog[.]org]
5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/
<
https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog () lists nanog 
org/message/GQ__;!!PtGJab4!_WNIxgmHi49_WEpzSmhbstsYvggqQJ9crnkwwh4nDT2mdG6RLVHeoLIUxgz2CKVR5V7dpooQzRFkqCnk88txt6CUzUU$ 
[lists[.]nanog[.]org]
5AQ75WAWRXFYS54QLFQAUMDGCM4QV4

_______________________________________________
NANOG mailing list

https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog () lists nanog 
org/message/3W__;!!PtGJab4!_WNIxgmHi49_WEpzSmhbstsYvggqQJ9crnkwwh4nDT2mdG6RLVHeoLIUxgz2CKVR5V7dpooQzRFkqCnk88txZyJXfJw$ 
[lists[.]nanog[.]org]
JNGJSN3R252QI7CWBDOTAL37LNQFIH/
<
https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog () lists nanog 
org/message/3W__;!!PtGJab4!_WNIxgmHi49_WEpzSmhbstsYvggqQJ9crnkwwh4nDT2mdG6RLVHeoLIUxgz2CKVR5V7dpooQzRFkqCnk88txZyJXfJw$ 
[lists[.]nanog[.]org]
JNGJSN3R252QI7CWBDOTAL37LNQFIH

_______________________________________________
NANOG mailing list

https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog () lists nanog 
org/message/ZY__;!!PtGJab4!_WNIxgmHi49_WEpzSmhbstsYvggqQJ9crnkwwh4nDT2mdG6RLVHeoLIUxgz2CKVR5V7dpooQzRFkqCnk88txMxp9YVM$ 
[lists[.]nanog[.]org]
NMIDYAXYZMGQJT2VX36DZIEY5XHNYC/
<
https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog () lists nanog 
org/message/ZY__;!!PtGJab4!_WNIxgmHi49_WEpzSmhbstsYvggqQJ9crnkwwh4nDT2mdG6RLVHeoLIUxgz2CKVR5V7dpooQzRFkqCnk88txMxp9YVM$ 
[lists[.]nanog[.]org]
NMIDYAXYZMGQJT2VX36DZIEY5XHNYC

_______________________________________________
NANOG mailing list

https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog () lists nanog 
org/message/EI__;!!PtGJab4!_WNIxgmHi49_WEpzSmhbstsYvggqQJ9crnkwwh4nDT2mdG6RLVHeoLIUxgz2CKVR5V7dpooQzRFkqCnk88txzLbpgEY$ 
[lists[.]nanog[.]org]
7EM7BXCFKDS3WR7HNRLREHECTMUCR7/
<
https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog () lists nanog 
org/message/EI__;!!PtGJab4!_WNIxgmHi49_WEpzSmhbstsYvggqQJ9crnkwwh4nDT2mdG6RLVHeoLIUxgz2CKVR5V7dpooQzRFkqCnk88txzLbpgEY$ 
[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 () lists nanog 
org/message/CH__;!!PtGJab4!_WNIxgmHi49_WEpzSmhbstsYvggqQJ9crnkwwh4nDT2mdG6RLVHeoLIUxgz2CKVR5V7dpooQzRFkqCnk88txHdxglIg$ 
[lists[.]nanog[.]org]
SFHGQWW7FLVDF6LENS6PRO65TEDQ2S/

_______________________________________________
NANOG mailing list

https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog () lists nanog 
org/message/3IZLYF5IT5FH5TZ6QKG3E2EPOZHVHCKC/__;!!PtGJab4!_WNIxgmHi49_WEpzSmhbstsYvggqQJ9crnkwwh4nDT2mdG6RLVHeoLIUxgz2CKVR5V7dpooQzRFkqCnk88txb5a2ba8$
 [lists[.]nanog[.]org]
_______________________________________________
NANOG mailing list

https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog () lists nanog 
org/message/ZHAOIN7ZHX4G4GAW4N5OWP2NZILMIH2U/__;!!PtGJab4!_WNIxgmHi49_WEpzSmhbstsYvggqQJ9crnkwwh4nDT2mdG6RLVHeoLIUxgz2CKVR5V7dpooQzRFkqCnk88txmAU7jzA$
 [lists[.]nanog[.]org]

_______________________________________________
NANOG mailing list
https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog () lists nanog 
org/message/PKJRQWXFLZ4U35FTAVSXAPT4LXM26FSU/__;!!PtGJab4!_WNIxgmHi49_WEpzSmhbstsYvggqQJ9crnkwwh4nDT2mdG6RLVHeoLIUxgz2CKVR5V7dpooQzRFkqCnk88tx7sa2eMM$
 [lists[.]nanog[.]org]
_______________________________________________
NANOG mailing list
https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog () lists nanog 
org/message/QO43KO2IMNFHW4KG5DSGXRZM6XTUAW63/__;!!PtGJab4!_qe_FN4kFq_1ERhyfhg4qLDVu341lquiMWCGVRB6KCsBD7Korp5yhF4RC0TgbfvFNiMpihA8f9dQjM22jakRxpR4NUY$
 [lists[.]nanog[.]org]
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/XEOUF2AGXT54ZTDC3ZFB6VFZBI36UZ23/