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 <[email protected]> > Sent: Friday, November 7, 2025 21:32 > To: North American Network Operators Group <[email protected]> > Cc: Matt Rienzo <[email protected]>; Gary Sparkes > <[email protected]> > 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 <[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/3IZLYF5I > T5FH5TZ6QKG3E2EPOZHVHCKC/ > _______________________________________________ > NANOG mailing list > https://lists.nanog.org/archives/list/[email protected]/message/ZHAOIN > 7ZHX4G4GAW4N5OWP2NZILMIH2U/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/ORY7Q66GUOO3ISSFSMPQW3UV3TKE2PUX/
