mail this page
products | company | support | training | contact us
<warning> To understand this stuff you need to be be comfortable with decimal, hexadecimal and binary notation. If you don't like this stuff stick to origami or try this memory jogger - Binary, Decimal and Hexadecimal</warning>
Most of this note is concerned with IP addresses used in version 4 of the IP protocol which uses a 32 bit IP address, such as, 192.168.0.15. This type of address is almost universally written as IPv4. See also IPv4 headers, TCP, UDP and IPv4 ICMP messages for the insatiably curious.
IPv4 is being progessively replaced with IPv6 (version 6 of the IP protocol) which uses a 128 bit address and greatly extends the address range of the Internet. While the immediate pressure for new IP addresses was greatly reduced in the mid-late 90s by CIDR, NAT and other initiatives, the increasingly dire warnings from the Regional Internet Registries (RIRs) of IPv4 address depletion are placing renewed emphasis on IPv6 deployment. Indeed, it is no exaggeration to say that a rising tide of panic is being fostered in an effort to increase the pace of IPv6 migration. Further, the adoption of IPv6 by the wireless world is probably the only way to supply the staggering number of mobile devices the world seems capable of consuming.
Bit numbering can be very confusing with various standard bodies adopting different conventions. The following are all valid, and used, bit numbering conventions for describing an 8 bit byte (an octet).
|Bit numbering conventions|
|Left to right base 0 (IETF)||0||1||2||3||4||5||6||7|
|Left to right base 1||1||2||3||4||5||6||7||8|
|Right to left base 1 (ITU)||8||7||6||5||4||3||2||1|
|Power of 2||7||6||5||4||3||2||1||0|
Always check what convention is used on any specification. We have bowed to the inevitable and this document uses the Left to right base 0 (IETF) standard since, because of the Internet, it is widely used and, hopefully, equally widely understood. The IETF's rationale for this standard is that it also represents unambiguously what is called network order, that is, bit 0 goes onto a network first, bit 1 second and so on. Bits also tend to come off the network in the same order they went on. Use of network order is necessary since the internal (machine) representation of data can vary enormously (all that big-endian, little-endian nonsense) but when data is stuffed onto a network it must be in a consistent order that can be used by any system, irrespective of its internal representation, that wants to use the data. Our own preference is for Power of 2 notation - but that's another story...
An IP v4 address is a 32 bit value which allows 4,294,967,296 unique addresses. It's a bit tough to remember numbers of this size so the conventional way of writing an IP address is in "dotted decimal" format, for example, 192.168.0.27.
A "dotted decimal" IP address is constructed as follows:
A 32 bit address contains 4 x 8 bit bytes (or octets)
Each 8 bit byte (octet) may represent 256 ( 0 - 255) decimal values. [The internal (machine) representation of the byte (octet) uses 'hexadecimal' notation and may contain the hexadecimal values 00 to FF.]
"dotted decimal" simply converts the 8 bit value for each byte (octet) to its decimal value (which is always in the range 0 to 255) and separates each value with a dot to make it more readable resulting in, for example, 192.168.2.5.
Each IP address has two components a network address and a host address (or id).
|Network address||Host address|
The boundary between the Network address part and the Host Address part was determined by the IP Address class and the NetMask or the SubnetMask. In a CIDR world it is determined exclusively by the NetMask.
You will occasionally see IPv4 addresses written like this:
The : (colon) indicates the number following is a Port Number - in the above case 369. This format is typically only used where a service is available on a non-standard port number, for instance, many web configuration systems, such as Samba swat, will use a non-standard port to avoid clashing with the standard web (HTTP) port number of 80. A port number is 16 bits giving a decimal range of 0 to 65535. In most systems privileged or well-known ports lie in the range 0 - 1023 and require special access rights, normal user ports lie in the range 1024 to 65535.
Before the advent of Classless Inter-Domain Routing (CIDR) the world was a complex place and we had four classes of IPv4 addresses: A, B, C and D (there is nominally a class E but for all practical purposes it was not used). The IP address Class is defined by the setting of the TOP 4 bits of the IP address (bits 0 -3 in the IETF notation). The IP Class provides the separation between the host and the network part of the IP address as defined below:
|Class||Example||Bits 0 - 3||Network Bits||Host Bits||Netmask|
x = don't care
Class D addresses are used for Multi-casting protocols exclusively, for example, OSPF, IGMP etc.
Class A, B and C are routed IPs (but may be PUBLIC or PRIVATE - see NAT)
The term Netmask above refers to the standard mask for the address class. We will see later that with CIDR different netmasks may be used with any IP Class.
Historically the term Netmask was used to describe any mask that extracted on a Class boundary and Subnetmask described a netmask that extracted less than a Class boundary. Since the advent of CIDR the term subnetmask is rarely used. A Netmask simply refers to a way of separating the Network Address and the Host Address parts of the IP address. It consists of the number of contiguous bits reflecting the size of the Network part of the address and was typically written in normal dotted-decimal notation, for example, 255.255.255.0 (but may now be more commonly written using the slash - or IP-Prefix - notation) and is used in Routing Tables with Bitwise AND operations.
The process of routing an IP address in the internet uses routing tables defined in each host (PC, Router or other device). A standard routing table will look something like this:
|Network address||Netmask||metric||next hop||Notes|
|192.168.0.0||255.255.255.0||1||192.168.0.0||Local network - send using ARP table|
A routing process using the above table is deceptively simple and may be expressed as follows:
BITWISE AND the destination IP address with the Netmask.
Compare result with current Network Address, if it MATCHES the Network Address and MATCHES the Next Hop address the address lies on the local network - route direct to destination IP using, say, ARP (Address Resolution Protocol).
If it MATCHES the Network Address but does NOT MATCH the Next Hop address - route to Next Hop using, say, ARP, In the above table only two entries satisfy this last test 127.0.0.1 the loopback address which is known to all systems and the default gateway.
If result does NOT MATCH move to next routing table entry and repeat from step 1.
The term BITWISE AND simply means ANDing of two values to create a third (result), 'bitwise' indicates this is done at the bit level. The following illustrates bitwise ANDing using the first entry in our routing table above.
Example 1: destination IP 192.168.0.3 is local (we bitwise AND the destination IP address and the entry NetMask and compare it with the Network Address):
|192.168.0.0||1100.0000.1010.1000.0000.0000.0000.0000||Result: 1 in every position where there is 1 in Target AND netmask. MATCHES our Network address and MATCHES the NEXT HOP address so must be local (we typically would use ARP or some other local protocol to send the data).|
Example 2 destination IP 172.16.5.13 is NOT local:
|172.16.4.0||1010.1100.0001.0000.0000.0100.0000.0000||Result: 1 in every position where there is 1 in Target AND netmask. Does NOT match our local network address. We try again with the next routing table entry.|
If you run the same calculations against the default gateway entry you will ALWAYS get a match. Any IP Address when ANDed with 0.0.0.0 will always result in 0.0.0.0 and will thus MATCH the default gateway network address but will not MATCH the next hop address so we send it (again typically using ARP) to that address. The gateway then uses its routing table to figure out what to do next, and so on until the packet reaches its destination.
Subnets are simply an administrative convenience and provide a method of splitting the host part of the address into smaller pieces by changing the value of the Class Netmask. When this is done the Netmask is usually called a Subnetmask. In general we have two rules for Net/Subnetmasks:
Examples of Subnetmasks (extracts less than the Class boundary - has more contiguous bits that the Class boundary netmask) include:
|Class||Netmask||No. of IPs|
To create a subnet of 32 addresses starting at 192.168.0.192 we would create a routing table entry of network address = 188.8.131.52 with a netmask of 255.255.255.224.
Every subnet loses two IP address for multi-casting and broadcasting. This is why the subnetmasks 255.255.255.254 and 255.255.255.255 are missing from the above table.
Net/subnetmasks today are more commonly written using the slash - IP-Prefix - notation such as 192.168.2.0/8. This notation, which combines the network address and net/subnetmask into a single entity.
Every network created by a Net/Subnetmask is defined by the standards to have two special (unuseable by normal hosts or PCs) IP addresses as follows:
The following table illustrates this:
|Network Address||Netmask||No. of IPs||Multi-cast IP||Broadcast IP|
Just to make things more interesting, there is a difference between the multi-cast address for the subnet and so-called multicasting Protocols which use an IPv4 Class D format address.
There are times when it useful to be able to find all hosts which have certain properties without knowing the IP address(es). This process typically uses a process that is confusing called multicasting and hosts use specially assigned IPv4 Class D addresses - each IPv4 Class D address is assigned by IANA to a protocol or class of devices. Thus is is possible for a host to send the address 184.108.40.206 and receive a response from those hosts which have the required properties (or are members of the same class) - in this case they support the RIP2 routing protocol. The following are examples of Multicast addresses and their associated protocol or characteristics:
|220.127.116.11||All routers of this subnet|
|18.104.22.168||All routers that support the OSPF protocol|
|22.214.171.124||All hosts that support the IGMP protocol|
|126.96.36.199 - 188.8.131.52||Microsoft and MSNBC - multicast transmissions|
Addresses in the range 184.108.40.206 - 220.127.116.11 are all multicast addresses.
In the above example Microsoft/MSNBC could use any of their Multicast addresses to create a specific conference (or transmission) using multicasting techniques and even run multiple concurrent conferences using any/all of the 64 addresses allocated to them.
As part of the moves to free up and maximise utilisation of the available stock of IPv4 addresses in the mid-late '90s the IETF took a number of steps of which the most significant were:
Classless Inter-Domain Routing (CIDR) which essentially removed the IP address Class boundaries.
Allocation of Private Addresses that could be reused many times over.
Network Address Translation (NAT) - allowing conversion from Private to Public when passing through a NAT gateway.
Classless Inter-Domain routing (CIDR) essentially removes the idea of Class from IP addresses and allows administrations to allocate and route any valid subnet from any convenient base IP irrespective of its Class. The idea being that if you want a group of 128 IP addresses, whether you take them from a Class C or from a Class B range is not important. You simply want 128 IP addresses. Equally, if you want 512 IPv4 addresses, whether they are taken from a Class B range or are two Class C ranges is again unimportant. The table below shows two 32 address subnets, one from a nominal Class B range the other from a nominal Class C range - spot the difference!
In short the key factors in a CIDR world become the Network (base) IP address and the Netmask.
To simplify writing IP addresses used in routing or filtering systems it has now become common practice to define a list of IP addresses using a slash (more properly IP Prefix) notation. The IP address to the LEFT of the SLASH (/) is the Network (base) IP address and the number (1 to 32) to the RIGHT of the SLASH (/) is the NUMBER OF CONTIGUOUS 1 BITS IN THE NETMASK. Thus, 192.168.2.0/24 will have an associated net/subnetmask containing 24 contiguous bits or 255.255.255.0 in dotted decimal format. The following table illustrates this notation:
|Slash Form||Network Base IP||Netmask||No. of IPs|
In the above examples - if you are not asleep - you will see that we have extracted multiple Class C addresses from a Class C IP address (line 1) and subnetted sub-class C addresses from a Class B address (line 3) just to illustrate how flexible CIDR has allowed us to become.
Software that interprets (or parses) IP addresses is usually very flexible in allowing specification of the number of dotted elements of the IPv4 address as shown in lines 1, 3 and 5. Essentially, only the minimum number of dotted elements necessary to unambigously define the IPv4 Network Base is required. All missing elements are replaced with zero before the slash value (netmask) is applied to create the Network Base IP. In the case of line 4, all 4 dotted elements must be present. If 172.28.127/28 was used the Network Base IP would be 172.28.127.0 - not the required result. In general, the rule is that if the slash value is a multiple of 8 you need only provide that number of dotted elements, if it is NOT a multiple of 8 you must supply one more. Thus, if the slash value is 16 (16/8 = 2 Remainder 0), then only two dotted elements are required. If the slash value is 25 (25/8 = 3 Remainder 1), then 4 dotted elements are required. <grovel> We incorrectly showed 23 in this calculation (and on line 4 of the table) not the correct value of 25 in spite of the fact the calculation of 3 remainder 1 was correct for the value of 25 but not 23. While 3 and 5 may look similar on small screens there was no excuse. Bigger screens and eye-tests are in order. Apologies. Thanks to Luca Saggese for taking the time to point out this egregious error.</grovel>
The IP address used on the left-hand side can be any IP that will be within the final Network. The Network Base IP is computed by BITWISE ANDing the left-hand IP with the netmask derived fom the slash value.
Line 6 is a rare, but acceptable, format to show a single address - it is more commonly simply written as 10.0.2.2.
The IETF has defined a series of IP ranges which may be freely used by any user/organization on their Private network. These addresses may not be used on the Public internet and all Public Internet gateways (routers) should silently discard the traffic (or, unusually, reject them with an ICMP message).
Clearly on large user networks Private IP addresses may well pass through routers while still inside a Private network.
The use of Private address means that the same IP addresses may be reused by many organisations (saving millions of IPv4 addresses) and only when the traffic is sent to the PUBLIC network must it be translated (via NAT) to a Public address.
Freely useable Private (not Public routable) Addresses
|Class||Start||End||Slash (IP Prefix)|
Which range you use is entirely up to you. Go on, spoil yourself (and be like Apple), have a whole class A address to yourself! In the case of home networks attached to a DSL or cable modem, it is normal to see a Class C range of 192.168.1/24 or 192.168.2/24. However, this is just a convention and any suitable range may be used. The full list of reserved and allocated IP address ranges are defined in RFC 1918 and RFC 3330 (you can get RFCs from the IETF).
Network Address Translation (NAT) refers to the process by which a Private IP address (which may be freely used and routed in a user's Private network) may be mapped (or translated) to a Public IP addresses which can be routed across the Public Internet.
The NAT process is usually located in a Router or Proxy function at the edge of the network such as a DSL or cable modem. The original NAT RFC (RFC 1631) is a deceptively small specification which revolutionized the way IP addresses are used. NAT can map (or translate) an unlimited number of Private IP addresses to a single Public IP address if required, or a limited number of Public IPs can be used to map a large number of Private IP addresses.
A well written NAT system also acts as a 'poor mans' firewall since it has the additional advantage that Internal IP addresses are not visible from outside the organisation and even if they were Internet routers should discard packets addresses to Private IP addresses. NAT is generally a 'good thing'™ for the traditional client server style applications of the Internet such as web access, FTP and email.
Note: As the Internet moves more to peer-to-peer applications, such as IM and VoIP, which require permanent visibility of a directly addressable IP that is stable for a reasonable period of time, NAT is becoming increasingly contentious. It is fair to say there is serious gulf between those that see NAT as having saved the Internet by providing re-use of the limited IPv4 address space and those who see it as inherently evil because it hides the end user, forcing all kinds of gruesome kludges such as STUN.
The term PAT (Port Address Translation) is used in conjunction with NAT. It refers to the process by which a NAT service can map a port number to a specific Private IP address. This allows a single Public IP address to support a range of Public services (Web, email, FTP etc.) on internal (Private IP) hosts. Example:
|External IP:Port||Service||Translated IP||Notes|
|192.168.2.0:80||HTTP (Web)||172.16.1.1||Web server|
|192.168.2.0:?||Any other port||Normal NAT||Normal NAT translation rules applied|
Note: The External IP:Port shown above uses a Private address purely for illustration of the process involved and to avoid using an allocated Public IP address - the principle remains true.
IP addresses may be either statically allocated or dynamically allocated by a service provider. A dynamic IP address has the following characteristics:
A single IP address is allocated when the user connects to the internet.
The service provider will normally change the IP address periodically - between every 12 and 24 hours is typical, significantly longer periods are increasingly common.
Dynamic IP addresses can be used for outgoing (client-server) activities such as Web browsing, collecting email and similar activities.
Dynamic IP addresses cannot be used (well there are 'kludges' that allow this) to host Web sites and email services that require a fixed IP defined in a DNS.
Static (Fixed) IP address(es) have the following characteristics:
One or more fixed IP address(es) are permanently assigned to a user (and will normally incur a cost).
Static IP addresses do not change (unless you change your service provider).
Static IP addresses can be used for outgoing (client-server) activities such as Web browsing, collecting email and similar activities.
Static IP addresses can be used to host Web sites and email services that require a fixed IP defined in a DNS.
A limited number of static address can be used in conjunction with NAT to map many PRIVATE to PUBLIC addresses.
There is a longer explanation.
Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.
Dec > Hex > Bin
data rate stuff
If you are happy it's OK - but your browser is giving a less than optimal experience on our site. You could, at no charge, upgrade to a W3C STANDARDS COMPLIANT browser such as Mozilla