• Tidak ada hasil yang ditemukan

Classless Inter-Domain Routing (CIDR)

Dalam dokumen TCP/IP Tutorial and Technical Overview (Halaman 63-66)

Comments Welcome

Chapter 2. Internetworking and Transport Layer Protocols

2.1 Internet Protocol (IP)

2.1.7 Classless Inter-Domain Routing (CIDR)

It has been mentioned in 2.1.1, “IP Addressing” on page 27 that due to the impacts of growth, the IP address space will near exhaustion very soon if addresses are assigned as they are requested or as they used to be assigned. IPv6 will easily overcome that problem (see Chapter 6, “IP Version 6” on page 357), but what can be done until IPv6 will be fully deployed?

One idea was to use a range of Class C addresses instead of a single Class B address. The problem there is that each network must be routed separately because standard IP routing understands only class A, B and C network addresses (see 2.1.3, “IP Routing” on page 35).

Within each of these types of network, subnetting can be used to provide better granularity of the address space within each network, but there is no way to specify that multiple Class C networks are actually related (see 2.1.2, “IP Subnets” on page 30). The result of this is termed the routing table explosion problem: A Class B network of 3000 hosts requires one routing table entry at each backbone router, whereas the same network, if addressed as a range of Class C networks, would require 16 entries.

The solution to this problem is a scheme called Classless Inter-Domain Routing (CIDR). CIDR is described in RFCs 1518 to 1520.

CIDR does not route according to the class of the network number (hence the term classless) but solely according to the high order bits of the IP address, which are termed the IP prefix. Each CIDR routing table entry contains a 32-bit IP address and a 32-bit network mask, which together give the length and value of the IP prefix. This can be represented as <IP_address network_mask>. For example, to address a block of eight Class C addresses with one single routing table entry, the following representation would suffice: <192.32.136.0 255.255.248.0>. This would, from a backbone point of view, refer to the Class C network range from 192.32.136.0 to 192.32.143.0 as one single network because of the identical IP prefix, as illustrated in Figure 18 on page 46:

11ðððððð ðð1ððððð 1ððð1ððð ðððððððð = 192.32.136.ð (class C address) 11111111 11111111 11111--- --- 255.255.248.ð (network mask)

===================================== logical_AND

11ðððððð ðð1ððððð 1ððð1--- --- = 192.32.136 (IP prefix)

11ðððððð ðð1ððððð 1ððð1111 ðððððððð = 192.32.143.ð (class C address) 11111111 11111111 11111--- --- 255.255.248.ð (network mask)

===================================== logical_AND

11ðððððð ðð1ððððð 1ððð1--- --- = 192.32.136 (same IP prefix)

Figure 18. Classless Inter-Domain Routing - IP Supernetting Example

This process of combining multiple networks into a single entry is referred to as supernetting because routing is based on network masks that are shorter than the natural network mask of an IP address, in contrast to subnetting (see 2.1.2, “IP Subnets” on page 30) where the subnet masks are longer than the natural network mask.

The current Internet address allocation policies and the assumptions on which those policies were based, are described in RFC 1518 — An Architecture for IP Address Allocation with CIDR. They can be summarized as follows:

Ÿ IP address assignment reflects the physical topology of the network and not the organizational topology; wherever organizational and administrative boundaries do not match the network topology, they should not be used for the assignment of IP addresses.

Ÿ In general, network topology will closely follow continental and national boundaries and therefore IP addresses should be assigned on this basis.

Ÿ There will be a relatively small set of networks that carry a large amount of traffic between routing domains and which will be interconnected in a non-hierarchical way and that will cross national boundaries. These are referred to as transit routing domains (TRDs). Each TRD will have a unique IP prefix. TRDs will not be organized in a hierarchical way where there is no appropriate hierarchy. However, wherever a TRD is wholly within a continental boundary, its IP prefix should be an extension of the continental IP prefix.

Ÿ There will be many organizations that have attachments to other organizations that are for the private use of those two organizations and that do not carry traffic intended for other domains (transit traffic). Such private connections do not have a significant effect on the routing topology and can be ignored.

Ÿ The great majority of routing domains will be single-homed. That is, they will be attached to a single TRD. They should be assigned addresses that begin with that TRD's IP prefix. All of the addresses for all single-homed domains attached to a TRD can therefore be aggregated into a single routing table entry for all domains outside that TRD.

Note: This implies that if an organization changes its Internet service provider, it should change all of its IP addresses. This is not the current practice, but the widespread implementation of CIDR is likely to make it much more common.

Ÿ There are a number of address assignment schemes that can be used for multi-homed domains. These include:

– The use of a single IP prefix for the domain. External routers must have an entry for the organization that lies partly or wholly outside the normal hierarchy. Where a domain is multi-homed but all of the attached TRDs themselves are topologically nearby, it would be appropriate for the domain's IP prefix to include those bits common to all of the attached TRDs. For example, if all of the TRDs were wholly within the United States, an IP prefix implying an exclusively North American domain would be appropriate.

– The use of one IP prefix for each attached TRD, with hosts in the domain having IP addresses containing the IP prefix of the most appropriate TRD.

The organization appears to be a set of routing domains.

– Assigning an IP prefix from one of the attached TRDs. This TRD becomes a default TRD for the domain but other domains can explicitly route by one of the alternative TRDs.

– The use of IP prefixes to refer to sets of multi-homed domains having the TRD attachments. For example, there may be an IP prefix to refer to single-homed domains attached to network A, one to refer to single-homed domains attached to network B and one to refer to dual-homed domains attached to networks A and B.

Ÿ Each of these has various advantages, disadvantages and side effects. For example, the first approach tends to result in inbound traffic entering the target domain closer to the sending host than the second approach, and therefore a larger proportion of the network costs are incurred by the receiving

organization.

Because multi-homed domains can vary greatly in character and none of the above schemes is suitable for all such domains, there is no single policy that is best and RFC 1518 does not specify any rules for choosing between them.

2.1.7.1 CIDR Implementation

The implementation of CIDR in the Internet is primarily based on Border Gateway Protocol Version 4 (see 3.4.2, “Border Gateway Protocol (BGP-4)” on page 135).

The implementation strategy, described in RFC 1520 — Exchanging Routing Information Across Provider Boundaries in the CIDR Environment involves a staged process through the routing hierarchy beginning with backbone routers. Network service providers are divided into four types:

Type 1

Those that cannot employ any default inter-domain routing.

Type 2

Those that use default inter-domain routing but require explicit routes for a substantial proportion of the assigned IP network numbers.

Type 3

Those that use default inter-domain routing and supplement it with a small number of explicit routes.

Type 4

Those that perform all inter-domain routing using only default routes.

The CIDR implementation involves an implementation beginning with the Type 1 network providers, then the Type 2 and finally the Type 3 ones. CIDR has already been widely deployed in the backbone and over 9,000 class-based routes have been replaced by approximately 2,000 CIDR-based routes.

Dalam dokumen TCP/IP Tutorial and Technical Overview (Halaman 63-66)