Difference between pages "Funtoo Linux Kernels" and "IPv4 calculations"

(Difference between pages)
(Kernel Features and Stability)
 
 
Line 1: Line 1:
This Section will give you an overview of kernels used in funtoo.
+
WARNING: Work in progress. Do not edit this article unless you are the original author.
  
Funtoo Linux provides a number of new kernels for your use. This is the official page for all Funtoo Linux kernel information.
 
  
Some points of interest:
+
= Refresh on TCP/IP model =
  
* Most Funtoo Linux kernels support the handy <tt>[[#Binary USE|binary]]</tt> USE flag, described below.
+
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.  
* Funtoo Linux offers quality kernels from other Linux Distributions, like <tt>ubuntu-server</tt> and <tt>debian-sources</tt>.
+
 
* A detailed [[#Kernel Features and Stability|Kernel Features and Stability]] table can be found below.
+
<illustration goes here TCP/IP model>
* Advanced users may want to take a look at [[Additional Kernel Resources]].
+
* There is a quick'n dirty howto to compile your own [[kernel]] with initramfs the funtoo way.
+
  
== Overview of Kernels ==
+
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.
  
=== sysrescue-std-sources ===
+
= The Internet layer and the IP protocol =
  
This kernel is from the [http://www.sysresccd.org SystemRescueCD project], and is based on Fedora 14/15, plus some other patches related to booting from a live CD. It is a quality kernel, and is generally pretty stable. It is not suitable for production servers but is a good choice for Funtoo Linux desktops. Earlier,the [[Funtoo Linux Installation]] Guide recommended this kernel for general users, but now 'debian-sources' is recommended. Note however, that by design all audio functions are removed from SystemRescueie no sound when using this kernel.
+
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]) :-)
  
=== vanilla-sources ===
+
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).
  
This will install the "vanilla" (unmodified) Linux kernel sources. Current recommended version is 3.x. Funtoo Linux fully supports Linux 3.x. The advantages of this kernel include recent improvements to [[Linux Containers]], a very modern networking stack with lots of bug fixes, and high reliability for desktops and servers. The downside is that this kernel must be manually configured by the user and does not have built-in <tt>genkernel</tt> support via the <tt>binary</tt> USE flag at this time.
+
== A story of cake ==
  
=== gentoo-sources ===
+
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.
  
This kernel tree is based on stable kernels from [https://www.kernel.org/ kernel.org] with genpatches applied [http://dev.gentoo.org/~mpagano/genpatches/about.htm genpatches].
+
=== Classeful networks ===
Gentoo patchset aims to support the entire range of Gentoo-supported architectures. List of available genpatched kernels: [http://dev.gentoo.org/~mpagano/genpatches/kernels.htm genpatches-kernels]
+
  
=== openvz-rhel6-stable ===
+
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
  
This is a RHEL6-based kernel with OpenVZ support. This kernel is now the preferred kernel for production OpenVZ deployments. It requires gcc-4.4.5 to build, which it will use automatically without the user needing to use <tt>gcc-config</tt>. We use this version of gcc since this is the version of gcc used by Red Hat to build this kernel.
 
  
=== openvz-rhel5-stable ===
 
  
This kernel is based on the latest Red Hat Enterprise Linux 5.6 kernel, and contains additional OpenVZ (virtual containers) patches from the [[OpenVZ on Funtoo Linux|OpenVZ]] project. It is a very stable and reliable kernel, and is recommended for use in production environments. The only major downside to this kernel is that it is based on Linux 2.6.18 -- some parts of the kernel are out-of-date, and it is not compatible with modern versions of udev. However, it is pretty trivial to downgrade udev to an earlier version on Funtoo Linux and this kernel has a track-record of being rock-solid. When stability is paramount, you put up with the udev downgrade, use this kernel, and can enjoy hundreds of days of uptime. For more information on how to use this kernel with Funtoo Linux, see the [[RHEL5 Kernel HOWTO]].
 
  
=== ubuntu-server ===
 
  
This is the kernel from Ubuntu Server. Version <tt>2.6.32.32.62</tt> is the same version used in Ubuntu Server 10.04 LTS, and version <tt>2.6.35.28.50</tt> is the one used in Ubuntu Server 10.10 (currently masked). In our testing of <tt>2.6.32.32.62</tt>, it has been very reliable and offers very good performance. One exception, which is common among 2.6.32-based kernels, is that it's recommended that you emerge <tt>broadcom-netxtreme2</tt> if you have any Broadcom-based NICs, as the in-kernel drivers have compatibility issues with certain models. This kernel is a very good option if you want a relatively modern server kernel and do not need [[OpenVZ]] support. We use gcc-4.4.5 to build this kernel. It will use gcc-4.4.5 automatically, without requiring the user to use <tt>gcc-config</tt>.
 
  
=== debian-sources ===
 
  
This is the Debian kernel. '''These ebuilds now support the <tt>binary</tt> USE flag.''' Daniel has added a special <tt>config-extract</tt> command which can be used to list all available official Debian kernel configurations, and generate them from the Debian files included with the kernel. This kernel has optional [[OpenVZ]] support, but it is much better to use <tt>openvz-rhel6-stable</tt> if you want a production-quality OpenVZ installation. For more information about how to use <tt>debian-sources</tt> and <tt>config-extract</tt>, see [[#Using Debian-Sources with Genkernel|Using debian-sources with Genkernel]] below.
 
  
=== debian-sources-lts ===
 
  
This is the Debian long-term stable kernel. '''These ebuilds now support the <tt>binary</tt> USE flag.''' Daniel has added a special <tt>config-extract</tt> command which can be used to list all available official Debian kernel configurations, and generate them from the Debian files included with the kernel.
+
): 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.
  
== Binary USE ==
+
= Classful and classless networks =
  
Many of the kernel ebuilds in Funtoo Linux support the very useful <tt>binary</tt> USE flag. By enabling this USE flag and emerging the kernel, the ebuild will automatically build a binary kernel image, initramfs and kernel modules and install them to <tt>/boot</tt>. The binary kernel image and initramfs can be used to boot your Funtoo Linux system without requiring any additional configuration. This is a great way to get a Funtoo Linux system up and running quickly. Here's how to do it:
+
Those addresses follows the thereafter logic:
  
<pre>
+
{| class="wikitable"
# echo "sys-kernel/openvz-rhel5-stable binary" >> /etc/portage/package.use
+
# emerge openvz-rhel5-stable
+
# nano -w /etc/boot.conf
+
# boot-update
+
</pre>
+
 
+
More information can be found in the [[Funtoo Linux Installation]] Guide.
+
 
+
== Funtoo Linux Genkernel ==
+
 
+
Funtoo Linux contains a forked/enhanced version of genkernel with the following new capabilities:
+
 
+
* genkernel can use a build directory that is separate from the kernel source directory. This is enabled using the new <tt>--build-dst</tt> option.
+
* <tt>--build-src</tt> is a new option that is equivalent to the <tt>--kerneldir</tt> option.
+
* <tt>--fullname</tt> can be used to specify the entire name of the kernel and initramfs images -- everything after <tt>kernel-</tt> and <tt>initramfs-</tt>.
+
* <tt>--firmware-src</tt> - a new option that works identically to <tt>--firmware-dir</tt>.
+
* <tt>--firmware-dst</tt> - a new capability - you can now define where genkernel installs firmware.
+
* Genkernel uses Funtoo Linux <tt>lvm2</tt> rather than building its own.
+
* Some compile fixes.
+
 
+
== Kernel Features and Stability ==
+
 
+
This page provides an overview of kernel features and stability information:
+
 
+
{| {{table}}
+
!Kernel Name
+
!Version
+
!USE flags
+
!Stability
+
!Extra Features
+
!Req'd udev
+
!Notes
+
 
|-
 
|-
|<tt>[[#vanilla-sources|vanilla-sources]]</tt>
+
| colspan="2" | '''32 bits (fixed length)'''
|3.11.4
+
|N/A
+
|'''Excellent''' - recommended for desktops and servers.
+
|N/A
+
|Any
+
|Recommended for modern networking stack, hardware and [[Linux Containers]] support. This kernel must be manually configured by the user. New Features: [http://kernelnewbies.org/Linux_3.11 kernelnewbies.org/linux_3.11]  New Drivers: [http://kernelnewbies.org/Linux_3.11-DriversArch kernelnewbies/Linux_3.11-DriversArch]
+
|-
+
|<tt>[[#gentoo-sources|gentoo-sources]]</tt>
+
|3.11.4
+
|N/A
+
|'''Excellent''' - recommended for desktops and workstations
+
|N/A
+
|Any
+
|Recommended for modern networking stack, hardware and [[Linux Containers]] support. This kernel must be manually configured by the user. New Features: [http://kernelnewbies.org/Linux_3.11 kernelnewbies.org/linux_3.11]  New Drivers: [http://kernelnewbies.org/Linux_3.11-DriversArch kernelnewbies/Linux_3.11-DriversArch]
+
|-
+
|<tt>[[#sysrescue-std-sources|sysrescue-std-sources]]</tt>
+
|3.0.21.302
+
|<tt>binary</tt>
+
|''Good'' - recommended for desktops
+
|N/A
+
|Any
+
|Nvidia card users: binary use flag installs nouveau drivers. Not compatible with nvidia-drivers.
+
|-
+
|<tt>[[#openvz-rhel6-stable|openvz-rhel6-stable]]</tt>
+
|2.6.32.042.079.5
+
|<tt>binary</tt>
+
|'''Excellent''' - recommended for production servers
+
|N/A
+
|Any
+
|This kernel is built with gcc-4.4.5. <tt>emerge broadcom-netxtreme2</tt> for reliable BCM5709+ support (integrated NIC)
+
|-
+
|<tt>[[#openvz-rhel5-stable|openvz-rhel5-stable]]</tt>
+
|2.6.18.028.095.1
+
|<tt>binary</tt>
+
|'''Excellent''' - recommended for production servers
+
|OpenVZ
+
|=sys-fs/udev-146*
+
|Broadcom <tt>bnx2</tt> driver module bundled with kernel appears to be OK. This kernel is built with gcc-4.1.2. Enabling the <tt>binary</tt> USE flag will cause gcc-4.1.2 to be emerged and used for building the kernel.
+
|-
+
|<tt>[[#ubuntu-server|ubuntu-server]]</tt>
+
|2.6.32.32.62
+
|<tt>binary</tt>
+
|'''Excellent''' - recommended for production servers (still in extended testing)
+
| N/A
+
|Any
+
|This kernel is built with gcc-4.4.5. <tt>emerge broadcom-netxtreme2</tt> for reliable BCM5709+ support (integrated NIC)
+
|-
+
|<tt>[[#ubuntu-server|ubuntu-server]]</tt>
+
|2.6.35.28.50
+
|<tt>binary</tt>
+
|''not yet tested''
+
| N/A
+
|Any
+
|This kernel is built with gcc-4.4.5. <tt>emerge broadcom-netxtreme2</tt> for reliable BCM5709+ support (integrated NIC)
+
|-
+
|<tt>[[#debian-sources|debian-sources]]</tt>
+
|3.10.11
+
|<tt>openvz</tt>
+
|''Good'' - default kernel recommended by Funtoo
+
|OpenVZ (optional)
+
|Any
+
|See [[#Using debian-sources with Genkernel]], below.
+
 
|-
 
|-
 +
| '''Network''' part (variable length of N bits ) || '''Host''' part (length : 32 - N bits)
 
|}
 
|}
  
== Using Debian-Sources with Genkernel ==
+
* 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
{{ fancyimportant|Debian-sources is now fully compatible with ''binary'' USE flag and recommended for desktop users. The below example is valid for manual installation. At least 12G of /var/tmp required to build
+
}}
+
This section describes how to build a binary kernel with <tt>debian-sources</tt> and <tt>genkernel</tt>, and it also explains how to use Funtoo Linux's <tt>config-extract</tt> tool to list and create official Debian kernel configurations.
+
 
+
=== First step: emerging the required packages ===
+
 
+
The first step is to emerge:
+
 
+
# The Debian sources
+
# Genkernel itself
+
 
+
This is achieved with:
+
 
+
<pre>
+
# emerge sys-kernel/debian-sources sys-kernel/genkernel
+
</pre>
+
 
+
Once the Debian kernel sources are deployed, you should find a directory named '''linux-debian-''version''''' (e.g. linux-debian-2.6.32.30) under '''/usr/src'''. Update your the '''linux''' symlink to point on this directory:
+
<pre>
+
# cd /usr/src
+
# rm linux
+
# ln -s linux-debian-2.6.32.30 linux
+
</pre>
+
Alternatively, emerge the debian-sources with USE="symlink"
+
 
+
=== Second step: Grabbing a configuration file ===
+
 
+
If is now time to download the kernel configuration file. For this tutorial we will use a configuration file for AMD64 (several others architectures like MIPS or SPARC64 are available.)  To view a complete list of available kernel configurations, type <tt>./config-extract -l</tt> in the Debian kernel source directory:
+
 
+
<pre>
+
ninja1 linux-debian-2.6.32.30 # ./config-extract -l
+
 
+
====== standard featureset ======
+
 
+
      alpha: alpha-generic, alpha-legacy, alpha-smp
+
      amd64
+
      armel: iop32x, ixp4xx, kirkwood, orion5x, versatile
+
        hppa: parisc, parisc-smp, parisc64, parisc64-smp
+
        i386: 486, 686, 686-bigmem, amd64
+
        ia64: itanium, mckinley
+
        m68k: amiga, atari, bvme6000, mac, mvme147, mvme16x
+
        mips: 4kc-malta, 5kc-malta, r4k-ip22, r5k-ip32, sb1-bcm91250a, sb1a-bcm91480b
+
      mipsel: 4kc-malta, 5kc-malta, r5k-cobalt, sb1-bcm91250a, sb1a-bcm91480b
+
    powerpc: powerpc, powerpc-smp, powerpc64
+
        s390: s390x, s390x-tape
+
        sh4: sh7751r, sh7785lcr
+
      sparc: sparc64, sparc64-smp
+
    sparc64: sparc64, sparc64-smp
+
 
+
====== vserver featureset ======
+
 
+
      amd64
+
        i386: 686, 686-bigmem
+
        ia64: itanium, mckinley
+
    powerpc: powerpc, powerpc64
+
        s390
+
      sparc
+
    sparc64
+
 
+
====== xen featureset ======
+
 
+
      amd64
+
        i386
+
 
+
====== openvz featureset ======
+
 
+
      amd64
+
        i386
+
</pre>
+
 
+
Type <tt>config-extract -h</tt> for extended usage information:
+
 
+
<pre>
+
ninja1 linux-debian-2.6.32.30 # ./config-extract -h
+
This work is free software.
+
 
+
Copyright 2011 Funtoo Technologies. You can redistribute and/or modify it under
+
the terms of the GNU General Public License version 3 as published by the Free
+
Software Foundation. Alternatively you may (at your option) use any other
+
license that has been publicly approved for use with this program by Funtoo
+
Technologies (or its successors, if any.)
+
 
+
usage: config-extract [options] arch [featureset] [subarch]
+
 
+
  -h  --help        print this usage and exit
+
  -l  --list        list all available kernel configurations
+
  -o  --outfile    specify kernel config outfile --
+
                    defaults to .config in current directory
+
  [featureset]      defaults to "none" if not specified
+
  [subarch]        defaults to the only one available; otherwise required
+
 
+
This program was written by Daniel Robbins for Funtoo Linux, for the purpose of
+
easily and conveniently extracting Debian kernel configurations. To see a nice
+
list of all available kernel configurations, use the --list option.
+
 
+
Debian's kernel configs are specified internally in arch_featureset_flavor
+
format, such as: "amd64_openvz_amd64". The featureset typically describes an
+
optional kernel configuration such as "xen" or "openvz", while the flavor in
+
Debian terminology typically refers to the sub-architecture of the CPU.
+
 
+
When using this command, you must specify an arch. A featureset of "none" is
+
assumed unless you specify one, and by default this program will pick the only
+
available subarch if there is only one to choose from. If not, you will need to
+
pick one (and the program will remind you to do this.)
+
 
+
The kernel configuration will be written to ".config" in the current directory,
+
or the location you specified using the -o/--outfile option.
+
</pre>
+
 
+
Let's use <tt>config-extract</tt> to create a kernel configuration for an amd64 system:
+
 
+
<pre>
+
# cd linux
+
# ./config-extract amd64
+
Wrote amd64_none_amd64 kernel configuration to /usr/src/linux-debian-2.6.32.30/.config.
+
</pre>
+
 
+
<tt>config-extract</tt> also allows you to extract special Debian featuresets, such as settings for Xen and [[OpenVZ]] kernels:
+
 
+
<pre>
+
# ./config-extract amd64 openvz
+
Wrote amd64_openvz_amd64 kernel configuration to /usr/src/linux-debian-2.6.32.30/.config.
+
</pre>
+
 
+
'''It is necessary to name the kernel configuration file something other than ".config" to avoid errors with genkernel.'''
+
 
+
 
+
After using <tt>config-extract</tt>, run <tt>make oldconfig</tt> and accept all default options by hitting Enter at all prompts.
+
 
+
=== Third step: Building and installing the kernel ===
+
  
This is simply achieved by:
+
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  :
  
<pre>
+
* Network 1 Host 1
# genkernel --kernel-config=config-2.6.32-5-amd64 all
+
*
</pre>
+
  
* --kernel-config: use the given configfile. If you only give a filename here, it is searched for in your current working dir. You can also use a relative or an absolute path leading to your configfile here (for example: "--kernel-config=/usr/src/linux/configfile").
 
* all: rebuild the kernel image and the initramfs ramdisk image (aside of kernel modules, the ramdisk image contains tools such as BusyBox and some generic startup scripts, depending on options you use on the command line several additional tools like lvm or raid volume management can be incorporated as well).
 
  
{{ fancyimportant|Unless explicitly stated via ''--no-clean'' or ''--no-mrproper'', Genkernel will do a '''make mrproper''' in the kernel source tree, thus cleaning a previous build '''and removing the previous kernel configuration file''' in it.
+
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
  
If you use Genkernel to rebuild a Linux kernel on SPARC64, remember to either:
+
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
* Set '''sparc64-unknown-linux-gnu-''' in ''General setup --> Cross-compiler tool prefix''
+
* Put '''--kernel-cross-compile=sparc64-unknown-linux-gnu-''' on the Genkernel command line
+
  
Once the kernel has been compiled and the ram disk has been generated, the kernel image plus its companion files (initramfs image and System.map) are placed in the /boot directory. You can use your favourite tool to update your bootloader configuration files.
+
  
[[Category:Internals]]
+
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 :
[[Category:Funtoo features]]
+
[[Category:Kernel]]
+
* 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.

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.