minimum IPv6 announcement size

Tue Oct 1 20:20:36 UTC 2013

The original plan was to go from 32 to 64 bits total. The additional 64 bits were added purely for the sake of EUI-64 based addressing, and really, 64 bits of network number is way more than enough. 

The /64 a are not what justify the larger blocks. That's IPv4 think. 

In IPv6, it is far better to think about the number of sinners without regard to counting hosts. The /48 per site is justified because it is almost inconceivable that a single site would ever need more than 65536 subnets. 

The /32 is a minimum reasonable allocation for an ISP to balance the tradeoff between routing table entries and consumption. 

Most estimates say that the vast majority of significant providers will end up using a /28 with some outliers on both sides. Many smaller providers will end up with /32 and a few medium to large ones will get /24 or even /20. A minute (probably less than 20 world wide) number might get /16s. 

Absent some novel (and IMHO I'll-advised) approach to semantic overloading, we will have plenty of address space to number the internet for many many years. 

Owen

> On Oct 1, 2013, at 12:11, Ryan McIntosh <rmcintosh at nitemare.net> wrote:
> 
> I'd love to be able to turn the microwave and oven on with my phone..
> maybe ten years from now lol..
> 
> In all seriousness though (and after skimming some of the other
> responses), I absolutely understand the ideals and needs amongst
> conserving memory on our routers for the sake of the future of bgp and
> internal routing. The problem I described has nothing to do with that
> however, I was mearly pointing out the fact that the basis of the
> larger allocations are based upon the fact we're handing over /64's to
> each vlan/point to point/lan/etc that we're turning up. In practice, I
> understand, a /64 means that 64 bits can handle a unique ip for every
> host without having to worry about numbering them, but how many hosts
> do we truly think will be sitting on one network? Surely not a /64's
> worth, that alone would cause havoc on a neighbor table's maximum
> memory limit. Maybe I'm missing the connection here, but I still don't
> see how a /64 is justified for each individual user/host/server/etc
> sitting on the edge of the internet that's getting ip's from an
> upstream provider (not arin/ripe/etc).
> 
> It's those smaller blocks that justify handing over larger ones, which
> I do understand there's plenty of, but how long are we going to patch
> the same problem and not try to fix it right?
> 
> Ryan
> 
>> On Mon, Sep 30, 2013 at 8:37 PM, Larry Sheldon <LarrySheldon at cox.net> wrote:
>>> On 9/27/2013 1:10 AM, Ryan McIntosh wrote:
>>> 
>>> I don't respond to many of these threads but I have to say I've
>>> contested this one too only to have to beaten into my head that a /64
>>> is "appropriate".. it still hasn't stuck, but unfortunately rfc's for
>>> other protocols depend on the blocks to now be a /64..
>>> 
>>> It's a waste, even if we're "planning for the future", no one house
>>> needs a /64 sitting on their lan.. or at least none I can sensibly
>>> think of o_O.
>> 
>> 
>> 
>> Are you accounting for connections to your refrigerator, water heater,
>> razor, vibrator, and on down to list so the gubermint can tell they when you
>> can use power for them?
>> 
>> --
>> Requiescas in pace o email           Two identifying characteristics
>>                                        of System Administrators:
>> Ex turpi causa non oritur actio      Infallibility, and the ability to
>>                                        learn from their mistakes.
>>                                          (Adapted from Stephen Pinker)
>> 