> 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 <[email protected]> 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 <[email protected]> > Sent: Friday, November 7, 2025 12:42 PM > To: North American Network Operators Group <[email protected]> > Cc: Matt Rienzo <[email protected]>; Matthew Petach < > [email protected]> > 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 <[email protected]> > 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 <[email protected]> > > Sent: Thursday, November 6, 2025 11:58 AM > > To: North American Network Operators Group <[email protected]> > > Cc: [email protected] > > 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 > > <[email protected] <mailto:[email protected]>> 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 < > > [email protected]<mailto:[email protected]>> wrote: > > >>Tell any financial department that 2% does not matter and see the > > >>reaction. > > >>Ed/ > > >>-----Original Message----- > > >>From: Marco Moock via NANOG <[email protected]<mailto: > > [email protected]>> > > >>Sent: Thursday, November 6, 2025 14:53 > > >>To: North American Network Operators Group <[email protected] > > <mailto:[email protected]>> > > >>Cc: Marco Moock <[email protected]<mailto:[email protected]>> > > >>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/[email protected]/message/GQ > > 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ > > < > > https://lists.nanog.org/archives/list/[email protected]/message/GQ > > 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4 > > > > > >>_______________________________________________ > > >>NANOG mailing list > > >> > > https://lists.nanog.org/archives/list/[email protected]/message/3W > > JNGJSN3R252QI7CWBDOTAL37LNQFIH/ > > < > > https://lists.nanog.org/archives/list/[email protected]/message/3W > > JNGJSN3R252QI7CWBDOTAL37LNQFIH > > > > > >_______________________________________________ > > >NANOG mailing list > > > > > https://lists.nanog.org/archives/list/[email protected]/message/ZY > > NMIDYAXYZMGQJT2VX36DZIEY5XHNYC/ > > < > > https://lists.nanog.org/archives/list/[email protected]/message/ZY > > NMIDYAXYZMGQJT2VX36DZIEY5XHNYC > > > > > _______________________________________________ > > NANOG mailing list > > > > https://lists.nanog.org/archives/list/[email protected]/message/EI > > 7EM7BXCFKDS3WR7HNRLREHECTMUCR7/ > > < > > https://lists.nanog.org/archives/list/[email protected]/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/[email protected]/message/CH > > SFHGQWW7FLVDF6LENS6PRO65TEDQ2S/ > > > _______________________________________________ > NANOG mailing list > > https://lists.nanog.org/archives/list/[email protected]/message/3IZLYF5IT5FH5TZ6QKG3E2EPOZHVHCKC/ > _______________________________________________ > NANOG mailing list > > https://lists.nanog.org/archives/list/[email protected]/message/ZHAOIN7ZHX4G4GAW4N5OWP2NZILMIH2U/ > _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/PKJRQWXFLZ4U35FTAVSXAPT4LXM26FSU/
