[arin-ppml] CIDR v2.0
bmanning at vacation.karoshi.com
bmanning at vacation.karoshi.com
Tue Sep 16 07:09:20 EDT 2008
On Tue, Sep 16, 2008 at 12:37:14PM +0200, Iljitsch van Beijnum wrote:
> 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).
Thats a whole lot of work to support bitstrings in routing protocols.
If its just to support IPv4 then I am not sure I see the long-term value
in making such a change. Now if we were going to start supporting
variable length addresses then I could see a compelling case for making
such a change.
Mind you, I am a fan of variable length addressing.
--bill
More information about the ARIN-PPML
mailing list