[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