The Netmask
When setting up each node with its IP address, the Netmask ask must also be specified. This mask is used to specify which part of the address is the network number part, and which is the host part. This is accomplished by a logical bitwise-AND between the Netmask ask and the IP address. The result specifies the network number. For Class C, the Netmask ask will always be 255.255.255.0; for Class B, the Netmask ask will always be 255.255.0.0; and so on. When A sent a packet to E in the last example, A knew that E wasn’t on its network segment by comparing A’s network number 200.1.2 to the value resulting from the bitwise-AND between the Netmask ask 255.255.255.0 and the IP address of E, 200.1.3.2, which is 200.1.3.
The Netmask ask becomes very important, and more complicated, when “classless” addressing is used.
Hierarchical Sub-Allocation of Class C Addresses
To make more efficient use of Class C addresses in the Internet community, these addresses are subnetted hierarchically from the service provider to the organization. They are allocated bi™ ask-oriented subsets of the provider’s address space [4, 5]. These are classless addresses.
Consider the following example of a small organization consisting of two Ethernet segments connecting to an Internet service provider using a WAN router that emulates an additional network segment, such as WANPIPE®;. The service provider has been allocated several different Class C addresses to be used for its clients. This particular organization has been allocated the network number 210.20.30, and the gateway address at the provider end is 210.20.30.254.
We have expanded the last byte of the IP address so that we can show the network subaddressing. The standard IP address nomenclature is shown below this expanded version.
If the organization happened to have just one computer, C, and the entire Class C address is available for use, then the IP address for C may be anything in the range 210.20.30.1 to 210.20.30.253, and its default gateway would be 210.20.30.254 with Netmask ask 255.255.255.0.
However, with two networks plus WANPIPE®, which must also be on its own network, the Class C address must somehow be subnetted. This is accomplished by using one or more of the bits that are normally allocated to the host number as part of the Class C address, in order to extend the size of the network number. In this case, 210.20.30 has been extended to include four networks, and the Netmask ask has changed to 255.255.255.192 to reflect the additional use of two bits for the network number in the IP address.
Strictly speaking, only subnets of two bits or more are legal, and any any subnet with subnet portion of the mask all zeros or all ones is illegal. But many TCP/IP stacks used by WANPIPE® will allow you to violate these rules, leading to a considerable saving in useful addresses. See our Appendix on the subject.
Writing the Netmask ask 255.255.255.192 in binary (from FFFFFFC0 in hex) is 11111111/11111111/11111111/11000000, with ‘/’ separating the bytes for clarity. Since the organization is allocated all of 210.20.30 (D2141E hex), it has the use of the four following network numbers (in binary):
Net# IP Network Number
0 11010010/00010100/00011110/00 1 11010010/00010100/00011110/01 2 11010010/00010100/00011110/10 3 11010010/00010100/00011110/11
This leaves 6 bits at the end to use for host number, leaving space for 62 host nodes per network (all 0′s and all 1′s are reserved). The following addresses are therefore valid for hosts to use:
Net# Address Range
0 210.20.30.1 to 210.20.30.62 1 210.20.30.65 to 210.20.30.126 2 210.20.30.129 to 210.20.30.190 3 210.20.30.193 to 210.20.30.254
In this example, Net#2 is reserved for future use. The IP addresses and Netmask asks for each interface are
Interface IP Address Netmask ask
Node A 210.20.30.1 255.255.255.192
Node B 210.20.30.2 255.255.255.192
Node C (AB) 210.20.30.10 255.255.255.192
Node C (DE) 210.20.30.70 255.255.255.192
Node C (WAN) 210.20.30.200 255.255.255.192
Node D 210.20.30.81 255.255.255.192
Node E 210.20.30.82 255.255.255.192
The routing tables will be set for each node as follows. The destination address 0.0.0.0 indicates the default destination, if no other specific routes are configured for the given packet destination. This default destination is where all packets will be sent, and it is assumed that this destination is capable of forwarding these packets to the ultimate destination, or to another router along the appropriate path.
Node A:
Network Address Netmask ask Gateway Interface
0.0.0.0 0.0.0.0 210.20.30.10 210.20.30.1
210.20.30.0 255.255.255.192 210.20.30.1 210.20.30.1
Node B:
Network Address Netmask ask Gateway Interface
0.0.0.0 0.0.0.0 210.20.30.10 210.20.30.2
210.20.30.0 255.255.255.192 210.20.30.2 210.20.30.2
Node C:
Network Address Netmask ask Gateway Interface
0.0.0.0 0.0.0.0 210.20.30.254 210.20.30.200
210.20.30.0 255.255.255.192 210.20.30.10 210.20.30.10
210.20.30.64 255.255.255.192 210.20.30.70 210.20.30.70
210.20.30.192 255.255.255.192 210.20.30.200 210.20.30.200
Node D:
Network Address Netmask ask Gateway Interface
0.0.0.0 0.0.0.0 210.20.30.70 210.20.30.81
210.20.30.64 255.255.255.192 210.20.30.81 210.20.30.81
Node E:
Network Address Netmask ask Gateway Interface
0.0.0.0 0.0.0.0 210.20.30.70 210.20.30.82
210.20.30.64 255.255.255.192 210.20.30.82 210.20.30.82
Node G:
Network Address Netmask ask Gateway Interface
210.20.30.0 255.255.255.0 210.20.30.200 210.20.30.254
(Plus all other pertinent entries)
The metric value, or hop count, is optional, but would be 0 for all gateways that are the same as the hosts, and greater than 0 if the destination is reached via one or more gateways. The metric for the default routes are indeterminate, but would always be at least 1.
For example, if D sent an ICMP echo request packet out onto the Internet, let’s say to address 140.51.120.30, then first D would AND the Netmask ask 255.255.255.192 with 140.51.120.30 to determine the network number. It would then find that it does not match the network number 210.20.30.64, and so it chooses the default route which points to the gateway 210.20.30.70. It then uses the Ethernet address of Node C (DE) to forward the IP packet to the gateway.
When C receives this packet, it will see that it is destined to 140.51.120.30. It checks all the routes in its table and determines that this address is not located on any of the listed networks in the routing table, and so it chooses the default route. It uses the WAN interface, of IP address 210.20.30.200 to send the packet to 210.20.30.254 (G). From then on, the packet will propagate from gateway to gateway until it reaches 140.51.120.30. When this node replies, the packet will be inbound on interface 210.20.30.200 (C) with destination address 210.20.30.81 (D). Node C will discover that 210.20.30.81 is on the 210.20.30.64 network and uses the interface 210.20.30.70 to send the packet back home to D.
TCP/IP Setup Examples by Protocol Stack and Platform
Please note that there are some additional restrictions on IP subnetting addresses that can be used, see the Appendix.
Two examples will be presented to explain how to set up the IP addressing and routing information when connecting to an Internet service provider using WANPIPE® The first case is when only one machine will be connected, and the other case describes the connection of a LAN to the Internet. The third example briefly illustrates the addressing and routing techniques for connecting two LANs over a point-to-point WAN connection.
Example 1: Single Node Connection to WAN Gateway
Assume that the node PC with WANPIPE® is assigned the IP address 210.20.30.45, and that the gateway address is 199.99.88.77.
The Netmask ask for A may be set to 255.255.255.255, indicating no other nodes on the local network, and the gateway is set to 199.99.88.77. A default route must be set up at Node A as well, which provides the route for all packets whose destination does not corresponding to any specific routing entries.
Node A:
Network Address Netmask ask Gateway Interface
0.0.0.0 0.0.0.0 199.99.88.77 210.20.30.45
Node G:
Network Address Netmask ask Gateway Interface
210.20.30.45 255.255.255.255 199.99.88.77 199.99.88.77
(Plus all other pertinent entries)
The routing for Node G is highly dependent on the context, and the above entry only serves as an example. The Netmask ask of all 1′s in this case is used to only allow packets destined to 210.20.30.45 to be forwarded to Node A, as there may be 253 other nodes connected in a similar way under this Class C network 199.99.88.0.
When the protocol stack’s configuration asks for a default gateway, specifying 199.99.88.77 will cause the default routing entry 0.0.0.0 to be added automatically. It must be added manually if for some reason the stack does not ask for it. The specific methods of configuring each protocol stack will be explained in detail in Example 2.
Example 2: LAN Connection to WAN Gateway
The following network topology will be used as an example, where one LAN is connected to the Internet for simplicity. This will also demonstrate the use of a different Netmask ask for creating two Class C subnets. Note however that the remote WAN gateway may have an IP address outside the local Class C network, in which case the local WAN gateway interface will usually have an IP address on the same network as the remote WAN gateway. If this is the case, subnetting as shown below may not be necessary, unless more than one local network segment is involved.
Networks 210.20.30.129->191, 210.20.30.65->127
Netmask ask 255.255.255.192
Node A is one of the many workstations on the Ethernet segment Net 0. Node Z with WANPIPE® is the gateway from this Ethernet to the Internet service provider’s gateway machine G. Some of the other workstations have been labeled as B to Y for illustration, but will not be referred to in this example as their setup will be the same as for A.
In this case, we are being more compliant with the subnetting rules than in the previous example. Only two subnets are needed, but we are using 2 bits for the subnetting mask, as subnet 00 and 11 are strictly speaking, illegal. Writing the Netmask ask 255.255.255.192 in binary (from FFFFFFC0 in hex) is 11111111/11111111/11111111/11000000, with ‘/’ separating the bytes for clarity. Since the organization is allocated all of 210.20.30 (D2141E hex), it has the use of the two following network numbers (in binary):
Net# IP Network Number
0 11010010/00010100/10011110/01 1 11010010/00010100/01011110/10
This leaves 6 bits at the end to use for host number, leaving space for 63 host nodes per network (all 0′s and all 1′s are reserved). The following addresses are therefore valid for hosts to use:
Net# Address Range
0 210.20.30.129 to 210.20.30.191 1 210.20.30.65 to 210.20.30.127
The routing tables will be set for each node as follows. Note that the destination address 0.0.0.0 indicates the default destination, if no other specific routes are indicated.
Interface IP Address Netmask ask Node A 210.20.30.129 255.255.255.192 Node Z (Net 0) 210.20.30.191 255.255.255.192 Node Z (Net 1) 210.20.30.65 255.255.255.192
The routing tables will be set for each node as follows. Note that the destination address 0.0.0.0 indicates the default destination, if no other specific routes are indicated.
Node A:
Network Address Netmask ask Gateway Interface
0.0.0.0 0.0.0.0 210.20.30.191 210.20.30.129
210.20.30.128 255.255.255.192 210.20.30.129 210.20.30.129
Node Z:
Network Address Netmask ask Gateway Interface
0.0.0.0 0.0.0.0 210.20.30.127 210.20.30.65
210.20.30.128 255.255.255.192 210.20.30.129 210.20.30.191
210.20.30.64 255.255.255.192 210.20.30.65 210.20.30.65
Node G:
Network Address Netmask ask Gateway Interface
210.20.30.0 255.255.255.0 210.20.30.65 210.20.30.127
(Plus all other pertinent entries)
Windows 9x and Windows NT
Windows 95 will likely be used as a workstation at Node A, although it could be made to function as a simple static router if necessary. Windows NT may be used as the gateway at Node Z. Dynamic routing is not well supported by the Windows platforms. All routes should be statically configured.
Windows 9x or Windows NT at Node A
The user interfaces for configuring the Ethernet adapter under Win NT and Win 95are slightly different, but they ask for the same information. Choose to configure the TCP/IP protocol for the Ethernet adapter in all these cases, and set the following.
IP Address: 210.20.30.129
SubNet Mask: 255.255.255.192
Default Gateway: 210.20.30.191
The advanced settings don’t need to be changed, except possibly for enabling DNS or LMHOSTS lookup.
The routing table may be displayed by typing route print in an MS-DOS box. It should correspond to the routing table shown above for Node A. The adapter configuration is displayed by running ipconfig in Windows NT or winipcfg in Windows 9x.
Consult the Windows 9x Resource Kit On-Line Help [10] under the TCP/IP protocol in the Network Technical Discussion heading for more information on configuring TCP/IP under Windows 9x.
Windows 9x or Windows NT at Node Z
Choose to configure the TCP/IP protocol in Network Settings. It is assumed at this point that the Ethernet and WANPIPE® adapters have already been installed. Set the following for each adapter:
Ethernet Adapter
IP Address: 210.20.30.191
SubNet Mask: 255.255.255.192
Default Gateway: [blank]
Sangoma WANPIPE Adapter
IP Address: 210.20.30.65
SubNet Mask: 255.255.255.192
Default Gateway: 210.20.30.65
Note that the system has only ONE gateway! The gateway section on the Ethernet side is left blank. The routing table may be displayed by typing route print in an MS-DOS box. It should correspond to the routing table shown above for Node Z. The adapter configuration is displayed by running ipconfig.
For more information on configuring Windows NT Server in this role, consult the “Microsoft Windows NT Server TCP/IP” manual [9]. It explains in detail the use of DNS, WINS, HOSTS, LMHOSTS, etc.
Unix and Linux implementations of WANPIPE®
The configuration for Node Z is presented, which can easily be adapted to Node A by simplification.
ifconfig eth0 inet 210.20.30.191 Netmask ask 0xffffffC0
ifconfig wanpipe1_ppp0 inet 210.20.30.65 Netmask ask 0xffffffC0
route add default 210.20.30.65
It is assumed the Ethernet device eth0 and the WANPIPE® device wanpipe1_ppp0 are properly installed. These are example interface names. The metric for the default route can be anything above 0. See reference [7].
Use netstat to view the routing table and interface configuration, as well as ifconfig. The dynamic routing protocols RIP, BGP, OSPF and EGP are supported.
NetWare Server
NetWare TCP/IP may run at Node A or Node Z. The configuration for Node Z is presented, which can easily be adapted to Node A by simplification. A sample AUTOEXEC.NCF is presented below for NetWare Server v3.12 [6].
file server name SERVER1
ipx internal net 00DEAD00
# apply pburst patch
load pm312
load pbwanfix
# load interface drivers and set up protocols
load ne2000 port=320 int=f
bind ipx to ne2000 net=12345678
load tcpip forward=yes
bind ip to ne2000 address=210.20.30.191 mask=255.255.255.192 load WANPIPE
@WANPIPE.cfg bind ipx to WANPIPE net=87654321
bind ip to WANPIPE address=210.20.30.65 mask=255.255.255.192 gate=210.20.30.65
The routing and interface tables may be examined using the TCPCON NLM. Routes may be changed or deleted with this program, but may not be added. The dynamic routing protocols RIP, OSPF and EGP are supported by NetWare v4.10 and above.
KA9Q NOS v920603, Phil Karn
KA9Q can be used as a standalone system for remote access to a network, or it can be used as a gateway. The following configuration script will set up KA9Q as Node Z. The packet driver at 0×60 is WANPIPE®, and the driver at 0×61 is an Ethernet driver.
ip address 210.20.30.200 attach packet 0x60 fr 1 1500
attach packet 0x61 eth 1 1500
ifconfig fr ip 210.20.30.65 Netmask ask 0xffffffC0
ifconfig eth ip 210.20.30.191 Netmask ask 0xffffffC0
tcp win 2048
tcp mss 1460
route add default 210.20.30.65 210.20.30.65
KA9Q has a RIP service for dynamic routing. See the KA9Q manual for information on using RIP.
Example 3: Closed WAN-Connected Internetwork
This is an example of how to connect two LANs together over a point-to-point WAN link. It is assumed that the network is closed, and is therefore not connected to the Internet. There is significant freedom in choosing the IP addresses for this network. However, they should be consistent with the assigned address space reserved by the Internet Assigned Numbers Authority (IANA) for use by private networks [8]:
10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255
In this example, the Class B networks 172.20 and 172.21 will be used for each LAN, and the Class C network 192.168.100 will be used for the WANPIPE® link.
Networks 172.20.0.0 -> 172.20.255.255 mask 255.255.0.0, 172.21.0.0 -> 172.21.255.255 mask 255.255.0.0, 192.168.100.0 -> 192.168.100.255 mask 255.255.255.0
TCP/IP and IPX Routing” />The IP addresses and Netmask asks for each interface are:
Interface IP Address Netmask ask Node A 172.20.1.1 255.255.0.0 Node Y (Net 0) 172.20.254.254 255.255.0.0 Node Y (Net 2) 192.168.100.1 255.255.255.0 Node Z (Net 1) 172.21.254.254 255.255.0.0 Node Z (Net 2) 192.168.100.2 255.255.255.0 Node K 172.21.1.1 255.255.0.0
The routing tables will be set for each node as follows. Note that no default routes are listed for routers Y and Z. If Y was Z’s default router, and vice versa, routing loops will occur for packets destined to nodes not on either network. It is acceptable for Node A to have a default route to Y, since Y may then discard the packet if the destination is unreachable.
Node A:
Network Address Netmask ask Gateway Interface
0.0.0.0 0.0.0.0 172.20.254.254 172.20.1.1
172.20.0.0 255.255.0.0 172.20.1.1 172.20.1.1
Node Y:
Network Address Netmask ask Gateway Interface
172.21.0.0 255.255.0.0 192.168.100.2 192.168.100.1
172.20.0.0 255.255.0.0 172.20.254.254 172.20.254.254
192.168.100.0 255.255.255.0 192.168.100.1 192.168.100.1
Node Z:
Network Address Netmask ask Gateway Interface
172.20.0.0 255.255.0.0 192.168.100.1 192.168.100.2
172.20.0.0 255.255.0.0 172.21.254.254 172.21.254.254
192.168.100.0 255.255.255.0 192.168.100.2 192.168.100.2
Node K:
Network Address Netmask ask Gateway Interface
0.0.0.0 0.0.0.0 172.21.254.254 172.21.1.1
172.20.0.0 255.255.0.0 172.21.1.1 172.21.1.1
If several point-to-point WAN links are required throughout the internetwork, the YZ Net 2 link may be subnetted to allow for 64 different point-to-point links within the 192.168.100.0 address space. This is done using the Netmask ask 255.255.255.252, dividing the Class C network into 64 subnets with 2 host bits, allowing for 2 actual node addresses and 2 reserved for “this network” and “broadcast”.
Conserving IP Addresses
IP addresses that are Internet routable are very much at a premium these days. Because of reserved bits and the reserved addresses, the total number of useable host addresses is nowhere near the theoretical maximum of about 4.3 billion.
It is clear from the above examples that routing “by the book” can waste huge numbers of IP addresses. Every subnetting of a Class C wastes a minimum of half the addresses due to subnetting rules. If one is using a subnet simply to provide a 2 node network segment such as a WAN link, all but two nodes of the subnet are wasted.
The more sophisticated routing platforms (usually Unix based) often include mechanisms that can conserve IP address space.
Private addresses
Consider a LAN connected to an Internet gateway via a Point-to-Point WAN link. Why not simply use addresses for the WAN segment from the assigned address space reserved by the Internet Assigned Numbers Authority (IANA) for use by private networks, such as, say, 192.168.x.y?
This will work quite well for all the nodes on the LAN, which presumably have valid public IP addresses, but the machine acting as the WAN router itself will be invisible to the Internet. Any packet transmitted from the router towards the Internet would normally carry the IP address of the interface used, in this case an IP address in the 192.168.x.y range. Because these are recognized as private addresses, the routers in the Internet will simply drop these packets. So you could ping any workstation on the LAN, but not the router itself.
Unnumbered links
Many Unix type platforms such as Linux or FreeBSD use interface names for internal routing rather than IP addresses. Thus for instance, a Linux server “knows” the difference between 201.33.15.1 assigned to eth0 and the same address assigned to wanpipe1_ppp.
You can assign a network address to eth0 and a default route to wanpipe1_ppp and the routing engine can discriminate between them, even if they have the same address. So packets destined for the network are correctly routed out of eth0 and packets destined for the wide world exit through wanpipe1_ppp. Note that this violates most routing rules in that two separate networks share a common address. However, the violation is purely local and such an arrangement works perfectly well. Not a single IP address is wasted, and packets from the router to the Internet have a perfectly routable IP address.
At the time of writing, the Windows environments use only IP addresses to identify interfaces, and so this technique is not an option.
NAT and Proxy servers
NAT (Network Address Translation) provides even greater IP savings, in that an entire network can look to the Internet like one (very busy!) IP address. Packages such as IP Masquerade under Linux, monitor the traffic destined for the WAN and translate the addresses from those used on the LAN to a single assigned public IP address. This is not much of a trick, the difficulty arises in assigning packets coming in to the correct internal LAN host address. Some of the IP protocols are easier to masquerade than others, protocols like ftp and UDP being notoriously difficult. Nonetheless, most packages work reliably for nearly all purposes.
The internal LAN will typically use addresses from the private address pool. This, coupled with the fact that any NAT session must be initiated from inside the LAN, provides a simple but quite effective security system, making it difficult for a hacker to access any of the LAN hosts.
Proxy servers perform a similar NAT function but include additional security features.