I'm sorry Mel, I only now saw your email.

I'll quote from my reply to Owen, for the motivation behind my question:

> Speaking of IPv6's full potential: we're considering 32 subscriptions
> per client. I've read people thinking of things like IPv6-aware soda
> cans. Refrigerators. Wearables. Cars and their internal components...
> You could have the on-board computer talking to the suspension via IPv6,
> and reporting back to the manufacturer or whatnot.
>
> Personally, I'm not particularly fond of the whole "refrigerators
> ordering milk bottles" craze, but hey, it may very well become a thing.
> And other stuff we haven't thought of yet.
>
> My point is: we're changing to a brand new protocol, and only now
> beginning to scratch its full potential. Yes, everything seems very big
> right now. Yes, 128 bits can be enough. Even 64 bits could be more than
> enough. But why limit ourselves? Someone decided (corretly) that 64
> would be too limiting.
>
> Please don't fall into the usual "you've got more addresses than
> atoms"... I've heard that, and am not disputing it. I'm not just talking
> about individual addresses (or /48's).
>
> What I am proposing here, as food for thought, is: what if we had e.g.
> 192 bits, or 256? For one, we could have much sparser allocations. Heck,
> we could even go as far as having a bit for each day of the month. What
> would this be good for? I don't know. Perhaps someone may come up with a
> use for it.
>

Regards,
Israel



On 07/09/2015 02:46 AM, Mel Beckman wrote:
> Israel,
>
> A better question is why bit-map your allocation plan at all? That seems ill 
> advised, since you must arbitrarily allocate huge swaths of ip space equally 
> between category classes when it's rarely efficient to do so. For example, 
> two bits for network infrastructure because infrastructure addresses are 
> likely far fewer than any customer class. Similarly three bits for geographic 
> region on the /38 boundary illogically assumes all geographic regions are the 
> same size.
>
> There isn't a good routing reason for a bitwise address structure, since 
> nobody routes that way. The only other rationale I can think of is human 
> mnemonic value, but 128-bit addresses are not very amenable to such mnemonics 
> (::DEAD:BEEF not withstanding :)
>
>  -mel beckman
>
>> On Jul 8, 2015, at 6:32 PM, Owen DeLong <o...@delong.com> wrote:
>>
>>
>>> Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so:
>>>
>>> - I reserve 1 bit for future allocation schemes, leaving me a /33;
>>> - 2 bits for network type (infrastructure, residential, business, LTE): /35
>>> - 3 bits for geographic region, state, whatever: /38
>>> - 5 bits for PoP, or city: /43
>>>
>>> This leaves me 5 bits for end sites: no joy.
>> Here’s the problem… You started at the wrong end and worked in the wrong 
>> direction in your planning.
>>
>> Let’s say you’re a national ISP. Let’s say you want to support 4 levels of 
>> aggregation.
>> Let’s say that at the lowest level (POP/City) you serve 50,000 end-sites in 
>> your largest POP/City. (16 bits)
>> Let’s say you plan to max out at 32 POPs/Cities per region (your number from 
>> above) (5 bits)
>> Let’s say you plan to divide the country into 8 regions (3 bits)
>> Let’s say for some reason you want to break your aggregation along the lines 
>> of service class (infrastructure, residential, business)
>>    as your top level division (rarely a good idea, but I’ll go with it for 
>> now) and that you have 4 service classes (2 bits)
>> Further, let’s say you decide to set aside half your address space for 
>> “future allocation schemes”.
>>
>> Each POP needs a /32.
>> We can combine the Region/POP number into an 8-bit field — You need a /24 
>> per Region.
>> You need 3 additional bits for your higher level sub-divisions. Let’s round 
>> to a nibble boundary and give you a /20.
>>
>> With that /20, you can support up to 67 Million end sites in your first plan 
>> still leaving 3/4 of your address space fallow.
>>
>> (That’s at /48 per end-site, by the way).
>>
>> Now, let’s consider: 7 Billion People, each of which represents 32 different 
>> end-sites — 224 billion end-sites world wide.
>> 224,000,000,000 / 67,000,000 = 3,344 (rounded up) total ISPs requiring /20s 
>> to serve every possible end-site on the
>> planet.
>>
>>
>> There are 1,048,576 /20s total, so after allocating all the ISPs in the 
>> world /20s, we still have 1,045,232 remaining.
>>
>> Let’s assume that every end-site goes with dual-address multi-homing (an 
>> IPv6 prefix from each provider).
>>
>> We are now left with only 1,041,888 /20s remaining. You still haven’t put a 
>> dent in it.
>>
>> Even if we divide by 8 and just consider the current /3 being allocated as 
>> global unicast, you still have 130,236 free /20s
>> left.
>>
>>> Granted, this is just a silly example, and I don't have to divide my
>>> address space like this. In fact, I really can't, unless I want to have
>>> more than 32 customers per city. But I don't think it's a very
>>> far-fetched example.
>> It’s not… It’s a great example of how not to plan your address space in IPv6.
>>
>> However, if we repeat the same exercise in the correct direction, not only 
>> does each of your end-sites get a /48, you get the /20 you need in order to 
>> properly deploy your network. You get lots of space left over, and we still 
>> don’t make a dent in the IPv6 free pool. Everyone wins.
>>
>>> Perhaps I'm missing something obvious here, but it seems to me that it
>>> would've been nice to have these kinds of possibilities, and more. It
>>> seems counterintuitive, especially given the "IPv6 way of thinking"
>>> which is normally encouraged: "stop counting beans, this isn't IPv4”.
>> The problem is that you not only stopped counting beans, you stopped 
>> counting bean piles and you lost track of just how big the pile that you are 
>> making smaller piles from really is.
>>
>> I hope that this will show you a better way.
>>
>> Owen
>>

Reply via email to