>> The following is meant to be used for demonstration purposes. >> It is meant for any and all to make reference to in discussions where >> "16 bits" may come into play. > > ip address allocation has nothing to with the physical object sizes. > for instance, you can have 2 separate ip addresses to core2duo CPU core > if you want to. > > itojun
Of course, host addresses which are allocated are always /128 in size, even if they are entries in a larger network. I am discussing *network* allocation policies. Specifically, what the impact is, if you use 16 more bits than necessary, for the host portion, and thus have 16 fewer bits in the network portion. This becomes important when we consider non-trivial hierarchies of allocations, such as RIR->LIR->ISP, where internally further allocations are made for internal aggregation purposes. This is because, lest we forget, that aggregation is tied to allocation. We cannot aggregate that which was not allocated suitably. And, if we further presume nibble boundaries for allocation units and aggregation points, as well as reservation of growth on nibble boundaries, we run the risk of getting squeezed on the total nibbles available. The basic math is: /64 vs /32 is 32 bits, which is only 8 nibbles. If we reserve an extra nibble for growth, that means only 4 levels of allocation between RIR and end user - which may not be enough. Finding that we have 16 more bits, i.e. 4 more nibbles, gives that much more flexibility and freedom to assign and use network space. There may still be cases where it's not enough, but the frequency with which those situation occur is likely to be a few orders of magnitude less. It is the regularity with which the RIRs need to add more blocks to the LIR assignments, that has direct impact on the Default-Free Zone (DFZ), and the goal here is to avoid directly or indirectly triggering problems in the DFZ by having too many prefixes - something that *is* seen in IPv4. If we can prevent problems without causing other serious problems, should we not make that effort? Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
