IPv6 Routing table will be bloated?

Sven Olaf Kamphuis sven at cb3rob.net
Tue Oct 26 16:52:51 UTC 2010


dusty old routers with ram problems...

solution there: re-think the way you do your routing and compare the price 
of ram versus cpu cycles. (as well as having custom hardware developed to 
do it on, intel simply does not offer enough address bus lines to maintain 
bigass tables and address them linearily so you can keep entries for each 
ip or mac address out there and counters with them to automatically 
"migitate" ddos attacks and give every communications partner their own 
fair share on the outgoing interface's capacity).

(and no, we're not talking linux/bsd here... just dedicated routing 
firmware on let's say ibm's power-6/power-7 platform)

instead of buying the same old shit from juniper/cisco/foundry again which 
doesn't even have enough ram to announce /30's ipv4 (if everyone would do 
so ;), let alone properly prevent ddos attacks from even being possible

-- 
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 at cb3rob.net
=========================================================================
<penpen> C3P0, der elektrische Westerwelle

=========================================================================

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 Tue, 26 Oct 2010, Owen DeLong wrote:

>
> On Oct 26, 2010, at 7:06 AM, TJ wrote:
>
>> Quick comment:
>> IGP bloat != BGP bloat.  Your customers cannot announce the space you gave
>> them externally - unless ~/32s, i.e.  forced aggregation.
>>
> He's talking about the bloat that comes from ISPs getting slow-started and then
> only being able to increase their network in increments of 2x each time, so,
> effectively ISP gets:
>
> 1	x	/32		Initial
> Fills that up, gets
> 1	x	/32		First subsequent
> Then
> 1	x	/31
> then
> 1	x	/30
> etc.
>
> Probably not quite as bad as IPv4, but, potentially close.
>
>> Also, your customers shouldn't need to come back for more very often and
>> ideally you have some reservations for them a well :).
>>
> Consider the scenario where you're dealing with an ISP that provides
> services to other ISPs as his downstream customers and the above
> statement doesn't hold true like you think it should.
>
> Owen
>
>> /TJ
>> PS - apologies for top posting.
>> On Oct 26, 2010 9:59 AM, "Jack Bates" <jbates at brightok.net> wrote:
>>> So, the best that I can tell (still not through debating with RIR), the
>>> IPv6 routing table will see lots of bloat. Here's my reasoning so far:
>>>
>>> 1) RIR (ARIN in this case, don't know other RIR interpretations) only
>>> does initial assignments to barely cover the minimum. If you need more
>>> due to routing, you'll need to provide every pop, counts per pop, etc,
>>> to show how v6 will require more than just the minimums (full routing
>>> plan and customer counts to justify routing plan). HD-Ratio has NO
>>> bearing on initial allocation, and while policy dictates that it doesn't
>>> matter how an ISP assigns to customer so long as HD-Ratio is met, that
>>> is not the case when providing justification for the initial allocation.
>>>
>>> 2) Subsequent requests only double in size according to policy (so just
>>> keep going back over and over since HD is met immediately due to the
>>> minimalist initial assignment?)
>>>
>>> So I conclude that since I get a bare minimum, I can only assign a bare
>>> minimum. Since everything is quickly maxed out, I must request more (but
>>> only double), which in turn I can assign, but my customer assignments
>>> (Telcos/ISPs in this case) will be non-contiguous due to the limited
>>> available space I have to hand out. This will lead to IGP bloat, and in
>>> cases of multi-homed customers whom I provide address space for, BGP
>> bloat.
>>>
>>> I'm small, so my bloat factor is small, but I can quickly see this
>>> developing exactly as my v4 network did (if it was years ago when I
>>> first got my v4 allocation, growing to today, for each allocation I got
>>> for v4, I'd expect similar out of v6). Sure, the end user gets loads of
>>> space with those nice /48's, but the space within ISPs and their ISP
>>> customers is force limited by initial allocations which will create
>>> fragmentation of address space. This is brought about due to the dual
>>> standard of initial vs subsequent allocations (just enough to cover
>>> existing vs HD Ratio).
>>>
>>> As an example, Using HD-Ratios as an initial assignment metric can
>>> warrant a /27, whereas the minimalist approach may only warrant a
>>> heavily utilized /30. 3 bits doesn't seem like much, but it's a huge
>>> difference in growth room. Bare minimums, as provided by me, only
>>> included the /24 IPv4 DHCP pools converted with a raw conversion as /32
>>> IPv4 = /48 IPv6 network
>>>
>>> Am I missing something, or is this minimalist approach going to cause
>>> issues in BGP the same as v4 did?
>>>
>>>
>>> Jack
>>>
>
>




More information about the NANOG mailing list