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: s...@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 <ma...@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 > > > > > > >