It's at least true of how some of the Cisco platforms cope with IPv6 access lists.
Owen On Aug 8, 2011, at 11:54 PM, Joel Jaeggli wrote: > > On Aug 8, 2011, at 5:14 PM, Owen DeLong wrote: > >> I'm sure there will be platforms that end up on both sides of this question. > > I know of no asic in a switch that claims to support ipv6 that does it this > way... That would tend to place you at a competitive disadvantage to > broadcom/marvell/fulcrum/juniper/cisco if you implemented it that way... it's > easier I imagine to simply reduce the size of the fib... > > given that switches routinely have to forward to neighbors on /126 or /127 > prefix links I think that would be something of a mistake. > >> YES: We made a less expensive box by cutting the width of the TCAM required >> in half > >> NO: We spared no expense and passed the costs (and a nice profit margin) on >> to you so >> that you can do whatever you like in IPv6 at wire speed. >> >> I'm sure the market will chose products from both sides of the line for the >> same reasons. >> >> Owen >> >> On Aug 8, 2011, at 4:34 PM, Randy Carpenter wrote: >> >>> >>> 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 >>>>> >>>>> >>>> >>>> >>>> >>
smime.p7s
Description: S/MIME cryptographic signature
