IP Address Format
An IP address is a 32-bit number that can be represented in many formats. Routers and computers are designed to operate efficiently on binary numbers, so a binary representation is a natural way for them to store and manipulate IP addresses. A typical 32-bit IP address to a router would look something like this:
10011100000110100001111000111100
This may be a fine representation for routers, but for us it is not the most appealing method. So let’s take a look at the binary representation and see if we can find a way to represent these numbers using a method that may be a bit more palatable. One way is to simply represent the IP address as a decimal number. The binary number used in the example above has a decimal value of
2,618,957,372
This may be easier to read, but the size of the number makes it cumbersome to work with. Another representation scheme is to break up the binary number into pieces and represent each piece as a decimal number. A natural size for binary pieces is 8 bits, which is the familiar “byte” or not-as-familiar “octet” (octet is the telecommunication term, but the two words can be used interchangeably). So let’s take our binary number, write it using groups of 8 bits (four octets) and then represent each group as a decimal number.
10011100
00011010
00011110
00111100
156
26
30
60
Table 2-1: Range of IP Addresses
Low
High
Binary
0000000000000000000
0000000000000
11111111111111111111111111111111
Decimal
0
4,294,967,295
Dotted Decimal
0.0.0.0
255.255.255.255
We don’t need all that space between the numbers, so let’s use a period, or dot, as a separator. Now our IP address has the form
156.26.30.60
which is referred to as dotted decimal notation. How many IP addresses are there? The range of IP addresses in all our representation schemes is shown in Table 2-1.
Theoretically, there are 4,294,967,296 possible IP addresses, although we will discover in this chapter that the actual usable number of IP addresses is much smaller.
Overview IP
A complete understanding of unicast and multicast IP addressing is required in order to design and implement robust IP networks. Concepts such as subnetting and Variable Length Subnet Masks (VLSM) should be mastered so that IP addressing plans make efficient use of your assigned address space. The concept, operation, and configuration of IP unicast routing protocols, RIP, IGRP, EIGRP, and OSPF, also need to be mastered because most multicast routing protocols rely on the underlying unicast routing configuration.
Multicast Communication Model
Now the fun begins. The problem to solve here is the one-to-many communication scenario. If a host wants to send the same packet to more than one receiver, how can this be accomplished? We can try using the unicast communication model and would be successful, but problems occur. Assume host A wants to send a packet to five hosts using the unicast model. This implies that host A knows the IP address of each receiver. If this is the case, then host A would need to send the same packet to five different IP addresses, as shown in Figure 1-6.
As the number of receivers increases, the number of packets that needs to be sent increases linearly. In other words, for n receivers, the host would need to send n copies of each packet. If the host is sending a real-time audio or video presentation, this solution may be workable for very few receivers, but as the number of receivers increases, the load of replicating packets on the host would be such that the delay between distinct packets would be unacceptable. Also, the links on the source router, router E in Figure 1-6, would have the bandwidth severely depleted.
Another major problem with this scheme is the host not knowing where the receivers are. If the receivers that require the traffic don’t change, then they could be entered, but this would be extremely restrictive because new receivers could not dynamically join or leave the group. And what about the broadcast model? Certainly every host on the local subnet would receive the traffic and each packet would only have to be sent once. So what’s the problem? Two come to mind. The first is that only receivers on the same subnet receive the traffic, while receivers on other subnets cannot receive it because the router blocks broadcasts. This is probably a good thing because we don’t want a broadcast to be delivered to the whole world. Yes, some people would like to do this, but in general it is not a good idea.
The second problem with using a broadcast is that every host is required to process the ethernet broadcast in order to determine if the traffic is intended for the host. The IP packet would have to be extracted from the ethernet frame and, because the destination IP address is also a broadcast address, the UDP or TCP portion of the packet would need to be extracted and passed up the protocol stack. If there is a process expecting the data, it would be passed to the application layer. If there is not a process expecting the data, then the data would be discarded. For those hosts not expecting the data, this would be a waste of valuable processing time and a source of many user complaints. Looks like we need another model.
For the multicast communication model, we will need two new types of addresses, an IP multicast address and an ethernet multicast address. An IP multicast address identifies a group of receivers that want to receive traffic destined for the group. Because all IP packets are encapsulated in ethernet frames, a multicast ethernet address is also required. For the multicast model to function correctly, hosts should be able to receive both unicast and multicast traffic, which mandates that hosts need multiple IP and ethernet addresses. A unicast IP and ethernet address are used for unicast traffic and zero or more IP, and ethernet multicast addresses are used for multicast traffic. Zero multicast addresses are needed if the host will not be receiving multicast traffic. A pair of multicast addresses, IP and ethernet, are required for each multicast group that the receiver wishes to join. A major difference between the unicast and multicast addresses is that unicast addresses are unique on each host, while multicast addresses are not. If five hosts wish to receive multicast traffic destined for group A, for example, then the hosts would all listen for traffic destined for the same multicast address, both IP and ethernet. The amount of traffic from the unicast case would be greatly reduced, as shown in Figure 1-7.
As the number of receivers increases, the number of packets that needs to be sent increases linearly. In other words, for n receivers, the host would need to send n copies of each packet. If the host is sending a real-time audio or video presentation, this solution may be workable for very few receivers, but as the number of receivers increases, the load of replicating packets on the host would be such that the delay between distinct packets would be unacceptable. Also, the links on the source router, router E in Figure 1-6, would have the bandwidth severely depleted. Another major problem with this scheme is the host not knowing where the receivers are. If the receivers that require the traffic don’t change, then they could be entered, but this would be extremely restrictive because new receivers could not dynamically join or leave the group. And what about the broadcast model? Certainly every host on the local subnet would receive the traffic and each packet would only have to be sent once. So what’s the problem? Two come to mind. The first is that only receivers on the same subnet receive the traffic, while receivers on other subnets cannot receive it because the router blocks broadcasts. This is probably a good thing because we don’t want a broadcast to be delivered to the whole world. Yes, some people would like to do this, but in general it is not a good idea.
The second problem with using a broadcast is that every host is required to process the ethernet broadcast in order to determine if the traffic is intended for the host. The IP packet would have to be extracted from the ethernet frame and, because the destination IP address is also a broadcast address, the UDP or TCP portion of the packet would need to be extracted and passed up the protocol stack. If there is a process expecting the data, it would be passed to the application layer. If there is not a process expecting the data, then the data would be discarded. For those hosts not expecting the data, this would be a waste of valuable processing time and a source of many user complaints. Looks like we need another model.
For the multicast communication model, we will need two new types of addresses, an IP multicast address and an ethernet multicast address. An IP multicast address identifies a group of receivers that want to receive traffic destined for the group. Because all IP packets are encapsulated in ethernet frames, a multicast ethernet address is also required. For the multicast model to function correctly, hosts should be able to receive both unicast and multicast traffic, which mandates that hosts need multiple IP and ethernet addresses. A unicast IP and ethernet address are used for unicast traffic and zero or more IP, and ethernet multicast addresses are used for multicast traffic. Zero multicast addresses are needed if the host will not be receiving multicast traffic. A pair of multicast addresses, IP and ethernet, are required for each multicast group that the receiver wishes to join. A major difference between the unicast and multicast addresses is that unicast addresses are unique on each host, while multicast addresses are not. If five hosts wish to receive multicast traffic destined for group A, for example, then the hosts would all listen for traffic destined for the same multicast address, both IP and ethernet. The amount of traffic from the unicast case would be greatly reduced, as shown in Figure 1-7.
Broadcast Communication Model
The broadcast model is one in which a host sends to everyone on the subnet. ARP is not needed because the ethernet broadcast address is a well-known address with the value 0xFF FF FF FF FF FF (Broadcast IP addresses also exist and are covered in Chapter 2). In the unicast model, a host could send an IP packet to any host on any network (assuming we have a route to the destination host). In the broadcast model, the scope of the broadcast is the local subnet. Routers block broadcast traffic, so the scope of a broadcast is limited to the local subnet (see Figure 1-5).
Unicast IP Communication Model
Three models exist for communication between hosts on a network whether or not the network is an intranet or the Internet. The first model is the unicast model, which is one-to-one communication. In Figures 1-4a through 1-4c, one host desires to send traffic to another specific host on the same IP subnet (IP addressing and subnets are covered in detail in Chapter 2, “Internet Protocol (IP), Unicast, Broadcast and Multicast Addresses”). For the ethernet Local Area Network (LAN), the hosts must contend with two different address schemes. The first scheme is the ethernet address that is burned into the Network Interface Card (NIC). The ethernet address is a six-byte (48-bit) link layer address that is globally unique and cannot be changed. Because the ethernet address is burned into the NIC, the ethernet address of the host changes if the NIC is changed. We have seen that on an ethernet LAN all data traffic is encapsulated in frames. Even though the host is sending to an IP address, the IP packet must be encapsulated in an ethernet frame. To accomplish the encapsulation, the sending host must resolve the receiving host’s IP to ethernet address mapping. The mapping is accomplished using the Address Resolution Protocol (ARP).
In Figures 1-4a-c, host A wishes to send a packet to host B. Host A knows the IP address of host B but not the ethernet address of host B. The ARP process, illustrated in the figures, proceeds as follows:
1. Host A sends an ARP broadcast (see Figure 1-4a) that all hosts on the network receive, including the router.
2. Host B receives the ARP and recognizes that the IP address contained in the ARP request belongs to host B. Host B sends an ARP reply that contains the ethernet address for host B (see Figure 1-4b).
3. Host A can now encapsulate the IP packet in an ethernet frame and transmit the frame to host B (see Figure 1-4c).
a. Host A sends an ARP request for IP address 172.16.1.2.
b. Host B responds with its ethernet address.
c. Host A can now send to host B.
If host A wants to send a packet to a host on another IP subnet, then the packet must be sent to the router. Host A will have a default gateway configured that points to the router interface attached to the LAN containing host A. Because the destination IP address is on a different subnet, host A knows to send the frame to the router and will send an ARP for the router’s ethernet address. When the router receives the frame, the IP packet is extracted and the router determines from the destination IP address whether or not the destination is on a directly connected network. If it is on a directly connected network, the router sends an ARP onto that network to resolve the ethernet address of the destination. When the ARP reply is received from the destination, the router can build an ethernet frame containing the IP packet and then send the frame to the destination. If the destination is not on a directly connected network, the router consults the routing table and determines the next router where the frame should be sent. IP unicast routing protocols are not covered in this book, but references are listed at the end of the chapter for further study.
In Figures 1-4a-c, host A wishes to send a packet to host B. Host A knows the IP address of host B but not the ethernet address of host B. The ARP process, illustrated in the figures, proceeds as follows:
1. Host A sends an ARP broadcast (see Figure 1-4a) that all hosts on the network receive, including the router.
2. Host B receives the ARP and recognizes that the IP address contained in the ARP request belongs to host B. Host B sends an ARP reply that contains the ethernet address for host B (see Figure 1-4b).
3. Host A can now encapsulate the IP packet in an ethernet frame and transmit the frame to host B (see Figure 1-4c).
a. Host A sends an ARP request for IP address 172.16.1.2.
b. Host B responds with its ethernet address.
c. Host A can now send to host B.
If host A wants to send a packet to a host on another IP subnet, then the packet must be sent to the router. Host A will have a default gateway configured that points to the router interface attached to the LAN containing host A. Because the destination IP address is on a different subnet, host A knows to send the frame to the router and will send an ARP for the router’s ethernet address. When the router receives the frame, the IP packet is extracted and the router determines from the destination IP address whether or not the destination is on a directly connected network. If it is on a directly connected network, the router sends an ARP onto that network to resolve the ethernet address of the destination. When the ARP reply is received from the destination, the router can build an ethernet frame containing the IP packet and then send the frame to the destination. If the destination is not on a directly connected network, the router consults the routing table and determines the next router where the frame should be sent. IP unicast routing protocols are not covered in this book, but references are listed at the end of the chapter for further study.
Subscribe to:
Posts (Atom)