Supernet block sizes - recommendations?
vaf at Valinor.Stanford.EDU
Thu May 13 17:36:36 UTC 1993
Same here. For large chunks of class C's, we send the end site directly
to the NIC.
This somewhat defeats the goal of using CIDR to reduce routing table explosion,
since if the block comes directly from the NIC, no aggregation can be done by
the service provider which connects the site.
Its just hard convincing the end sites the 'merits' of a chunk of class
C addresses for them-- too many are just too caught up in the 'prestige'
involved in getting a class B network... if only someone could tell all
those 'consultants' advising these end sites to get class B's... ;-)
I can think of a couple of benefits of having big chunk of C's rather than a B:
- two-level subnetting, even using dumb protocols that can't to VLSM (i.e.
each individual class-C is a "subnet" of the block, plus each class-C
can be subnetted itself)
- more flexible routing policy possible with EGP2/BGP3 - a monolithic
class-B can have only one routing policy (at least until BGP4) but a
block of class-C's can be divided to support multiple policies for
different parts of the block. This may not be something to advocate,
though, since it plays against aggregation.
More information about the NANOG