Neal: You aren’t the only one who thought the math was off with IPv6.
I had my issues, but for different reasons. Interesting read. R Sent from my iPhone > On Jun 20, 2023, at 7:17 PM, imn...@gmail.com wrote: > > I did some math a while back. IPv6 will 'never' run out of addresses? Hah! > It'll happen sooner than anyone thinks. > > - Assume 2^31 IPv6 LANs attached to the internet around the world. > - Compute 2^31 * 2^64 = 2^95 addresses assigned > - Assume 16 devices connected on each LAN: 2^31 * 2^4 = 2^35 addresses in use > > Converting to decminal, about 40 * 10^27 addresses assigned, 34 * 10^9 > addresses used. That leaves about 1.2 quintillion times the number of > addresses in use that will never be used. > > Had they used /96 as the standard size (32-bit host address), that would've > resulted in about 2^63 addresses assigned for the same 2^35 addresses used. > The wastage would've dropped to about 270 million times the addresses used: > about 12 orders of magnitude less address wastage. > > My opinion on this in more detail: http://murent.us/#ipv6wastage. > > I read somewhere that some may be second-guessing that decision. They > might've done better to use /96 and hash the MAC address down to 24 bits to > make SLAAC work. > > Neal > > >> On Tue, 20 Jun 2023 15:05:07 -0700 >> Eric Fahlgren <ericfahlg...@gmail.com> wrote: >> >> Yeah, some of the RFCs on v6 address formats hem and haw about how big the >> network ID and interface ID parts are (probably written before actual >> implementations were in place), but >> https://www.rfc-editor.org/rfc/rfc4291#section-2.5.1 says quite >> unequivocally: >> >> For all unicast addresses, except those that start with the binary >> value 000, Interface IDs are required to be 64 bits long... >> >> Which drives a stake in the ground regarding how to partition those 128 bits. >> >> >>> On Tue, Jun 20, 2023 at 11:59 AM Petr Menšík <pemen...@redhat.com> wrote: >>> >>> I think that is required by SLAAC RFC, which adds another 2 bytes to 6 >>> bytes of hardware ethernet address. >>> >>> Which is in total 8 bytes, therefore 64 bits is required for it. Prefix >>> cannot be higher, but can be lower in theory. There might be some >>> implementation details now supporting lower prefix length in current >>> implementation. >>> >>> Cheers, >>> Petr >>>> On 15. 06. 23 12:07, renmingshuai via Dnsmasq-discuss wrote: >>> >>> When ra-only, slaac, or ra-stateless is configured in dhcp-range and the >>> prefix len is set to a value other than 64, like this: >>> >>> “dhcp-range=2000:1000:1000:1000:1000:1000::, ra-stateless,120,infinite” >>> >>> the following error message is displayed: >>> >>> dnsmasq: prefix length must be exactly 64 for RA subnets at line 16 of >>> /etc/dnsmasq.conf >>> >>> Why must the prefix length be 64? This may come from an RFC regulation or >>> recommendation, but I didn't find it. Would you mind tell me the reason? >>> >>> -- >>> Petr Menšík >>> Software Engineer, RHEL >>> Red Hat, http://www.redhat.com/ >>> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB >>> >>> _______________________________________________ >>> Dnsmasq-discuss mailing list >>> Dnsmasq-discuss@lists.thekelleys.org.uk >>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss >>> > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
