Re: IPv6 end user addressing

[Randy Carpenter <rcarpen () network1 net>]

I heard at one time that hardware manufacturers were likely to route in hardware only down to a /64, and that any 
smaller subnets would be subject to the "slow path" as ASICs were being designed with 64-bit address tables. I have no 
idea of the validity of that claim. Does anyone have any concrete evidence for or against this argument?

If true, it would make /64s even more attractive.

-Randy


----- Original Message -----
> we assign /112 per "end user vlan (or server)" at this moment...
> works
> perfectly fine (and thats even "a bit too big").
>
> - nobody wants to use dynamic ips on -servers- or -router links-
> anyway
>
> i -really- can't see why people don't just use subnets with just the
> required number of addresses.
>
> take one /64 (for /64's sake ;), split it up into subnets which each
> have
> the required number of addresses (lets say you have 2-4 addresses for
> each
> bgp/router link, so you simply split it up into subnets that size)
>
> etc.
>
> no need to use /64 for -everything- at all, just because it fits
> (ethernet) mac addresses (as if ethernet will be around longer than
> ipv6
> ha-ha, someone will come up with something faster tomorrow and then
> its
> bye bye ethernet, the 10ge variant is getting slow, and the 100ge
> variant
> is not even standardized yet, and trunking is a bottleneck ;)
>
> we don't use /24's for -everything- on ipv4 now do we :P
>
> (oh wait, there once was a time where we did.. due to another
> retarded
> semi-automatic configuration thingy, called RIP , which also only
> seemed
> to understand /24 or bigger ;)
>
> --
> Greetings,
>
> Sven Olaf Kamphuis,
> CB3ROB Ltd. & Co. KG
> =========================================================================
> Address: Koloniestrasse 34         VAT Tax ID:      DE267268209
>           D-13359                   Registration:    HRA 42834 B
>           BERLIN                    Phone:
>                     +31/(0)87-8747479
>           Germany                   GSM:
>                       +49/(0)152-26410799
> RIPE:    CBSK1-RIPE                e-Mail:          sven () cb3rob net
> =========================================================================
> <penpen> C3P0, der elektrische Westerwelle
> http://www.facebook.com/cb3rob
> =========================================================================
>
> Confidential: Please be advised that the information contained in
> this
> email message, including all attached documents or files, is
> privileged
> and confidential and is intended only for the use of the individual
> or
> individuals addressed. Any other use, dissemination, distribution or
> copying of this communication is strictly prohibited.
>
>
> On Mon, 8 Aug 2011, Owen DeLong wrote:
>
> > On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote:
> >
> > > On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews <marka () isc org>
> > > wrote:
> > > > So you want HE to force all their clients to renumber.
> > >
> > > No.  I am simply pointing out that Owen exaggerated when he stated
> > > that he implements the following three practices together on his
> > > own
> > > networks:
> > > * hierarchical addressing
> > > * nibble-aligned addressing
> > > * /48 per access customer
> > >
> > > You can simply read the last few messages in this thread to learn
> > > that
> > > his recommendations on this list are not even practical for his
> > > network today, because as Owen himself says, they are not yet able
> > > to
> > > obtain additional RIR allocations.  HE certainly operates a
> > > useful,
> > > high-profile tunnel-broker service which is IMO a very great asset
> > > to
> > > the Internet at-large; but if you spend a few minutes looking at
> > > the
> > > publicly available statistics on this service, they average only
> > > around 10,000 active tunnels across all their tunnel termination
> > > boxes
> > > combined.  They have not implemented the policies recommended by
> > > Owen
> > > because, as he states, a /32 is not enough.
> > >
> > > Do I think the position he advocates will cause the eventual
> > > exhaustion of IPv6?  Well, let's do an exercise:
> > >
> > > There has been some rather simplistic arithmetic posted today,
> > > 300m
> > > new subnets per year, etc. with zero consideration of
> > > address/subnet
> > > utilization efficiency within ISP networks and individual
> > > aggregation
> > > router pools.  That is foolish.  We can all pull out a calculator
> > > and
> > > figure that 2000::/3 has space for 35 trillion /48 networks.  That
> > > isn't how they will be assigned or routed.
> > >
> > > The effect of 2011-3 is that an out-sized ISP like AT&T has every
> > > justification for deciding to allocate 24 bits worth of subnet ID
> > > for
> > > their "largest POP," say, one that happens to terminate layer-3
> > > services for all customers in an entire state.  They then have
> > > policy
> > > support for allocating the same sized subnet for every other POP,
> > > no
> > > matter how small.  After all, the RIR policy permits them to
> > > obtain
> > > additional allocations as soon as one POP subnet has become full.
> > >
> > > So now you have a huge ISP with a few huge POPs, and a lot of
> > > small
> > > ones, justified in assigning the same size aggregate prefix,
> > > suitable
> > > for 2^24 subnets, to all those small POPs as well.  How many
> > > layer-3
> > > POPs might this huge ISP have?  Any number.  It could be every
> > > central
> > > office with some kind of layer-3 customer aggregation router.  It
> > > could even be every road-side hut for FTTH services.  Perhaps they
> > > will decide to address ten thousand POPs this way.
> > >
> > > Now the nibble-aligned language in the policy permits them to
> > > round up
> > > from 10,000 POPs to 16 bits worth of address space for "POP ID."
> > >  So
> > > AT&T is quite justified in requesting:
> > >    48 (customer subnet length) - 24 (largest POP subnet ID size) -
> > >    16
> > > (POP ID) == a /8 subnet for themselves.
> > Right up until you read:
> >
> > 6.5.3 (d):
> > If an LIR has already reached a /12 or more, ARIN will
> > allocate a single additional /12 rather than continue
> > expanding nibble boundaries.
> > As you can see, there is a safety valve in the policy at /12 for
> > just
> > this reason.
> >
> >
> > > Now you can see how this policy, and addressing scheme, is utterly
> > > brain-dead.  It really does put you (and me, and everyone else) in
> > > real danger of exhausting the IPv6 address space.  All it takes is
> > > a
> > > few out-sized ISPs, with one large POP each and a bunch of smaller
> > > ones, applying for the maximum amount of address space permitted
> > > them
> > > under 2011-3.
> >
> > Even by your calculations, it would take 256 such outsized ISPs
> > without
> > a safety valve. With the safety valve that is built into the policy
> > at /12,
> > it would take 4,096 such ISPs. I do not believe that there are more
> > than
> > about 20 such ISPs world wide at this time and would put the
> > foreseeable
> > likely maximum at less than 100 due to the need for customers to
> > support
> > such outsized ISPs and the limited base that would have to be
> > divided
> > among them.
> >
> > Owen