Difference between pages "Zope HOWTO" and "IPv4 calculations"

From Funtoo
(Difference between pages)
Jump to: navigation, search
(First Steps)
 
 
Line 1: Line 1:
This page documents how to use Zope with Funtoo Experimental, which currently has good Zope support thanks to [[Progress Overlay Python]] integration.
+
WARNING: Work in progress. Do not edit this article unless you are the original author.
  
== About Zope ==
 
  
Zope is an Open Source application server framework written in Python. It has an interesting history which you should familiarize yourself with before starting Zope development, as it contains several interesting twists and turns.
+
= Refresh on TCP/IP model =
  
=== Zope History ===
+
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>
  
{{Note}} This HOWTO targets Zope 2.13, which includes Five. It is typically the version you should be using for new Zope projects.
+
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.  
  
* There are two versions of Zope, Zope 2 and Zope 3. One might assume that Zope 3 is the version that people should use for new software development projects by default, but this is not the case. Most Zope-based projects continue to use Zope 2. Zope 3 was an attempt to redesign Zope 2 from scratch, and is completely different from Zope 2, but it was not adopted by the community.
+
= The Internet layer and the IP protocol =
  
* There is also something called [http://codespeak.net/z3/five/ Five] (named because it is "2 + 3") that backports many of the new features of Zope 3 into the Zope 2 framework. Several projects will use Zope 2 plus Five in order to use some of the newer features in Zope. Five was merged into mainline Zope 2 in early 2010, and first appeared in Zope 2.8.
+
The goal of this article being more focused on calculation of addresses used at the ''Internet layer'' so  let's forget the gory details about the TCP/IP stack (you can find an extremely detailed discussion in [[How the TCP/IP stack works]]...  still 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] or NCP. NCP looks like, from our point of view, prehistoric however it is of big importance as it established a lot of concepts still in use today : protocol data units, splitting an address in various components, connection management concept (TCP) and so on comes from NCP. Historical reward  for those who are still reading this long paragraph: first, even a 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]) :-)
  
* You can learn more about the history of Zope 2, 3 and Five in the [http://svn.zope.org/Zope/trunk/src/Products/Five/README.txt?view=markup Five README].
+
Enough of historical background, packet networks history is super interesting but would make this article would just too long. So let's go back to the Internet Protocol! In those good old seventies the engineers who designed the Internet Protocol retained a 32 bits addressing scheme. Why 32 bits and not 64 or 128? In that decade, computers were rare with very limited resources and everyone at that time found that using 32 bits to express the a computer's address on the network would be way far more than enough : 2^32 gives 4,294,967,296 or roughly 4.3 billions (even some briliant visionaries like  [http://en.wikipedia.org/wiki/J._C._R._Licklider J.C.Lickleider] would probably never have imagined the growth and popularity of computer networks at that time).
  
* To make things even more interesting, work on [http://docs.zope.org/zope2/releases/4.0/ Zope 4] is underway, and it will be based on 2.13 rather than 3.x. It includes a number of [http://docs.zope.org/zope2/releases/4.0/CHANGES.html#restructuring incompatible changes] with prior versions.
+
== A story of cake ==
=== Zope Resources ===
+
  
Now that you understand what version of Zope you should be targeting (2.13), we can point you towards the correct documentation :)
+
From the beginning, engineers were aware that, also their address pool was ''a priori'' gigantic, it had to be used wisely and address pool exhaution issues had always been in the landscape: between 1977 and 1984, the number of interconnected hosts grew from roughly a hundred to more than a ''thousand'' and it was clear that this would not reach any limit. Indeed even at this time the problem was more ''when'' the pool will be depleted rather than ''if'' it would become depleted. Seen from those good old eighties, the IPv4 pool depletion was not an immediate problem especially altough the issued started be be a bit more critical a decade later (IETF [https://www.arin.net/knowledge/v4_deplete_v6_adopt.pdf forecasted] an IPv4 depletion between 2010 and 2017 in 1993).
 +
Just like you divide your birthday cake in slices of various sizes depending on your guests' appetite to minimize the waste, the engineers choose to divide the initial IPv4 pool in several slices of various size. Each one of those latter were then exclusively attributed to a given organization who wanted to connect to the ARPAnet by the Government of the United States (ICANN/IANA and Regional Internet Registries came much later at the end of nineties). Okay the ARPAnet became defunct with the split of MILNET in 1984 giving NSFNet later replaced with the Internet as we still know today but the principle of exclusively attributing IPv4 blocks remained the same.
  
; '''[http://docs.zope.org/zope2/zope2book/ The Zope 2 Book]'''
+
=== Classeful networks ===
: This book provides a general introduction to Zope concepts and ZMI. It is a good place to start, but doesn't provide a direct introduction to Zope development. It's recommended that you skim through this book to familiarize yourself with Zope. It generally does not assume much prior knowledge about Web development or Python.
+
; '''[http://docs.zope.org/zope2/zdgbook/ Zope Developer's Guide]'''
+
: This guide will give you a better introduction to Zope development. It assumes you already know Python. Skip chapters 1 and 2 and start in [http://docs.zope.org/zope2/zdgbook/ComponentsAndInterfaces.html chapter 3], which covers components and interfaces. [http://docs.zope.org/zope2/zdgbook/Products.html Chapter 5] covers the creation of your first product.
+
; '''[http://codespeak.net/z3/five/manual.html The Five Manual]'''
+
: We're not done yet. There is a bunch of stuff in Zope 2.13 that is not in the official documentation. Namely, the stuff in Five.
+
; '''[http://docs.zope.org/ztkpackages.html ZTK Documentation]'''
+
: ZTK 
+
; '''ZCA'''
+
: [http://www.muthukadan.net/docs/zca.html A Comprehensive Guide to Zope Component Architecture] offers a good introduction to the programming concepts of ZCA. We also have a new page on [[Zope Component Architecture]] which will help you to understand the big picture of ZCA and why it is useful. ZCML ("Z-camel") is a part of ZCA and  was introduced in Zope 3, so typically you will find ZCML documented within Zope 3 documentation and book.
+
; '''Content Components'''
+
: Views and Viewlets: [http://docs.zope.org/zope.viewlet/index.html This tutorial on viewlets] also contains some viewlet-related ZCML examples near the end. The "Content Component way" of developing in Zope seems to be a Zope 3 thing and tied to ZCML. Chapter 13+ of Stephan Richter's ''Zope 3 Developer's Handbook'' (book) seems to cover this quite well. You will probably also want to check out Philipp Weitershausen's ''Web Component Development with Zope 3'' (book).
+
; '''[http://wiki.zope.org/zope2/Zope2Wiki Zope 2 Wiki]'''
+
: Main wiki page for all things related to Zope 2.
+
; '''[http://docs.zope.org docs.zope.org]'''
+
: This is the main site for Zope documentation.
+
  
== First Steps ==
+
To shovel the IPv4 pool depletion problem as much as possible in the future, engineers choose to divide the initial IPv4 pool as a set of various sized blocks each one of those then being exclusively allocated to a given organization depending on her networking needs,. In
  
First, you will need to emerge {{Package|net-zope/zope}}:
 
<console>
 
###i## emerge -av zope
 
</console>
 
  
Zope is now installed.
 
  
== Project Skeleton ==
 
  
{{Note}} Zope should be run by a regular user account, not as the root user.
 
  
The first step in using Zope is to ensure that you are using a regular user account. Create a new directory called ''<tt>zope_test</tt>'':
 
<console>
 
$##bl## cd
 
$##bl## mkdir zope_test
 
</console>
 
  
Now, enter the directory, and create an "instance", which is a set of files and directories that are used to contain a Zope project:
 
<console>
 
$##bl## cd zope_test
 
$##bl## /usr/lib/zope-2.13/bin/mkzopeinstance
 
</console>
 
  
You will see the following output, and will be prompted to answer a few questions:
 
<console>
 
Please choose a directory in which you'd like to install
 
Zope "instance home" files such as database files, configuration
 
files, etc.
 
  
Directory: instance
 
Please choose a username and password for the initial user.
 
These will be the credentials you use to initially manage
 
your new Zope instance.
 
  
Username: admin
+
): RFC 790 introduced in 1981 mentions the notion of ''network classes''. Just because you guests at a party have different appetites so you split a cake in more or less big slices, organizations have various needs so the initial IPv4 address pool has to be divided in a set of more or less big "slices". Depending of their size, those "slices" are said to belong to a ''class'' hence the terminology of ''classeful networks''.  Each organization wanting to connect the ARPAnet had to request the exclusive attribution of an exclusive address block of the IPv4 pool to the Government of the United States (ICANN/IANA and Regional Internet Registries came at the end of nineties), no matter of how it will be used or not internally.
Password: ****
+
Verify password: ****
+
</console>
+
  
Now, we will start our Zope instance:
+
= Classful and classless networks =
<console>
+
$##bl## cd instance
+
$##bl## bin/runzope
+
</console>
+
  
Now that Zope is running, you can visit ''<tt>localhost:8080</tt>'' in your Web browser. You will see a nice introductory page to Zope.
+
Those addresses follows the thereafter logic:
  
If you now go to the ''<tt>localhost:8080/manage</tt>'' URL, you will be prompted to log in. Enter the username and password you specified. You are now logged in to the ZMI (Zope Management Interface.)
+
{| class="wikitable"
 +
|-
 +
| colspan="2" | '''32 bits (fixed length)'''
 +
|-
 +
| '''Network''' part (variable length of N bits ) || '''Host''' part (length : 32 - N bits)
 +
|}
  
You can stop your application by pressing Control-C. In the future, you can start and stop your Zope instance using the following commands:
+
* 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
  
<console>
+
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  :
$##bl## zopectl start
+
$##bl## zopectl stop
+
</console>
+
  
{{Note}} ''<tt>zopectl start</tt>'' will cause your instance to run in the background rather than consuming a shell console.
+
* Network 1 Host 1
 +
*
  
== First Project ==
 
  
We will create a single very primitive Zope package, consisting of an Interface for a TODO class, and a TODO class.
+
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
  
Create the following files and directories relative to your project root:
+
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
  
* Create the directory <tt>lib/python/example</tt>.
+
* Create the file <tt>lib/python/example/__init__.py</tt> by typing <tt>touch lib/python/example/__init__.py</tt>.
+
* Create these files:
+
  
=== <tt>example-configure.zcml</tt> ===
+
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 :
 
+
This file registers the <tt>example</tt> directory you created in <tt>lib/python</tt> as a ''package'', so that it is seen by Zope. Edit <code>/etc/package-includes/example-configure.zcml</code>:
+
* ARIN (American Registry for Internet Numbers) : covers North America
<pre>
+
* LACNIC (Latin America and Caribbean Network Information Centre): covers South America and the Caribbean
<include package="example" />
+
* RIPE-NCC (Réseaux IP Européens / or RIPE Network Coordination Centre): covers Europe, Russia and middle east
</pre>
+
* Afrinic (Africa Network Information Center) : covers the whole Africa
 
+
* APNIC (Asian and Pacific Network Information Centre) : covers oceania and far east.
=== <tt>interfaces.py</tt> ===
+
 
+
The following file defines the <tt>ITODO</tt> interface, and also uses some Zope Schema functions to define what kind of data we expect to store in objects that implement <tt>ITODO</tt>. Edit <code>/lib/python/example/interfaces.py</code> with your favorite text editor:
+
 
+
<pre>
+
from zope.interface import Interface
+
from zope.schema import List, Text, TextLine, Int
+
 
+
class ITODO(Interface):
+
    name = TextLine(title=u'Name', required=True)
+
    todo = List(title=u"TODO Items", required=True, value_type=TextLine(title=u'TODO'))
+
    daysleft = Int(title=u'Days left to complete', required=True)
+
    description = Text(title=u'Description', required=True)
+
</pre>
+
 
+
=== <tt>TODO.py</tt> ===
+
 
+
Now, we define <tt>TODO</tt> to be a ''persistent'' object, meaning it can be stored in the ZODB. We specify that it implements our previously-defined <tt>ITODO</tt> interface, and provide reasonable defaults for all values when we create a new TODO object. Edit <code>/lib/python/example/TODO.py<code> using your favorite text editor:
+
<pre>
+
from persistent import Persistent
+
from zope.interface import implements
+
from example.interfaces import ITODO
+
 
+
class TODO(Persistent):
+
    implements(ITODO)
+
    name = u''
+
    todo = []
+
    daysleft = 0
+
    description = u''
+
</pre>
+
 
+
=== <tt>configure.zcml</tt> ===
+
 
+
Create the <tt>/lib/python/example/configure.zcml</tt> configuration file:
+
<pre>
+
<configure xmlns="http://namespaces.zope.org/zope"
+
    xmlns:five="http://namespaces.zope.org/five"
+
    xmlns:browser="http://namespaces.zope.org/browser">
+
</configure>
+
</pre>
+
 
+
== Debug Mode ==
+
 
+
We can test our first project by entering debug mode:
+
<console>
+
$##bl## bin/zopectl debug
+
Starting debugger (the name "app" is bound to the top-level Zope object)
+
</console>
+
 
+
Now, let's try creating a new TODO object and writing it out to a ZODB database:
+
<console>
+
>>> from ZODB import FileStorage, DB
+
>>> storage = FileStorage.FileStorage('mydatabase.fs')
+
>>> db = DB(storage)
+
>>> connection = db.open()
+
>>> import transaction
+
>>> root = connection.root()
+
>>> from example.TODO import TODO
+
>>> a = TODO
+
>>> a.name = u'My TODOs'
+
>>> a.TODOS = [ u'Do Laundry', u'Wash Dishes' ]
+
>>> a.daysleft = 1
+
>>> a.description = u'Things I need to do today.'
+
>>> root[u'today'] = a
+
>>> transaction.commit()
+
</console>
+
 
+
[[Category:HOWTO]]
+
[[Category:Featured]]
+

Revision as of 20:17, 24 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 and the IP protocol

The goal of this article being more focused on calculation of addresses used at the Internet layer so let's forget the gory details about the TCP/IP stack (you can find an extremely detailed discussion in How the TCP/IP stack works... still 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 or NCP. NCP looks like, from our point of view, prehistoric however it is of big importance as it established a lot of concepts still in use today : protocol data units, splitting an address in various components, connection management concept (TCP) and so on comes from NCP. Historical reward for those who are still reading this long paragraph: first, even a user was addressable in NCP messages second even in 1970 the engineers were concerned by network congestions issues (this page) :-)

Enough of historical background, packet networks history is super interesting but would make this article would just too long. So let's go back to the Internet Protocol! In those good old seventies the engineers who designed the Internet Protocol retained a 32 bits addressing scheme. Why 32 bits and not 64 or 128? In that decade, computers were rare with very limited resources and everyone at that time found that using 32 bits to express the a computer's address on the network would be way far more than enough : 2^32 gives 4,294,967,296 or roughly 4.3 billions (even some briliant visionaries like J.C.Lickleider would probably never have imagined the growth and popularity of computer networks at that time).

A story of cake

From the beginning, engineers were aware that, also their address pool was a priori gigantic, it had to be used wisely and address pool exhaution issues had always been in the landscape: between 1977 and 1984, the number of interconnected hosts grew from roughly a hundred to more than a thousand and it was clear that this would not reach any limit. Indeed even at this time the problem was more when the pool will be depleted rather than if it would become depleted. Seen from those good old eighties, the IPv4 pool depletion was not an immediate problem especially altough the issued started be be a bit more critical a decade later (IETF forecasted an IPv4 depletion between 2010 and 2017 in 1993). Just like you divide your birthday cake in slices of various sizes depending on your guests' appetite to minimize the waste, the engineers choose to divide the initial IPv4 pool in several slices of various size. Each one of those latter were then exclusively attributed to a given organization who wanted to connect to the ARPAnet by the Government of the United States (ICANN/IANA and Regional Internet Registries came much later at the end of nineties). Okay the ARPAnet became defunct with the split of MILNET in 1984 giving NSFNet later replaced with the Internet as we still know today but the principle of exclusively attributing IPv4 blocks remained the same.

Classeful networks

To shovel the IPv4 pool depletion problem as much as possible in the future, engineers choose to divide the initial IPv4 pool as a set of various sized blocks each one of those then being exclusively allocated to a given organization depending on her networking needs,. In





): RFC 790 introduced in 1981 mentions the notion of network classes. Just because you guests at a party have different appetites so you split a cake in more or less big slices, organizations have various needs so the initial IPv4 address pool has to be divided in a set of more or less big "slices". Depending of their size, those "slices" are said to belong to a class hence the terminology of classeful networks. Each organization wanting to connect the ARPAnet had to request the exclusive attribution of an exclusive address block of the IPv4 pool to the Government of the United States (ICANN/IANA and Regional Internet Registries came at the end of nineties), no matter of how it will be used or not internally.

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.