My take (albeit watching from the sidelines here myself): While the number of /64s available in a /32 makes this largely theoretical, I’d expect that if an operator were to dedicate /64s for this purpose, they would not be able to count them towards their HID ratio for a subsequent allocation.
An operator can certainly use a subset of a /64 provisioned for “active-networking" purposes to number non-network-active IoT devices, as long as they don’t collide with other addressing including stateless EUI-64 ranges. These would presumably be able to be counted towards the HID ratio. This does not solve the issue I raised earlier that IP resources are generally intended to be ephemeral and location/topology-specific, and that if this type of addressing permanently associates any given “thing” with an IP address, I’d argue that raises a substantial risk of larger issues down the road. Thanks, -Chris > On Aug 19, 2024, at 08:42, Rob Evans <[email protected]> wrote: > > Hi, >> However, that agreement may not be necessary. The holder of a /32 allocated >> under current policies can use that space legitimately, while also having >> plenty of spare /64s. And each of those /64 prefixes bears enough /128 >> addresses to identify 2^64 (18 billion billion) objects. >> >> Perhaps the authors might consider that if an existing IPv6 holder wants to >> implement their scheme, they could simply take a single /64 from their IPv6 >> space and use it as proposed. That could even be the same /64 which is >> assigned to the server of information about the objects identified within >> the prefix (an implementation detail which is probably beyond the scope of >> this discussion). >> > > Very much this. I must confess that I’ve only been peripherally watching this > discussion and had meant to go back and read it in more detail to try and > understand why this wasn’t an option… > > Cheers, > Rob > > _______________________________________________ > SIG-policy - https://mailman.apnic.net/[email protected]/ > To unsubscribe send an email to [email protected]
_______________________________________________ SIG-policy - https://mailman.apnic.net/[email protected]/ To unsubscribe send an email to [email protected]
