Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

IP networking: CIDR, NAT and more

By Eddie Lord. Published: 13th Sep 2004, 22:11:28 | Permalink | Printable

Part three final

For his concluding article on IP networks, Eddie Lord explains and discusses how, behind the scenes, the Internet coped with its rapid and unforeseen expansion, and also other issues involved in public and private networks.

In the first of these three articles, I covered the basics of IP addressing, beginning with the original class system, detailing the twin problems of IP address space exhaustion and the unmanageable growth in the routing tables. In the second part, I continued with an introduction to netmasks, and then discussed subnetting as a partial solution to these two major problems. Subnetting is an ideal solution for individual organisations such as a university or a large company, but on a global scale subnetting on its own wasn’t sufficient.

By 1990, it was becoming obvious that these problems were reaching crisis levels, and that they would eventually lead to the stagnation of the Internet.

In 1993, a new regime of IP addressing, called Classless Inter-Domain Routing (CIDR, pronounced ‘cider’) was introduced. This abandoned the class system altogether, and made a large number of changes in the way IP addresses were allocated and used. Although CIDR is a far more efficient method of allocating the remaining IP address space, it also has to sit side-by-side with the legacy networks based on the original class system.

CIDR insider
By the time CIDR was introduced, most class A and B addresses had been allocated, leaving the majority of class C addresses available which nobody wanted at the time, due to their small size. The solution is to use up the class C workspace by combining several class C networks into one continuous network which would then be a useful size for an organisation. This is often called ‘supernetting’.

One other major aspect of CIDR is that it allows for several routes to be combined into a single entry in the routing tables. Combining several class C networks together is a good example of this effect and is called ‘route aggregation’. Thus, one entry can represent many thousands of addresses lower down the hierarchy. Without route aggregation, the growth in the routing tables would have brought the Internet to a standstill.

Many of the A and B allocations are seriously under-used. The Internet authority has started a campaign to recover some of these unused numbers, but naturally many of the owners are reluctant to hand back any of their allocations. CIDR also means that holes in the class A and B address space can be carved out, and any unused or returned numbers can easily be allocated without any of the restrictions of the old class system.
The new scheme also meant that many of the old classic restrictions were removed, and it became possible to use some of the reserved addresses, for example when subnetting, as I described in part two.

In part two, I briefly mentioned the network prefix as a shorthand method of writing the netmask. With the restructuring of the IP address space the concept of classes, with the fixed network addresses defined by the prefixes /8, /16, /24, was replaced by the concept of a network prefix that can, in theory, be of any length (up to /32). As a result of this change, Internet routers now have to advertise the prefix length in addition to the destination IP address. This, of course, required updated software for all CIDR capable routers and hosts.

The net prefix revisited
Under CIDR, IP addresses are combined with a prefix number which represents the number of bits making up the network address. This is equivalent to the number of binary 1’s in the traditional netmask.

To recap the principle: an address of (say) 192.168.0.0, with a subnet mask of 255.255.255.224, would be written as 192.168.0.0/27, where /27 indicates that the netmask has 27 1’s followed by five 0’s (making up the 32 bits required of a netmask). Thus: /27 gives the number of significant bits used as the network address, hence the name prefix.

A pure class A address would be written as a /8 address, a class B as /16, and a class C as /24.

You may also find that addresses are shortened even more. For example, 172.16.0.0/12 can be written as 172.16/12 or 10.0.0.0/8 can be written as 10/8. The zeros are assumed and can be left out. If an address is quoted as 10/8, this covers all the addresses from 10.0.0.0 to 10.255.255.255, whereas 172.16/12 covers the address range from 172.16.0.0 to 172.31.255.255.

Once the class distinction of fixed prefixes was removed, it became possible to use any prefix with any address regardless of its original class, although, in practice, this is confined to using prefixes between /13 and /27.

Instead of relying on the first three bits of an address to route information, a router that supports CIDR will now use the advertised prefix to route messages. This brings about tremendous flexibility, in that address allocations could be tailored to the actual needs of an organisation. For example, blocks of addresses can be assigned for networks of just 32 hosts (/27) or even networks featuring over 500,000 hosts (/13).

Table 1 shows the prefix and netmask equivalent. It also shows the number of hosts supported for each prefix, and it shows the number of old class networks that have been combined.

Table 1: CIDR prefix and networks
CIDRprefixSubnet maskEquivalentnumberof class CnetworksHost bitshNo. of available hosts per subnet
2h - 2
/13255.248.0.02048 C19524,286
/14255.252.0.01024 C18262,142
/15255.254.0.0512 C17131,070
/16255.255.0.01 B or 256 C1665,534
/17255.255.128.0128 C1532,766
/18255.255.192.064 C1416,382
/19255.255.224.032 C138,190
/20255.255.240.016 C124,094
/21255.255.248.08 C112,046
/22255.255.252.04 C101,022
/23255.255.254.02 C9510
/24255.255.255.01 C8254
/25255.255.255.128½ C7126
/26255.255.255.192¼ C662
/27255.255.255.2241/8 C530
/28255.255.255.2401/16 C414
/29255.255.255.2481/32 C36
/30255.255.255.2521/64 C22


Table 1 – CIDR prefix and networks


Note how a change in the prefix alters the number of hosts supported. Every time the prefix increases by one, the number of supported addresses is halved. Thus: a /22 prefix supports 1024 (210) addresses, whilst a /23 supports 512 (29) addresses. So a /22 network can be subdivided into one /23 and two /24 networks or perhaps one /23, one /24 and two /25s. This last subdivision is illustrated in Figure 1.

Figure 1: Subdividing CIDR addresses


The supernet
Now let us look at an example of combining several class C addresses. Take the four network addresses 192.168.64.0 to 192.168.67.0 as shown in table 2 and figure 1.

The network addresses of this supernet will range from the network address of the first network, to the broadcast address of last network. From table 2, notice how the class C networks 1—4 all have the first 22 bits in common (shown in bold type). A /22 netmask will join these networks together creating a network that will support 1024 addresses. The routers will now treat this as one big network reducing the number of routes presented to the backbone from four to one.

From part two, you may recall that subnetting was based on borrowing the subnetting bits from the host bits. This gave us more networks, but fewer hosts per network. With supernetting we, in effect, borrow from the network part, making fewer networks, which increases the number of hosts per network. This is illustrated in the table 2 by the ‘Sn’ column. In this case, two bits of the class C address have been allocated. Thus, the first 22 bits of the address becomes the network address.

Table 2: Supernetting 4 class C networks
NetworkDotted decimalBinaryClass info
Network address
22 bits
Host ID
Sn
1192 . 168 .  64 .   011000000.10101000.01000000.00000000Private class C net 1
2192 . 168 .  65 .   011000000.10101000.01000001.00000000Private class C net 2
3192 . 168 .  66 .   011000000.10101000.01000010.00000000Private class C net 3
4192 . 168 .  67 .   011000000.10101000.01000011.00000000Private class C net 4
Supernet192 . 168 .  64 .   011000000.10101000.01000000.00000000Supernet network address
255 . 255 . 252 .   011111111.11111111.11111100.00000000Netmask (/22)
192 . 168 .  67 . 25511000000.10101000.01000011.11111111Supernet broadcast address


Table 2 – Supernetting 4 class C networks


The network and broadcast addresses of the ‘in between’ class C subnets can now be allocated to hosts, lifting another of the old class restrictions.

Even though CIDR removes the need to reserve the ‘all 0’s’ and ‘all 1’s’ broadcast addresses, backwards compatibility and some TCP/IP implementations still expect these addresses to be reserved. So, for these reasons, the network and broadcast address of the supernetted network are reserved.

In order to supernet networks together, the following simple rules should be followed:
  • The networks to be supernetted must have a continuous string of addresses. In the jargon, the networks have to be ‘contiguous’, and this is the process of address aggregation.
  • The number of networks to be supernetted must be in powers of two. It’s not possible, for instance, to supernet three class C networks together.
  • A further restriction is that the third byte of the first (lowest) class C address to be supernetted must be divisible by the number of nets to be supernetted. In our example, the third byte is 64, and this is divisible by four. For example, it’s not possible to supernet the two class C networks 192.168.67.0 and 192.168.68.0, as 67 is not divisible by two.


The CIDR network
These days, any organisation that requires a block of IP addresses must obtain them from within the block of addresses allocated to the ISP, rather than directly from IANA. Problems can arise if an organisation contemplates a change of ISP, since IP numbers are generally rented not owned. There are exceptions to this, but keeping a block of IP numbers and then moving to another provider destroys the whole point of CIDR.

In the past, if an organisation requires 800 hosts, a class B address may have been allocated (wasting some 64,700 addresses) or, alternatively, they may have been allocated four class Cs blocks (which would introduce four new routes into the global routing tables). With CIDR, the ISP can allocate a /22 block giving 1024 addresses, which is sufficient for the 800 required with some room for future expansion.

The use of a prefix to define a block of addresses means that CIDR networks can only be allocated in ‘power of two’ blocks.

CIDR also brought changes to the routing protocols. Each packet sent over the Internet contains the subnet prefix in the destination field as well as the destination IP. The router compares the network address with its tables, as before, and, if a match is found, the packet is routed to the next hop. If no match is found, the packet is sent to the default gateway address. The change here is that, if a match is found with more than one entry, the packet is sent to the next hop with the longest match.

Example CIDR network
Have a look at figure 2 now. Imagine that an ISP has been allocated an address block with a /18 prefix, giving it 16,384 (214) addresses. The ISP will allocate blocks of addresses to its customers, from within its own allocation. (ISP ‘A’ may, of course, have other blocks allocated to it, but for simplicity these have been ignored.)

Figure 2 – A typical CIDR network


In this example, ISP ‘A’ has been allocated a /22 block to Major Co., giving it 1024 (210) addresses, which in turn may be further divided into two or more networks, perhaps a /23 and two /24 blocks. ISP ‘A’ has also allocated a /20 block, with 4096 (212) addresses, to its subsidiary ISP ‘B’, which in turn has allocated our router, R1, with one IP address of 201.111.65.33. (In practice, most addresses allocated in this way are dynamic, and so the actual address might change from time to time.)

If we have several machines that need to share the Internet, then creating a small private network behind our router modem will give the required access to the Internet.

Looking now at the backbone router, the only entry in its routing table for this corner of the Internet is 201.111.64.0/18 – it knows nothing about the Major Co., or ISP ‘B’. In fact, ISP ‘A’ will accept any message matching 201.111.64.0/18 (201.111.64.0 to 201.111.127.255). The advantage of this method of allocation is that only the /18 address is logged in the backbone routing tables. All other addresses downstream are hidden from the backbone, but hosts can still send and receive data via the higher level address.

Creating a simple home LAN
Upstream of your modem router, out there on the Internet, CIDR is the modern protocol. However, in building a small network at home, following the classic subnetting rules will probably make things easier.

We can design our own network by choosing a set of IP addresses from the private range of IP numbers. For simplicity, choose a netmask of 255.255.255.0, which is probably the most commonly used netmask. This, of course, is the default class C mask. If we use this netmask, we will have 254 available host addresses to choose from. Starting with the reserved network address of 192.168.0.0, it’s convention to set the LAN side of the router, R1, to 192.168.0.1. We can label each host in turn starting with 192.168.0.2 etc, not forgetting that the broadcast addresses of 192.168.0.255 is reserved. Any traffic sent to 192.168.0.1, which is the gateway address for our private network, will be sent out to the Internet.

Note that all the hosts on the home network must have the same netmask, otherwise some of the hosts won’t be available. If we accidentally label one host as (say) 192.169.0.2, it will be outside the network and won’t be seen by the other hosts. Using the same IP address for two hosts will result in problems too. In addition, I have seen advice that using an IP address of 10.0.0.x causes problems with ShareFS in some circumstances. Personally, I haven’t had a problem with this but you can read more about it on Rick Murray's website.

Your choice of IP addresses and netmask may well be dictated by the default settings of the router kit, and one of the DSL routers I bought from R-Comp defaulted to 10.0.0.2 with a mask of 255.0.0.0. You will find that in this classless Internet, many bits of kit will default to the basic classic details.

Supporting protocols
In this series of articles, I’ve concentrated on IP addressing. However, there are several auxiliary protocols that support IP addressing. Some of these are:
  • Network Address Translation (NAT)
  • Dynamic Host Configuration Protocol (DHCP)
  • Address Resolution Protocol (ARP)
  • Domain Name Service (DNS)


There are many other protocols, but I want to just mention, briefly, NAT, DHCP, ARP and DNS as they impinge directly on our examination of IP addressing.

The NAT protocol
During these discussions I’ve advocated using the IANA private address space to connect your home LAN to the Internet, but I haven’t said how the router manages the crossover from a private address to the ISP allocated public address.

A router will use Network Address Translation (NAT) to act as a ‘border control’ between the local network and another network, such as the Internet. It does this by maintaining a table which maps the local private addresses to the public address (or addresses, if there are more than one). The NAT table is dynamic, with entries constantly being created or deleted according to the traffic flow. NAT comes in three flavours, but the one that interests us is the ‘NAT overload’ mode, commonly called ‘network address port translation’ (NAPT), but also ‘port address translation’ or even ‘IP masquerade’.

Any datagram packet sent from a private host has its source IP address converted on the fly to the IP address of the registered public address. The router makes an entry in its table of the packet source address and its port number, ready to convert any reply back to the correct address for delivery to the local host. The port number is used to identify which of the local hosts was the originating source.

There are a number of advantages to using NAT. Conversions are done on the fly and are fast. It’s economic, as NAT is cheap and part of any modern router. It also means that you don’t have to pay for more than one public IP address.

One major side benefit of NAT is that hosts on the local network can’t be addressed directly from outside, which provides for a simple firewall. This isn’t really a substitute for a proper firewall, but it’s pretty effective all the same. This assumes that you have at least changed the default password in the administration controls for your router hardware. Sadly, this may have to be done on a non-standard i.e non-riscos computer.

To the outside world, packets coming from the LAN look as though they are coming from your allocated public IP address, and so the ISP, generally speaking, doesn’t need to know how many machines are using the router.

DHCP
The Dynamic Host Configuration Protocol (DHCP) is used to administer the automatic allocation of IP addresses. Up to now, I’ve assumed that all the IP addresses of the local hosts will be entered manually. For most RISC OS users, this is indeed the case. However, RISC OS Select and RISC OS 5 both allow DHCP to be used and it very much simplifies the setup of a local network. DHCP has the advantage that computers supporting DHCP can be added to the local network and be automatically configured to the required IP address and netmask, easing the burden on the site administrator.

When a DHCP-enabled host is booted up, it will make a request on the broadcast address 255.255.255.255 for the lease of an IP address. The DHCP server will reply on the network address of 0.0.0.0 giving the relevant IP address to the host. This IP address is valid for only a certain period of time, called the lease period. The host will renegotiate the lease at regular intervals and thus maintain the same IP address for the time the host is online, or other configured time.

Using a router-modem as the DHCP server would be the most suitable course of action. It’s also possible to have hosts with fixed IP addresses share the network with DHCP-enabled hosts. The fixed IP addresses just need to be stored in the DHCP tables on the server.

The DNS protocol
From all the discussion so far, it should be evident that networks require an IP address for any routing and delivery of a datagram packet. Unfortunately, we humans are not very good at remembering numbers, so ‘hostnames’ are used. Now all we require is a method of translating the more human friendly names into the IP address actually needed by the network. Working behind the scenes, the Domain Name Service (DNS) does this translation automatically for us.

When you set up an Internet connection, your ISP will provide you with one or two DNS Server addresses, (ISPs are required to have two servers for this purpose to maintain the integrity of the system). When you type in the required host URL, for example www.drobe.co.uk, a request is sent via the 'Resolver' module to the ISP DNS server. After a short delay, this will send the correct IP address back to you, and allow you to connect to the required website. How is it done?

Distributed around the Internet there are 13 special machines that are known as Root Name Servers. These special servers keep a database of all the other computers that handle the top level names such as .com, .edu, .org, .gov, .mil, .uk, etc. The ISP DNS server will send your request to the nearest root level server, to find out what it knows about www.drobe.co.uk. The root server will send the location of the .uk server back to the ISP. The ISP name server will then ask the .uk DNS machine if it knows our URL. The response will tell us the location of the .co server and so on down the hierarchy. The request will hop back and forth from one DNS server to the next until the exact match is found, and the IP address is sent back to your local host.

Your ISP will also keep a temporary cache of all the addresses it has found, in case they are required by other users, so a second search for the same name should be faster. In practise, the ISP name server will probably go directly to the .co.uk DNS server because the .co.uk will probably be permanently in the cache, thus speeding up any search for these hostnames.

The MAC address
Let us just finish off with one more type of address. The Media Access Control (MAC) address is a world unique six byte or 48 bit binary number that is burnt into every network interface card (NIC) and is always quoted as a hex number. For example, the MAC address may look like 00-09-95-00-31-C6. The first three hex numbers identify the manufacturer, whilst the last three hex numbers are the serial number assigned by that manufacturer.

All the manufacturer codes are registered with the Institute of Electrical and Electronic Engineers (IEEE). The number 00-09-95 is registered to Castle Technology Ltd, whilst 00-01-3D is registered to RiscStation Ltd and ARM have 00-02-F7. This means that the MAC address is the physical address of the network card fitted to the host, whilst the IP address is known as a ‘logical’ address.

Consider the IP address as being the software part of the network, whilst the MAC address is the hardware component of the network. If the host were to be moved to another network, the IP address may well have to change, but the MAC address would not, as it’s burnt into the device and so, generally, can’t be changed.

Network routers have to maintain a map of the host’s IP address and its MAC address. This mapping is known as the ARP cache or table. ARP stands for ‘Address Resolution Protocol’, which provides the logic for fetching the map and keeping the cache up-to-date. The MAC address is used by a number of protocols and even for software security protection. DHCP also relies on the MAC address to identify the host that has requested the lease of an IP address.

IPv6 (IPng – next generation)
CIDR hasn’t cured all the problems of the Internet, and it has introduced some problems of its own. The eventual exhaustion of the 32­bit IP address space is only a matter of time. The replacement for IPv4 is IPv6 or IPng as it’s sometimes called. This was proposed in 1995 and has been in development since then.

The biggest change is to the number of bits used from 32 bits to 128 bits. This is the most obvious change, but there are a number of other important changes in how it all works. For example:
  • Data packets are put together in a different and more efficient manner allowing for a number of improvements.
  • IP4 addresses can be embedded into the packet header which will help ease the transition from the current format to IPv6.
  • Security is built-in.
  • Broadcast addresses aren’t used.


Addresses are written in hexadecimal rather than dotted decimal. This will consist of eight 16-bit chunks, written in hex. This is a more compact method when you consider that the address is 128 bits long.

A typical example might be: fe80:0000:0000:0000:0204:93ff:fe5b:aee4.

IPv6 is available now, but it’s confined to those large organisations that require the advantages of virtually unlimited IP addresses such as telecoms companies. After all, when your kids want to play peer-to-peer games via their mobiles you will need a lot of IP numbers. Interestingly, the latest version of Mac OS X is IPv6-ready, with a default network prefix of /64, and Castle's Tematic division mentioned IPv6 support in their list of recent developments.

Conclusion
This concludes the discussion on IP addressing and netmasks. There’s a lot more that could be said, and indeed some areas have been glossed over to reduce the complexity of the subject. The intention has been to give a good overview of netmasks and IP addressing in order to make subnetting your own LAN a little easier to understand. I hope you have been able to follow my explanation of the concepts.

Acknowledgments
My grateful thanks to John McCartney for taking time to proof read this series, and for his many valuable suggestions. Thanks also to Ray Favre for his time and effort in sorting out my many Dr Wimp queries, not to mention the efforts of the c.s.a.programming group for their help in answering my questions. Thanks also to Archive editor Paul Beverley for his efforts in producing this epistle.

References and resources
For anyone interested in pursuing the subject further, I’ve put a number of resources together which can be found listed in part two. These web addresses and textfiles may be of interest and additionally, there are some tables that will give an extended view of subnetting.

The majority of the information has been culled from the ‘Request for Comments’ (RFC) documents that are openly published on the Internet. The main RFCs are listed below, but they can be hard going in places. Searching for the particular RFC in Google will take you to the appropriate site. A StrongHelp file by Justin Fletcher that has a list of RFCs is available here.

If you feel a deeper knowledge is required, one document that’s really worth reading is the tome ‘Understanding IP Addressing: Everything you ever wanted to know’ by Chuck Semeria, also available on the Internet.

The major RFCs are listed below:


Links


Articles, comments? Originally published in Archive magazine, the subscription magazine for RISC OS users.

Previous: Audio software porting made easier
Next: Auto-built libraries from riscos.info

Discussion

Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

Some points

"Each packet sent over the Internet contains the subnet prefix in the destination field as well as the destination IP"

Hm not exactly, the destination IP is send which then is divided in a network and host part by the routers. Subnetting means the routers closer to the destination have a biger (more detailed) network part in their table for the same address.

In theory you can also use the network address as a host address, but as there were computers (a long time ago) which wrongly implemented the all zero host address as broadcast instead of the all one host address there is a posibility that you are not reachable for some computers if you have the network address.

Another good thing about IPv6 is that the header has a fixed format which makes it easyer to implement routing in hardware instead of software.

Not only routers but every computer with an ethernet interface needs to have a ARP table, all packets on a ethernet are routed on the MAC address. Hosts (including routers) will only receive a packet if it is for their MAC address, only after that they will check the destination IP address if it is at the final destination or if it needs to be routed further.

 is a RISC OS UserJaco on 14/9/04 7:21PM
[ Reply | Permalink | Report ]

A very good set of articles, I certainly know more now!

Well done, and thanks for the effort.

 is a RISC OS UserCJE on 16/9/04 11:43AM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

  • Star Fighter 3000 Review
    RISC OS gaming classic better than ever
     25 comments, latest by The Doctor on 9/1/04 8:54PM. Published: 5 Jan 2004

  • Random article

  • News in brief
    More to follow
     22 comments, latest by bstewart on 26/3/06 5:08PM. Published: 22 Mar 2006

  • Useful links

    News and media:
    IconbarMyRISCOSArcSiteRISCOScodeANSC.S.A.AnnounceArchiveQercusRiscWorldDrag'n'DropGAG-News

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    Dealers:
    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster

    Usergroups:
    WROCCRONENKACCIRUGSASAUGROUGOLRONWUGMUGWAUGGAGRISCOS.be

    Useful:
    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign


    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "Thanks for leaving out a significant part of my statement. Is that the standard of journalism we can expect from Drobe?"
    Page generated in 0.1603 seconds.