I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 8:51 AM, Saku Ytti via NANOG <[email protected]> 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 <[email protected]> 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 <[email protected]> Sent: Friday, November 7, 2025 19:10 To: North American Network Operators Group <[email protected]> Cc: Vasilenko Eduard <[email protected]> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> Sent: Thursday, November 6, 2025 20:58 To: North American Network Operators Group <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> 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 <[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://urldefense.com/v3/__https://lists.nanog.org/archives/list/[email protected]/message/GQ__;!!PtGJab4!8J2PiwP_8LbFqAcgREWK2oXv1e-KsBgc2U06KIV3zt97PbCwH4nrAwGIIp_yu832t1H6TdgqlaR6YNkeoqMv2E4b5Lg$ [lists[.]nanog[.]org] 5AQ75WAWRXFYS54QLFQAUMDGCM4QV4/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/[email protected]/message/3W__;!!PtGJab4!8J2PiwP_8LbFqAcgREWK2oXv1e-KsBgc2U06KIV3zt97PbCwH4nrAwGIIp_yu832t1H6TdgqlaR6YNkeoqMv-056Hsw$ [lists[.]nanog[.]org] JNGJSN3R252QI7CWBDOTAL37LNQFIH/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/[email protected]/message/ZYN__;!!PtGJab4!8J2PiwP_8LbFqAcgREWK2oXv1e-KsBgc2U06KIV3zt97PbCwH4nrAwGIIp_yu832t1H6TdgqlaR6YNkeoqMvK3jDtEI$ [lists[.]nanog[.]org] MIDYAXYZMGQJT2VX36DZIEY5XHNYC/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/[email protected]/message/EI7EM7BXCFKDS3WR7HNRLREHECTMUCR7/__;!!PtGJab4!8J2PiwP_8LbFqAcgREWK2oXv1e-KsBgc2U06KIV3zt97PbCwH4nrAwGIIp_yu832t1H6TdgqlaR6YNkeoqMvKeG8GXs$ [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/[email protected]/message/P47JM32L2IYAYYSHNGVBRQFWEIMTEFYQ/__;!!PtGJab4!8J2PiwP_8LbFqAcgREWK2oXv1e-KsBgc2U06KIV3zt97PbCwH4nrAwGIIp_yu832t1H6TdgqlaR6YNkeoqMv1zGhLko$ [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/[email protected]/message/CNKQ7DSVH56SSZA53OA5ELOAJCY4DAO2/__;!!PtGJab4!8J2PiwP_8LbFqAcgREWK2oXv1e-KsBgc2U06KIV3zt97PbCwH4nrAwGIIp_yu832t1H6TdgqlaR6YNkeoqMviofUsr8$ [lists[.]nanog[.]org] -- ++ytti _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/[email protected]/message/FPSD7YHKCHUNIZRSLKCSZMPNJRNHXADF/__;!!PtGJab4!8J2PiwP_8LbFqAcgREWK2oXv1e-KsBgc2U06KIV3zt97PbCwH4nrAwGIIp_yu832t1H6TdgqlaR6YNkeoqMvk6Oy4JQ$ [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/NEKOOIKRFSB5ZKP4UKFMQRPWMP5MJCG5/
