| Sprint Corp. (Kansas City, Mo.) and some other large ISPs have
called for a minimum CIDR block size. Their goal is to restrict the
number of routing table entries by forcing customers (usually other
ISPs) to aggregate a minimum number of addresses into CIDR blocks.
So far (to allow for an orderly transition), some top-level ISPs
are doing this on newly assigned IP address space only, starting with
/18 CIDR blocks in the 206.0.0.0 address block. Sprint is
grandfathering in older addresses, but it and other members of the
No
rth American Network Operators Group (NANOG) are pressuring ISPs to
use CIDR for previously assigned addresses, too.
With the /18 prefix set out as a stipulation, an ISP can announce
to Sprint a block of 64 network addresses, but not a smaller block of
32 (/19)--which would be filtered out by Sprint's routers. In other
words, Sprint won't know where networks in those smaller CIDR blocks
are (because its routers won't list them), which means systems behind
Sprint's network won't be able to reach them.
Accurate Allocation
CIDR may not solve IP address exhaustion, but when it comes to
allocating the right number of addresses the scheme is a big help.
Say a network manager needs network addresses for 10,000 hosts.
That normally means applying for a Class B address--a request likely to
be denied given how scarce Class Bs are. Even if a Class B were
granted, more than 55,000 addresses would go unused (remember, Class
Bs support more than 65,000 hosts).
But with CIDR, a net
manager can apply to an ISP for a block of 64
Class Cs. The CIDR scheme offers plenty of room for growth--a block of
64 Class C addresses supports more than 16,000 hosts--without unduly
draining the pool of available addresses.
That doesn't mean there are no CIDR downsides. ISPs, for instance,
will look to serve only those addresses within "their" CIDR blocks. A
network whose addresses are outside that block might be dropped from
some routing tables, cutting it off from other parts of the Internet.
Network managers could renumber networks with another address that is
part of a CIDR block, but doing so tends to be costly and
time-consuming.
Still, as long as the public network address used by their routers
or firewalls is part of a CIDR block, net managers are unlikely to
feel the effects of the CIDR scheme. (There is a method for
determining how a network address is announced by core routers.
Instructions are available at
http://www.ra.net/RADB.tools.docs/.query.html.)
Just Add More?
But even if CIDR addressing is fully implemented by every ISP in
the world, the addresses will simply one day run out. It's
inevitable.
It's a problem that the developers of IP only dimly foresaw 20
years ago, but now the IETF is moving to counteract the shortage. It
has sanctioned an upgrade known as IP version 6 (IPv6), which
dramatically expands the number of available addresses by boosting
them from 32 to 128 bits.
What's more, IPv6 will, through the use of a hierarchical routing
scheme, ease the workload of routers. CIDR blocks can be aggregated on
the basis of geographical location or ISP assignment--which enables
routers to determine where a network is located by its address. That's
a big change from IPv4, under which ISPs and the InterNIC assign
addresses at random. The equivalent in IPv4 terms would be if all IP
addresses in the 220.0.0.0 /8 CIDR block were assigned to networks in
Europe.
Behind this scheme lie new exterior routing protocols--such as the
OSI interdom
ain routing protocol (IDRP)--that promise to improve router
performance by carrying CIDR masks as well as IP addresses. The main
idea with hierarchical routing is that a site's networks are part of a
small CIDR block, which is part of a larger CIDR block from an ISP,
which in turn is part of a regional or continental CIDR block.
Routers in other regions carry the largest CIDR blocks in their
routing tables and use them to forward traffic for any network in the
block to NAPs in appropriate locations. However, even with bigger CIDR
blocks, there will still be more and more networks--which means bigger,
more powerful, and faster routers will be needed.
Not So Fast
On paper, IPv6 is a great idea. It will relieve the IP address
crunch, and it promises to streamline configuration and management of
workstations and routers alike.
Still, IPv6 poses some daunting questions for net managers. For
instance, what's the best way to make the transition while maintaining
backward compatibili
ty with all those systems still running IPv4? What
about renumbering networks--not to mention buying, installing, and
configuring all of that new IP software?
IPv6 advocates say there's no reason to worry. The transition plan
calls for 32-bit IPv4 addresses to be embedded in the
least-significant-bit positions of the IPv6 address field. This would
permit communication between IPv4 and IPv6 systems and would allow a
system to run dual protocol stacks until the day IPv4 is officially
replaced.
The downside is that this plays into the hands of networkers who
don't want to convert to IPv6 at all; instead, they have a workable
option for continuing to run IPv4. For network managers who do want to
make the move, about the only thing they can do right now is make sure
their networks are part of CIDR address blocks. Ideally, all addresses
should be part of one contiguous block--but that may not be possible
for enterprise nets.
In short, the switch to IPv6 won't come about until the value of a
new technology becomes clear and system hardware and software can
support it. Today, only a handful of vendors offer production-grade
IPv6 products. Net managers will thus continue to wring as much out of
IPv4 as they can--until their own systems or the sheer numbers of
Internet users forces the conversion to IPv6.
William Dutcher is a member of the Internet consulting group of Network Solutions Inc. (Herndon, Va.). His e-mail address is bdutcher@mcimail.com.
[
Home
]
[
Registration
|
Subscriptions
]
[
Contact Us
|
E-Mail
]
|
