[arin-ppml] CIDR v2.0

bmanning at vacation.karoshi.com bmanning at vacation.karoshi.com
Tue Sep 16 16:55:07 EDT 2008


 soooo... you see real problems with accepting /32 prefixes in IPv6 space
then.  (since there are the same number of /32's in either family).

--bill


On Tue, Sep 16, 2008 at 01:52:43PM -0500, Kevin Kargel wrote:
> I wasn't advocating enforced route aggregation as a viable method..  I was
> just stating it is the only way I know of to allow >24bit network
> allocations and make them work given todays routing hardware.
> 
> If route tables are going to multiply, which is what would happen if subC PI
> networks became common, routing hardware would have to make a quantum leap
> in power.  
> 
> I run mid level (Cisco 10K, 72xx, 76xx) enterprise routers, and they do not
> have a lot of excess space or power for the route tables I manage today.
> Even doubling or tripling the size of the route tables would cause problems,
> much less the increase we would see if sub-C PI space became common.  
> 
> I am sure that there are millions of business cases for routing sub-C
> networks, but stuffing the route tables like that before hardware to handle
> them is available and affordable will bring us to critical mass in short
> order.
> 
> 
> > -----Original Message-----
> > From: bmanning at vacation.karoshi.com 
> > [mailto:bmanning at vacation.karoshi.com] 
> > Sent: Tuesday, September 16, 2008 1:24 PM
> > To: Kevin Kargel
> > Cc: PPML
> > Subject: Re: [arin-ppml] CIDR v2.0
> > 
> > 
> > 	Kevin, 
> > 		in some ideal world, aggregation into some small set of
> > 	"ISP" space would be fine.  but things have not worked 
> > out that way.
> > 	for efficent address utilization, I expect we will see 
> > >24 bit allocations
> > 	more and more.  esp if that is all you need to support 
> > a translation function.
> > 
> > --bill
> > 
> > 
> > 
> > On Tue, Sep 16, 2008 at 08:11:51AM -0500, Kevin Kargel wrote:
> > > The difficulty with this is that we already have problems 
> > of hardware 
> > > that is insufficient to support the routing tables.  ISP's 
> > are already 
> > > filtering long CIDR routes (>24bit) because there isn't sufficient 
> > > memory or processor in the hardware to support the number 
> > of routes it 
> > > would require.
> > > 
> > > Your idea would work, but only if we got rid of PI space and forced 
> > > everyone to use IP space from their ISP so that there could be 
> > > efficient route aggregation.  If you search through threads 
> > you will 
> > > see that there is violent opposition by end users who want to be 
> > > provider independent.
> > > 
> > > > -----Original Message-----
> > > > From: arin-ppml-bounces at arin.net
> > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Iljitsch van 
> > > > Beijnum
> > > > Sent: Tuesday, September 16, 2008 5:37 AM
> > > > To: PPML PPML
> > > > Subject: [arin-ppml] CIDR v2.0
> > > > 
> > > > In the early 1990s IPv4 address space was running out. They fixed 
> > > > this by changing routing protocols. Maybe we should try 
> > to do that 
> > > > again.
> > > > 
> > > > <history>
> > > > 
> > > > In the early days of the internet you could only use IPv4 
> > addresses 
> > > > as blocks of 16777216, 65536 or 256 addresses. 256 was 
> > too small for 
> > > > most people so 65536 was a popular choice, but there are 
> > only some 
> > > > 16000 of these class B blocks and it was looking like 
> > those would be 
> > > > exhausted by the mid-1990s.
> > > > So they started giving people a bunch of class C blocks (256 
> > > > addresses each) but now the routing tables started to explode 
> > > > because a university that needed a single class B block 
> > before now 
> > > > used something like 16 class C blocks, which had to appear in 
> > > > routing tables individually. To fix this, routing protocols, 
> > > > especially BGP, were changed to be able to work with 
> > address blocks 
> > > > of arbitrary power of two sizes so address space and 
> > routing table 
> > > > slots could be managed much more efficiently. (This is "classless 
> > > > interdomain routing".)
> > > > 
> > > > </history>
> > > > 
> > > > Now that IPv4 address space is becoming scarce again, why 
> > not do the 
> > > > same thing again? But now rather than arbitrary powers of 2, we 
> > > > modify the protocols to work with arbitrary address ranges. I.e., 
> > > > 192.0.2.27
> > > > - 192.0.2.43.
> > > > 
> > > > To accommodate legacy routers that can't do lookups based 
> > on ranges 
> > > > we can put in backward compatibility mechanisms from
> > > > BGP5 to BGP4 similar to the ones from BGP4 (with CIDR) to
> > > > BGP3 (no CIDR).
> > > > _______________________________________________
> > > > PPML
> > > > You are receiving this message because you are subscribed to the 
> > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > > Unsubscribe or manage your mailing list subscription at:
> > > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > > Please contact info at arin.net if you experience any issues.
> > > > 
> > > _______________________________________________
> > > PPML
> > > You are receiving this message because you are subscribed 
> > to the ARIN 
> > > Public Policy Mailing List (ARIN-PPML at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> > 



> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



More information about the ARIN-PPML mailing list