Fact Sheet for IPv4 Addressing
The following fact sheet discusses some of the most important aspects of IP addressing and its
relationship to the internetwork. It first discusses the standard way in which IPv4 addressing is used.
There are unusual cases (e.g., proxy-arp, multinetting) that bend some of these rules. They are
discussed in subsequent sections.
The Standard Case
1. An internetwork is a collection of multiple layer-2 networks. IPv4 creates a virtual layer-3
internetwork by interconnecting those networks at layer 3 with devices called routers.
2. A router is a device that has IP forwarding enabled. It accepts packets on an IP interface that
have IP destination addresses that do not match the IP bound-address list for that interface. In
other words, for unicast IP the router’s IP interfaces operate promiscuously.
3. In each layer-2 network any interface can deliver a frame to any other interface on that same
layer-2 network (i.e., they are in the same layer-2 broadcast domain). They cannot deliver a
frame to an interface on a different layer-2 network in the internetwork. This is true for the
layer-2 interface regardless of whether the IP protocol object on the same interface behaves as
a host or a router. The interfaces that are on the same network and that can deliver frames to
each other are “local” to each other. The interfaces that cannot deliver frames to each are
“remote” to each other.
4. An IPv4 address is a 32 bit unsigned binary number.
5. In the original “classfull” address architecture the Class A unicast addresses had the most
significant address bit set to 02. The Class B addresses had 102 as the most significant bits. The
Class C addresses had 1102 as the most significant bits.
6. An IPv4 netmask is a 32 bit unsigned binary number with contiguous 1s on the left (more
significant) and 0s on the right. The bit positions on the left (with the 1s) are called the network
bits and the bit positions on the right (with the 0s) are called the host bits. The number of
network bits in the netmask and the number of host bits in the netmask add up to 32. The
netmask is said to be “longer” if it has a larger number of network bits. It may be useful to think
of this as a “longer” string of contiguous 1s on the left side of the netmask.
7. A specific CIDR block is identified by a 32-bit address and a 32-bit netmask. The 32 bit netmask
transfers the concept of “network bits” and “host bits” to the address. The CIDR block includes
all addresses with the same network bit values as the address but with any arbitrary
combination of host bits. Any such addresses are said to be “inside” or “contained in” that
specific CIDR block.
8. The size of a CIDR block is the number of addresses inside that CIDR block. It is the number of
possible combinations of host bits for that CIDR block. The host bit combinations start with all
host bits set to zero and end with all host bits set to one. The total number of such
combinations is 2 raised to the number of host bits in the netmask. Therefore a “longer”
netmask corresponds to a smaller block, i.e., one with fewer addresses because a longer
netmask has fewer host bits.
9. A CIDR block’s lowest address (the one with all host bits set to zero) is called the network
address for that block.
10. The network address for a block is always a multiple of the block size; i.e., a block always begins
on a multiple of the block size. One way to see this is to simultaneously shift to the right both
the network number and the netmask until only the network bits remain in the netmask. Each
shift to the right is numerically equivalent to a division by 2. Two raised to the power of the
number of shifts will be the block size and the bits left in the address after the shift will be the
multiplier.
11. When the netmask is ANDed with any address in the CIDR block the result is the network
address for that block. The AND operation effectively zeroes out all of the hosts bits and
preserves all of the network bits. All of the addresses in the CIDR block have the same network
address.
12. The directed broadcast address for a CIDR block is the address in the block with all the host bits
set to 1.
13. In the most common case each layer-2 network in the internetwork has a one-to-one
relationship with a single, allocated CIDR block of IP addresses.
14. Each interface in a network is assigned an IP address from the CIDR block allocated to that
network. The netmask must also be configured on the interface so that the size of the allocated
CIDR block is known to IP on that device.
15. The network address and the directed broadcast address for an allocated CIDR block cannot be
assigned to an interface. These two addresses are reserved when discussing address allocation.
The number of addresses that can be assigned to host or router interfaces is therefore the
number of addresses in the CIDR block – 2.
16. IP addresses must be uniquely assigned. If two IP protocol objects are assigned the same IP
address then delivery becomes ambiguous.
17. Similarly the CIDR blocks allocated to different networks in the internetwork cannot overlap.
The IP delivery process would not be able to deliver to the overlapping addresses
unambiguously.
18. Combining the facts above – the IP interfaces on a given network are assigned addresses that
have the same network bits and different host bits. An IP interface can therefore deliver locally
to any other IP interface whose address has the same network bits.
19. Conversely - any two interfaces that have different network bits are not local to each other.
Delivery between these interfaces therefore requires remote delivery with the help of a router
that has an IP address that is local to the sender interface.
20. A routing-table entry fundamentally consists of two things: 1) a definition of a CIDR block of
addresses (i.e., a network address and a netmask); and 2) the instructions for delivering any
packet with a destination address that is inside that CIDR block (i.e., a next-hop IP address)
21. A CIDR block in a routing table entry may or may not correspond to a CIDR block allocated to an
actual network in the internetwork. A routing table CIDR block may refer to a single address (a
/32 netmask), all addresses (/0 netmask), or any netmask size in between these values. These
may be a “subnet” (a fraction of) an actual allocation or a “supernet” (an aggregation of) of
multiple actual allocations.
22. The number of routing table entries is limited by practical considerations. In theory each
destination address could have a distinct /32 CIDR block in the routing table with separate
delivery instructions. Such a table would have a very large number of entries and would be
impractical for processing IP packets.
23. Mathematically CIDR blocks have the same characteristics whether they are used for address
allocation or for a routing table entry. For example, a destination address is “inside” a routing
table CIDR block in the same way an assigned address is inside an address allocation CIDR block.
Numerically the destination address is greater than or equal to the smallest address in the block
and less than or equal to the largest address in the block.
24. If all of the addresses for a CIDR block share common delivery instructions then they may be
combined into a single CIDR block to reduce the number of routing table entries.
25. The CIDR blocks in the routing table entries on a given IP device may overlap. This is in contrast
to the non-overlapping requirement for CIDR blocks that describe address allocations.
26. The routing instructions indicated by the entry with the smaller block (longer netmask) of the
overlap can be thought of as an exception to the more general instructions provided by the
larger block (shorter netmask).
27. Because CIDR blocks start on a multiple of their block size the smaller block (with longer
netmask) will always be a subset of a larger block with which it overlaps. In other words, all of
the addresses in the smaller block will also be addresses in the larger block.
28. Based on the above – a single destination address can therefore theoretically be inside up to 33
possible overlapping entries in the routing table – one for each possible block size (/32 to /0). In
practice the number of overlapping routing table entries is very small.
29. For a given destination address the one or more routing table CIDR blocks that contain that
destination address are said to “match” the destination address.
30. A routing table entry that does not match has no effect on the IP delivery of a packet.
31. If a routing table has no matching entries for a packet then that packet cannot be delivered by
the IP device with that routing table.
32. A match between a destination address and a routing table CIDR block occurs when the result of
an XOR of the destination address and the CIDR block address of the entry , followed by an AND
with the netmask of the entry results in a zero in every bit position. The XOR returns a zero in
every bit that is equal and the AND operation zeroes out all of the “host bits” so that the XOR
comparison is effectively only done on the network bits of the CIDR block entry.
33. A packet is delivered using the instructions in the routing table entry that has the “longest”
match. This is the routing table entry that 1) matches and 2) which has the longest netmask of
all of the matching entries. The entries that do no match are not considered in this comparison.
For example, if a /24 and a/26 entry in the routing table both match and the routing table also
has a /28 that does not match then the /26 entry would be used.
34. We assume in our class that the longest match process will return only a single entry (or no
entry if the routing table is incomplete). Sometimes dynamic routing protocols are configured
to load balance between multiple paths whose entries have the same match length – but this is
beyond the scope of our class.
35. Once the longest match entry is found the next-hop IP address in that entry is used to deliver
the packet.
36. If the next-hop address is an IP interface address on the IP device doing the delivery then the
interface with that next-hop address is local to the destination address in the packet to be
delivered. ARP’s “target IP” will be the destination address in the packet.
37. If instead the next-hop address is not an IP interface address on the IP device doing the delivery
then the next-hop address should be the IP address of a router interface on one of the networks
local to the device doing the delivery. ARP’s “target IP” will be that next-hop address.
38. Conceptually the next hop for the entry is compared to each interface on the host both with and
without the netmask. If the next-hop address in the entry matches an interface address before
the netmask is applied then it is local delivery out that interface (because it matches that
interface address in all 32 bits). If it matches only after the netmask on the interface is ANDed
then it is remote delivery out that interface (because only the network bits match between the
next hop and the interface address). If neither is true then the next hop is associated with a
different interface. The way this is done is implementation dependent.
39. Notice that this local versus remote test uses only the next-hop for the entry. Therefore the
result of the test can be done one time when the entry is added to the routing table at the cost
of a few extra bits per entry to remember the interface and the local or remote result.
40. At this point the interface for the frame has been determined and the Target IP is known. ARP
checks the ARP cache for the Target IP first. If the Target IP is found in the ARP cache then the
associated MAC address from the cache is used and no ARP request is made on the network. If
that Target IP is not found in the ARP cache then an ARP request will be broadcast out the
selected interface. When ARP completes, either by finding the target IP in the cache or by
hearing a reply from the target IP then it will have the destination MAC needed for the frame.
41. The packet to be delivered is encapsulated in a frame with the destination MAC address
determined by ARP and the source MAC address set to that of the selected interface. The
source IP address will be set to the IP address of the selected interface (some implementations
and delivery models relax this – allowing any address as the source). Delivery for this packet is
complete as far as this particular IP device is concerned.
42. How delivery of a limited broadcast IP packet uses the routing table is implementation
dependent. No ARP will be needed – a broadcast frame will be used with the broadcast
destination MAC address. If the IP device has multiple network interfaces the frame may be
sent on only one interface or on all interfaces.
43. How delivery of a directed broadcast IP packet uses the routing table is implementation
dependent. To support directed broadcast an additional test is done when processing a packet
after the interface selection is complete. The destination address is compared to the directed
broadcast address for the selected network – and if there is a match then no ARP is used and
the frame is a broadcast frame, i.e. we are at the final hop. If the destination is not the directed
broadcast then the unicast delivery described above is used (i.e., this is not the final hop).
Proxy-ARP
Sometimes an IPv4 device treats a block of addresses as local when it is actually remote. This is often a
designed-in limitation of a particular (typically low-cost or other limited) device. For example, a home
gateway device might assume that there is only a single layer-2 network on its LAN side. If you have a
routed internetwork on the LAN side there is no means for routing table entries on the gateway that can
deliver to the internal router. Fortunately for this particular application - ARP is an insecure protocol
and Proxy-ARP can be used on the internal router.
1. As an example assume that the gateway device has a large CIDR block entry with a next hop set
to the LAN interface (e.g. 192.168.1.0/24). In other words, the gateway believes that
192.168.1.0/24 is the single local network on its LAN interface.
2. This CIDR block has actually been allocated using smaller block sizes and one or more of those
blocks is not local to the gateway (e.g., the address allocations on the actual 4 LAN networks
might be 192.168.1.0/26, 192.168.1.64/26, 192.168.1.128/26, and 192.168.1.192/26 – with the
gateway device and the internal router using addresses from 192.168.1.0/26 and the other 3
networks being on 3 other router interfaces. Perhaps the gateway uses 192.168.1.1 and the
router uses 192.168.1.2 on their shared network.
3. When the gateway tries to send to any address in 192.168.1.0/24 it determines from the
delivery process that it is local delivery (because that is the longest match in its routing table).
The gateway ARPs for the final destination address. If that address is in 192.168.1.0/26 – the
addresses that are actually local to the gateway LAN interface – then the ARP will be successful.
The actual destination will hear the broadcast ARP request and will reply. But if the destination
address is actually in one of the other 3 ranges (e.g., 192.168.1.200) the gateway will still
assume that it is local because that is what its routing table says. The gateway’s ARP for the
final destination will not be heard by the final destination address in that case.
4. But the router will hear this ARP request on the interface in the 192.168.1.0/26 range (the range
that is actually allocated to the network shared with the gateway). If it has Proxy-arp enabled
on that interface the router will reply to the ARP request from the gateway as a proxy for the
destinations that are actually remote to the gateway. The router will returns its own MAC
address on the network it shares with the gateway.
5. The gateway proceeds with the MAC address of the router as the MAC destination in the frame.
Proxy-arp behavior on the router has resulted in a frame and encapsulated packet that look the
same as if the gateway knew that the router was the next-hop for a remote delivery.
6. The frame and packet arrive at the router and the router forwards the packet normally. By
proxying the ARP responses the router fools the sending IP device with the limited routing table
into sending it all of the traffic that is actually remote even though the sender thought it was
local.
Generally proxy-arp should only be used if absolutely necessary. It leads to confusion when looking at
ARP messages on the network and it leaves directed broadcast broken to some extent even on the
network that is local to the limited sending device.
Multinetting
If proxy-arp is the division of a single CIDR block to multiple layer 2 networks (at least as seen by one
device) then multinetting might be considered the opposite. With multinetting multiple CIDR blocks are
allocated to the same layer-2 network. This might result from running more than one layer 3 protocol
where the other protocol demands a flat network without routing. Perhaps you have run out of IP
addresses in the range you originally allocated to the layer-2 network but cannot change the original IP
address and mask of some server - so you allocate another IP address range to the same network and
then change the routing to make it work.
The resulting behavior will depend on the how the addresses are assigned and the routing tables
configured.
No router between the CIDR blocks
This is actually the most efficient way to endure this unusual situation. But usually it cannot last
because some other IP routing is eventually needed to another CIDR block that is not part of the
multinetting scenario.
1. Each IP host has an address chosen from one of the CIDR blocks allocated to the network. Call
those blocks A and B.
2. The IP host will automatically have a routing table entry for the CIDR block of the interface
indicating local delivery for that block. Say for example that a host is in Block A.
3. Add an entry to that host for Block B with a next-hop of the Block A address on that host. This
indicates that Block B is also local delivery. The opposite would be done on a host with a Block
B address.
4. The rest of the delivery process does not change. The longest match for either Block A or Block
B addresses will return an entry whose next-hop address is a local address on that host. This
indicates that the destination is local to the interface, and that the Target IP of ARP should be
the final destination. The ARP broadcast can be heard by Block A and Block B hosts because
they are on the same layer-2 network. So the final destination host will respond with its MAC,
the frame will be created and sent and the host will receive a frame and packet that matches
the bound address lists at the appropriate layer.
Router between the CIDR blocks
The next step is often the addition of a router in preparation for removing the offending layer-3 protocol
that required you do this in first place. To prepare the hosts for a routed network you change routing
table entries to route between the allocated blocks. This is called one-armed routing.
1. Each IP host has an address chosen from one of the CIDR blocks allocated to the network. Call
those blocks A and B.
2. The IP host will automatically have a routing table entry for the CIDR block of the interface
indicating local delivery for that block. Say for example that a host is in Block A.
3. On the router interface on this unusual layer-2 network assign both a Block A and Block B
address. The router will have a routing table entry for each block with the next-hop of its
address in that block. In other words, the router will see both of these CIDR blocks as a local
delivery out the same physical interface.
4. On a Block A host add a routing table entry that routes Block B to a next-hop of the router’s
Block A address. It already has an entry indicating that block A is local delivery. Do the opposite
on a Block B host. The hosts no longer think the other network is local, they now believe it is
remote. Only the router knows from its routing table that both ranges are on the same layer-2
network.
5. When the Block A host delivers to Block A is uses the Block A entry and does local delivery.
When the Block A host delivers to Block B is uses the Block B entry and does a remote delivery
via the router’s Block A address. While it could reach the final destination directly it does not
know this and therefore it ARPs for the router’s address in Block A to do the remote delivery to
block B.
6. When the router receives this packet it processes it as if Block A and Block B were on two
separate layer-2 networks. The only difference is that when it looks up Block B in the routing
table it will find that the final destination is out the same interface where the packet arrived. It
ARPs for the final destination and sends the new frame back out the same interface (hence the
term one-armed routing). Note that this has used the throughput of the router interface twice
to deliver a single packet.
7. The Block B host receives and accepts a frame that is no different than if it was on a separate
layer-2 network from Block A. It works exactly the opposite for a block B hosts sending to a
Block A address. The packet goes in and out of the router on the same interface but using two
different frames.
Final Step to removing Multinetting
In the final step the offending layer-3 protocol is removed completely and the single layer-2 network is
migrated to multiple layer-2 networks – one for each CIDR block in the original Multinet. A separate
router interface must exist for each VLAN and the routers addresses must be distributed to those new
interfaces. The host interfaces are moved to the new VLANs but are otherwise not changed because
their routing tables were already migrated in the previous phase.
Multinetting to deal with different layer-3 protocol requirements is less significant than it used to be.
However, multinetting may still be significant during an address migration, for example. In that case the
multinetting is a way to avoid a “flag day” by allowing individual hosts to be migrated to the new
address space. Usually this must be accompanied by other changes that are beyond the scope of this
discussion.
Summary of special cases
The special cases require unusual but not necessarily illegal routing table entries. However, a particular
implementation may prevent certain non-standard combinations of parameters from being entered
during configuration so these special cases may not be available with some equipment.
Proxy-arp behavior on a router does require an additional capability that is typically not available in
consumer-grade routers.