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]