Difference between pages "PXE network boot server" and "IPv4 calculations"

From Funtoo
(Difference between pages)
Jump to: navigation, search
(Configuring PXELinux (based on syslinux))
 
(The Internet layer)
 
Line 1: Line 1:
== ''Howto: Turn your Funtoo machine into a Network Boot Server'' ==
+
WARNING: Work in progress. Do not edit this article unless you are the original author.
This guide helps explain how to set up a PXE server using in.tftpd and dnsmasq.
+
This may be useful for installing an operating system on a machine that has no optical drive and/or an older BIOS which doesn't support booting from USB.  
+
  
This guide will cover the basics of getting your server set up to allow clients to boot from the network to a pxelinux/syslinux menu and choose an option of installing / running your preferred distribution or installing a MS Windows operating system - the possibilities are endless and you are free to use it as you wish!! The funtoo way!
 
  
== Dependencies ==
+
= Refresh on TCP/IP model =  
The following packages are required:
+
  
* {{Package|net-dns/dnsmasq}}
+
When the ARPANet (a packet oriented network) was born in those good old seventies, engineers had to solve the problem of making computers being able to exchange packets of information over the network and they invented in 1974 something you are now using to view this page: TCP/IP! TCP/IP is a collection of various network protocols, being organized as a stack. Just like your boss does not do everything in the company and delegates at lower levels which in turn delegates at an even more lower level, no protocol in the TCP/IP suite takes all responsibilities, they are working together in a hierarchical and cooperative manner. A level of the TCP/IP stack knows what its immediate lower subordinate can do for it and whatever it will do will be done the right way and will not worry about the manner the job will be done. Also the only problem for a given level of the stack is to fulfill its own duties and deliver the service requested  by the upper layer, it does not have to worry about the ultimate goal of what upper levels do.
* {{Package|net-ftp/tftp-hpa}}
+
 
* {{Package|sys-boot/syslinux}}
+
<illustration goes here TCP/IP model>
For Windows PXE Booting:
+
* {{Package|net-fs/cifs-utils}}
+
* {{Package|net-fs/samba}}
+
*A simple fileserving protocol configured and working properly. Both FTP and HTTP work fine. You can use either one.
+
{{Note}} This guide will use System Rescue CD as an example of the PXE Boot Process.
+
* Download System Rescue CD[http://www.sysresccd.org]
+
{{Note}} The following packages are only required if you intend to install Microsoft Windows via Network Boot (NOT REQUIRED IN THIS HOWTO)
+
*NFS support - Kernel configuration : CONFIG_NFS_FS=y||m
+
  
== Understanding the PXE/Network Boot process ==
+
The above illustration sounds horribly familiar : yes, it is sounds like this good old OSI model. Indeed it is a tailored view of the original OSI model and it works the exact same way: so the data sent by an application A1 (residing on computer C1) to another application A2 (residing on computer C2) goes through C1's TCP/IP stack (from top to bottom), reach the C1's lower layers that will take the responsibility to move the bits from C1 to C2 over a physical link (electrical or lights pulses, radio waves...sorry no quantum mechanism yet) . C2's lower layers will receive the bits sent by C1 and pass  what has been received to the C2's TCP/IP stack (bottom to top) which will pass the data to A2. If C1 and C2 are not on the same network the process is a bit more complex because it involves relays (routers) but the global idea remains the same. Also there is no shortcuts in the process : both TCP/IP stacks are crossed in their whole, either from top to bottom for the sender or  bottom to top for the receiver. The transportation process in itself is also absolutely transparent from an application's point of view:  A1 knows it can rely on the TCP/IP stack to transmits some data to A2, ''how'' the data is transmitted is not its problem, A1 just assumes the data can be transmitted by some means. The TCP/IP stack is also loosely coupled to a particular network technology because its frontier is precisely the physical transportation of bits over a medium and so the physical network's technology,  just the same way A1 does not care about how the TCP/IP stack will move the data from one computer to another. The TCP/IP stack itself does not care about the details about how the bits are physically moved and thus it can work with any network technology no matter the technology is Ethernet, Token Ring or FDDI for example.  
A PXE Network boot isn't much different than a traditional boot from your hard drive, in fact you will probably find the boot loader to be very similar to what you are already familiar with! In a nut shell here is what happens: You set your BIOS / Boot options to boot from Network. The client will obtain an IP address from the PXE server (via DNSMasq), after the IP address is obtained it simply looks for the tftp daemon running on the server (tftp-hpa). The DHCP Server sends the PXE information to the NIC and it loads up a menu that you define in your pxelinux configuration (syslinux), or depending on your configuration it may go straight into the OS / Installation that you configure.
+
  
Sounds easy huh? For the most part it is very simple to set up. However if you plan to set up a MS Windows install via the network, it gets a bit more tricky, mainly due to MS not using a case sensitive file system, and requiring files to be located using drive letters and back slashes "\" instead of slashes "/"  What this requires is a remapping file. With a remapping file, tftp daemon will remap the characters, symbols, and/or drive letters to suit the needs. This is why I recommend tftp-hpa in this guide. 
+
= The Internet layer =
  
DNSMasq actually provides a tftp server if you want to use it, however I recommend the use of tftp-hpa as it allows remapping in the event you ever intend to boot a Windows environment over your network.  
+
The goal of this article being more focused on calculation of addresses used at the ''Internet layer'' so  let's forget the gory details of the TCP/IP stack works (you can find an extremely detailed discussion in [[How the TCP/IP stack works]]...  to be written...). From here, we assume you have a good general understanding of its functionalities and how a network transmission works. As you know the ''Internet'' layer is responsible to handle logical addressing issues of a TCP segment (or UDP datagram) that has either to be transmitted over the network to a remote computer or that has been received from the network from a remote computer. That layer is governed by a set of strict set rules called the ''Internet Protocol'' or ''IP'' originally specified by [RFC 791] in september 1981. What is pretty amazing with IP is that, although its original RFC has been amended by several others since 1981, its specification remains absolutely valid! If have a look at [RFC 791] you won't see "obsoleted". Sure IPv4 reached its limits in this first half the XXIst century but will remains in the IT landscape for probably several years to not say decades (you know, the COBOL language....). To finish on historical details, you might find interesting know that TCP/IP was not the original protocol suite used on the ARAPANet, it superseded in 1983 another protocol suite the [http://en.wikipedia.org/wiki/Network_Control_Program Network Control Program]. NCP looks like, from our point of view, quite prehistoric but it is of big importance as it established a lot of concepts still in use today : PDU, splitting an address in various components, connection management and so on comes from NCP. Historical reward  for those who are still reading this long paragraph: first, even a computer user was addressable in NCP messages second even in 1970 the engineers were concerned by network congestions issues ([http://www.cs.utexas.edu/users/chris/think/ARPANET/Timeline this page]).
  
This guide will cover the basics of getting your PXE server up and running for a linux based client, in this guide we will be using System Rescue CD (which is a Gentoo Live CD Image).
+
Let's go back to those good old seventies: the engineers who designed the Internet Protocol retained a 32 bits addressing scheme for IP and, afterall, the ARAPnet will never have the need to be able to address  billions of hosts! If you look at some ARAPANet diagrams it counted less than 100 hosts in
  
In the event that you want to install Microsoft Windows over the network, you will have your server already configured, and you will only need to do some minor config changes, host your Windows installation files / Preinstallation Environment and set your tftp remapping configuration. (This can become a headache if you plan to host several releases of MS Windows over the network - due to conflicting remappings)
+
who would ''ever'' need millions of addresses afterall?  So in theory with those 32 bits we can have around 4 billions of computers within that network and arbitrarily retain that the very first connected computer must be given the number "0", the second one "1", the third one "2" and so on until we exhaust the address pool at number 4294967295 giving no more than 4294967296 (2^32) computers on that network because no number can be a duplicate.
  
It is also very important to understand that the PXE network is only responsible for giving you network access up until the operating system is loaded. What this means is that your kernel you are loading will need to have support for the network card on your client(s). You may want to consider a generic kernel that supports several different NICs.  For Windows, this means you will probably want to include all NIC drivers in your installation files and ensure that they are loaded during installation.
+
= Classful and classless networks =
  
== Installing and Configuring tftp-hpa (in.tftpd) for serving your network boot files ==
+
Those addresses follows the thereafter logic:
Install the tftp server using portage:  
+
<console>
+
###i## emerge -av net-ftp/tftp-hpa
+
</console>
+
  
Create a directory for your tftp server - this is where your pxe configuration files and any files that will be accessed directly from the PXE boot process will be located (You can put it anywhere you have access to, I will be using /tftproot):
+
{| class="wikitable"
<console>
+
|-
###i## mkdir /tftproot
+
| colspan="2" | '''32 bits (fixed length)'''
</console>
+
|-
 +
| '''Network''' part (variable length of N bits ) || '''Host''' part (length : 32 - N bits)
 +
|}
  
Edit your PXE configuration:
+
* The network address : this part is uniquely assigned amongst all of the organizations in the world (i.e. No one in the world can hold the same network part) 
Set the path to /tftproot or your preferred directory created above. We are going to also go ahead and add a remapping file just in case you intend to use it later it will be ${INTFTPD_PATH}tftpd.remap:
+
* The host address :  unique within a given network part
<console>
+
###i## nano /etc/conf.d/in.tftpd
+
# Path to server files from
+
# Depending on your application you may have to change this.
+
# This is commented out to force you to look at the file!
+
#INTFTPD_PATH="/var/tftp/"
+
#INTFTPD_PATH="/tftpboot/"
+
INTFTPD_PATH="/tftproot/"
+
  
# For more options, see in.tftpd(8)
+
So in theory we can have something like this (remember the network nature is not to be unique, it hs to be be a collection of networks  :
# -R 4096:32767 solves problems with ARC firmware, and obsoletes
+
# the /proc/sys/net/ipv4/ip_local_port_range hack.
+
# -s causes $INTFTPD_PATH to be the root of the TFTP tree.
+
# -l is passed by the init script in addition to these options.
+
INTFTPD_OPTS="-m ${INTFTPD_PATH}tftpd.remap -R 4096:32767 -s ${INTFTPD_PATH}"
+
</console>
+
  
No need to worry about the the contents of the tftpd.remap file for now, but to prevent the daemon from panicking on a missing file, just create an empty one like so:
+
* Network 1 Host 1
 +
*
  
<console>
 
###i## touch /tftproot/tftpd.remap
 
</console>
 
  
== Installing and Configuring DNSMasq for DHCP / PXE Booting ==
+
Just like your birthday cake is divided in more or less smaller parts depending on how guests' appetite, the IPv4 address space has also been divided into more or less smaller parts just because organizations needs more or less computers on their networks. How to make this possible? Simply by dedicating a variable number of bits to the network part! Do you see the consequence? An IPv4 address being '''always''' 32 bits wide, the more bits you dedicate to the network part the lesser you have for the host part and vice-versa, this is a tradeoff, always. Basically, having more bits in :
Install {{Package|net-dns/dnsmasq}} if you don't already have it installed (use the tftp useflag):
+
* the network part : means more networks possible at the cost of having less hosts per network 
Even though we won't be using the built-in tftp server for dnsmasq, we will still need it to be tftp-aware:
+
* the host part : means less networks but more hosts per network
<console>
+
###i## echo "net-dns/dnsmasq tftp" >> /etc/portage/package.use/dnsmasq && emerge -av net-dns/dnsmasq
+
</console>
+
DNSMasq is a powerful daemon that has the capability of functioning as a DNS cacheing server, DHCP Server, TFTPD Server, and more. For now we will be focusing on one thing in the configuration, the DHCP Server.
+
  
The DNSMasq configuration file is located at: /etc/dnsmasq.conf and it is a very large file however there are only 3 options we need for this to work, you can later enable DNS and custom dhcp mappings if neededThose 3 configuration options are:
+
It might sounds a bit abstract but let's take an example : imagine we dedicate only 8 bits for the network part and the remaining 24 for the hosts part. What happens? First if we only
  
#dhcp-boot=pxelinux.0 #Tells the filename to grab from the tftp server for booting This is provided by the syslinux package we will be configuring in the next step
+
   
#dhcp-range=192.168.0.100,192.168.0.250,72h #customize this range to suite your network needs.
+
#interface=eth0 #The interface that will be acting as a DHCP server. If you want the DHCP server to run on a different interface be sure to change this option
+
  
== Configuring PXELinux (based on syslinux) ==
+
Is the network part assigned by each organization to itself? Of course not! Assignment are coordinated at the worldwide level by what we call Regional Internet Registries or RIRs which, in turn, can delegate assignments to third-parties located within their geographic jurisdiction. Those latter are called Local Internet Registries or LIRs (the system is detailed in RFC 7020). All of those RIRs are themselves put under the responsibility of now now well-known Internet Assigned Numbers Authority or [http://www.iana.org IANA]. As of 2014 five RIR exists :
Install {{Package|sys-boot/syslinux}}:
+
   
<console>
+
* ARIN (American Registry for Internet Numbers) : covers North America
###i## emerge -av sys-boot/syslinux
+
* LACNIC (Latin America and Caribbean Network Information Centre): covers South America and the Caribbean
</console>
+
* RIPE-NCC (Réseaux IP Européens / or RIPE Network Coordination Centre): covers Europe, Russia and middle east
 
+
* Afrinic (Africa Network Information Center) : covers the whole Africa
PXE booting only requires one file that is installed by syslinux, however we you will probably want to use more later on. For now we will use the pxelinux.0 file as we mentioned earlier while setting up DNSMasq, as well as a basic menu using the menu.c32 and a graphical menu using the vesamenu.c32.
+
* APNIC (Asian and Pacific Network Information Centre) : covers oceania and far east.
<console>
+
###i## cd /usr/share/syslinux
+
###i## cp menu.c32 vesamenu.c32 pxelinux.0 /tftproot
+
###i## cd /tftproot
+
</console>
+
 
+
PXELinux can boot a different option for each device's MAC address on your network, or it can also boot a default for all nic's on the network if a MAC address config isn't found. I will be covering the default method as it works for most simple setups. If you prefer a different boot configuration for each MAC address on your NICs then you can google for "pxelinux.cfg MAC config" and find tons of documentation for doing so. 
+
To set up the default config, first create the following directory:
+
<console>
+
###i## mkdir /tftproot/pxelinux.cfg
+
</console>
+
 
+
Inside this directory is where the "default" config as well as any other custom configurations by MAC will reside. Here is an example of a graphical menu used to boot System Rescue CD, the file should be located at ''<code>/tftproot/pxelinux.cfg/default</code>'':
+
<console>
+
###i## nano /tftproot/pxelinux.cfg/default
+
# The default menu style - using vesa menu in this example
+
DEFAULT vesamenu.c32
+
# If you have a png image in the /tftproot directory you can specify it here like so:
+
Menu Background netboot-1.png
+
# Prompt user for selection
+
prompt 0
+
 
+
#Global label identifier
+
label System Rescue CD
+
        # Set this entry as the default selection
+
        menu default
+
        # Actual viewable label text
+
MENU LABEL System Rescue CD
+
        # The timeout for the entry is a bit unclear, but 10000 is equivalent to 10 Seconds.
+
        TIMEOUT 10000
+
        TOTALTIMEOUT 10000
+
        # The kernel image to load.  This entry would actually reside at /tftproot/srcd/isolinux/rescue64  The path is relative to /tftproot or your tftp directory
+
kernel srcd/isolinux/rescue64
+
        # The initrd relative to tftproot directory and specifying the netboot server, protocol, and file
+
        # In this example the http protocol is used on server 192.168.0.1. The file is sysrcd.dat
+
        # If you have your http server set up to host files at /var/www/localhost/htdocs then this file would be located in that directory
+
append initrd=srcd/isolinux/initram.igz netboot=http://192.168.0.1/sysrcd.dat
+
</console>
+
 
+
== Mounting the ISO Image and Hosting the Compressed File System ==
+
In the above configuration example I was using a mounted System Rescue CD image at /tftproot/srcd  The kernel and initrd are located inside the isolinux directory of the ISO, the compressed filesystem is located at the top level of the ISO (i.e. /tftproot/srcd/sysrcd.dat)
+
 
+
In order to replicate the exact settings I used in this config you may do the following:
+
<pre>
+
cd /tftproot;mkdir srcd;mount -o loop /path/to/systemrescuecd.iso srcd/</pre> Be sure to replace the "/path/to/systemrescuecd.iso" with the actual path you downloaded the System Rescue CD to and the actual filename.
+
 
+
Now you need to be sure that 2 files reside on your HTTP or FTP server, whichever you prefer to use for the netboot process is fine, but the System Rescue CD Netboot process will do 3 things:
+
#Load Kernel
+
#Load Initrd
+
#Request the compressed filesystem from the network
+
The files needed for the 3rd step are located in the srcd/ directory if you mounted it with the above command. System Rescue CD uses a .dat file for the compressed filesystem, and it is verified during boot with a md5sum using the .md5 file in the srcd/ directory. The filenames are sysrcd.dat and sysrcd.md5.  They need to be hosted on your fileserver/http server that you specify for the netboot argument in the pxelinux.cfg/default file. If you have a basic Apache/Lighttpd server set up you can do the following:
+
<pre> ln -s /tftproot/srcd/sysrcd.dat /var/www/localhost/htdocs/;ln -s /tftproot/srcd/sysrcd.md5 /var/www/localhost/htdocs/</pre>
+
 
+
== Starting the services and preparing for use ==
+
First we want to start the PXE server:
+
<pre> /etc/init.d/in.tftpd start</pre>
+
And now DNSMasq:
+
<pre> /etc/init.d/dnsmasq start </pre>
+
If you are using Apache ensure it is running (If you use Lighttpd or Nginx replace this step with the appropriate service)  
+
<pre> /etc/init.d/apache2 status</pre> If service is running you should be good at this point, if not just start it:
+
<pre> /etc/init.d/apache2 start </pre>
+
If all your configuration options are correct and you have your HTTP/FTP server running and hosting the files properly, your configuration should be done on the server side for hosting ''System Rescue CD''!!  Don't get carried away just yet, we still have to test things are working :D
+
 
+
== Testing your first network boot ==
+
The first thing you want to do now is set up your client to boot from the network. This may vary on different machines / bios, common methods are:
+
*Pressing F12 at boot to select boot method
+
*Pressing F1, F10, or DEL at boot to enter BIOS Setup
+
*Consult your motherboard documentation for the appropriate method of selecting boot device if the above don't work
+
 
+
You will want to choose a method to boot from Network as the first boot device. It may also be called "Boot From Lan" "Network Boot" "PXE Boot"  Once you have selected the appropriate method you may need to save the settings, proceed on to booting.  If you chose the right method you should be seeing some text on your screen, such as:  PXE Boot.. Obtaining DHCP....  If all is well you will be presented with your PXELinux Boot menu.  If your client system is still booting from the hard drive, or you see a failure related to obtaining DHCP IP address, please verify your settings in the above section "Installing and Configuring DNSMasq for DHCP / PXE Booting"[http://www.funtoo.org/index.php?title=Installing_and_Configuring_DNSMasq_for_DHCP_/_PXE_Booting&action=submit#Installing_and_Configuring_DNSMasq_for_DHCP_.2F_PXE_Booting] -make sure that your interface is set correctly, and that you are offering a DHCP range on the same internal network range as the IP address your server hasIf you have any error relating to unable to find PXE boot, please verify that you have the pxelinux.0 file in your /tftproot  and that your /etc/dnsmasq.conf  has the ""dhcp-boot=pxelinux.0"" configuration option.. **note that the 0 is a zero and not an o.
+
 
+
Upon a successful PXE configuration you will be presented with the network boot menu, with the option to boot System Rescue CD.  If you have the appropriate files in the correct locations and your http/ftp server is working properly, you should be able to select the System Rescue CD menu entry and successfully boot via network. Congratulations!!
+
 
+
== Adding more operating systems / installations to your working PXE setup ==
+
I know that by example, a lot of people probably want to use something other than the System Rescue CD. The main things have been outlined above for most linux distributions. MS Windows, see [http://www.funtoo.org/wiki/PXE_Network_Windows_Installation PXE Network Windows Installation] is quiet a bit more difficult than any linux install. I will try to cover the most important steps to serving a Windows Installation from the network soon.
+
 
+
If you are wondering how you go about hosting a different Linux install other than the System Rescue CD, the main things to look at are the pxelinux.cfg/default file to edit the kernel and initrd lines. You also need to be sure that those files are accessible by the PXE loader, and if your initrd requires a compressed filesystem, be sure that you have a working ftp/http server hosting the compressed filesystem (Remember once boot process has been handed over to your kernel that you are no longer accessing the network via tftp but instead by the core services provided by the initrd + drivers provided by your kernel) I will add that you may use the fetch=tftp:// protocol in the kernel cmdline, however it doesn't seem to work as stable as using http/ftp method.  Each distro is different you may need to consult the documentation for the specific  distro's needed boot cmdline.  For the most part you will find it to be very similar(i.e. kernel+initrd+compressed-filesystem) Ubuntu doesn't even use a compressed filesystem on their ISO's it basically just uses a kernel and an initrd. I am currently working on getting a Funtoo netboot image developed, tested, and providing information on how to host a Funtoo Base system over the network via your Funtoo PXE Netboot Server.
+
[[Category:HOWTO]]
+

Revision as of 17:52, 16 January 2014

WARNING: Work in progress. Do not edit this article unless you are the original author.


Refresh on TCP/IP model

When the ARPANet (a packet oriented network) was born in those good old seventies, engineers had to solve the problem of making computers being able to exchange packets of information over the network and they invented in 1974 something you are now using to view this page: TCP/IP! TCP/IP is a collection of various network protocols, being organized as a stack. Just like your boss does not do everything in the company and delegates at lower levels which in turn delegates at an even more lower level, no protocol in the TCP/IP suite takes all responsibilities, they are working together in a hierarchical and cooperative manner. A level of the TCP/IP stack knows what its immediate lower subordinate can do for it and whatever it will do will be done the right way and will not worry about the manner the job will be done. Also the only problem for a given level of the stack is to fulfill its own duties and deliver the service requested by the upper layer, it does not have to worry about the ultimate goal of what upper levels do.

<illustration goes here TCP/IP model>

The above illustration sounds horribly familiar : yes, it is sounds like this good old OSI model. Indeed it is a tailored view of the original OSI model and it works the exact same way: so the data sent by an application A1 (residing on computer C1) to another application A2 (residing on computer C2) goes through C1's TCP/IP stack (from top to bottom), reach the C1's lower layers that will take the responsibility to move the bits from C1 to C2 over a physical link (electrical or lights pulses, radio waves...sorry no quantum mechanism yet) . C2's lower layers will receive the bits sent by C1 and pass what has been received to the C2's TCP/IP stack (bottom to top) which will pass the data to A2. If C1 and C2 are not on the same network the process is a bit more complex because it involves relays (routers) but the global idea remains the same. Also there is no shortcuts in the process : both TCP/IP stacks are crossed in their whole, either from top to bottom for the sender or bottom to top for the receiver. The transportation process in itself is also absolutely transparent from an application's point of view: A1 knows it can rely on the TCP/IP stack to transmits some data to A2, how the data is transmitted is not its problem, A1 just assumes the data can be transmitted by some means. The TCP/IP stack is also loosely coupled to a particular network technology because its frontier is precisely the physical transportation of bits over a medium and so the physical network's technology, just the same way A1 does not care about how the TCP/IP stack will move the data from one computer to another. The TCP/IP stack itself does not care about the details about how the bits are physically moved and thus it can work with any network technology no matter the technology is Ethernet, Token Ring or FDDI for example.

The Internet layer

The goal of this article being more focused on calculation of addresses used at the Internet layer so let's forget the gory details of the TCP/IP stack works (you can find an extremely detailed discussion in How the TCP/IP stack works... to be written...). From here, we assume you have a good general understanding of its functionalities and how a network transmission works. As you know the Internet layer is responsible to handle logical addressing issues of a TCP segment (or UDP datagram) that has either to be transmitted over the network to a remote computer or that has been received from the network from a remote computer. That layer is governed by a set of strict set rules called the Internet Protocol or IP originally specified by [RFC 791] in september 1981. What is pretty amazing with IP is that, although its original RFC has been amended by several others since 1981, its specification remains absolutely valid! If have a look at [RFC 791] you won't see "obsoleted". Sure IPv4 reached its limits in this first half the XXIst century but will remains in the IT landscape for probably several years to not say decades (you know, the COBOL language....). To finish on historical details, you might find interesting know that TCP/IP was not the original protocol suite used on the ARAPANet, it superseded in 1983 another protocol suite the Network Control Program. NCP looks like, from our point of view, quite prehistoric but it is of big importance as it established a lot of concepts still in use today : PDU, splitting an address in various components, connection management and so on comes from NCP. Historical reward for those who are still reading this long paragraph: first, even a computer user was addressable in NCP messages second even in 1970 the engineers were concerned by network congestions issues (this page).

Let's go back to those good old seventies: the engineers who designed the Internet Protocol retained a 32 bits addressing scheme for IP and, afterall, the ARAPnet will never have the need to be able to address billions of hosts! If you look at some ARAPANet diagrams it counted less than 100 hosts in

who would ever need millions of addresses afterall? So in theory with those 32 bits we can have around 4 billions of computers within that network and arbitrarily retain that the very first connected computer must be given the number "0", the second one "1", the third one "2" and so on until we exhaust the address pool at number 4294967295 giving no more than 4294967296 (2^32) computers on that network because no number can be a duplicate.

Classful and classless networks

Those addresses follows the thereafter logic:

32 bits (fixed length)
Network part (variable length of N bits ) Host part (length : 32 - N bits)
  • The network address : this part is uniquely assigned amongst all of the organizations in the world (i.e. No one in the world can hold the same network part)
  • The host address : unique within a given network part

So in theory we can have something like this (remember the network nature is not to be unique, it hs to be be a collection of networks  :

  • Network 1 Host 1


Just like your birthday cake is divided in more or less smaller parts depending on how guests' appetite, the IPv4 address space has also been divided into more or less smaller parts just because organizations needs more or less computers on their networks. How to make this possible? Simply by dedicating a variable number of bits to the network part! Do you see the consequence? An IPv4 address being always 32 bits wide, the more bits you dedicate to the network part the lesser you have for the host part and vice-versa, this is a tradeoff, always. Basically, having more bits in :

  • the network part : means more networks possible at the cost of having less hosts per network
  • the host part : means less networks but more hosts per network

It might sounds a bit abstract but let's take an example : imagine we dedicate only 8 bits for the network part and the remaining 24 for the hosts part. What happens? First if we only


Is the network part assigned by each organization to itself? Of course not! Assignment are coordinated at the worldwide level by what we call Regional Internet Registries or RIRs which, in turn, can delegate assignments to third-parties located within their geographic jurisdiction. Those latter are called Local Internet Registries or LIRs (the system is detailed in RFC 7020). All of those RIRs are themselves put under the responsibility of now now well-known Internet Assigned Numbers Authority or IANA. As of 2014 five RIR exists :

  • ARIN (American Registry for Internet Numbers) : covers North America
  • LACNIC (Latin America and Caribbean Network Information Centre): covers South America and the Caribbean
  • RIPE-NCC (Réseaux IP Européens / or RIPE Network Coordination Centre): covers Europe, Russia and middle east
  • Afrinic (Africa Network Information Center) : covers the whole Africa
  • APNIC (Asian and Pacific Network Information Centre) : covers oceania and far east.