Network: IPv4 address space utilization forecasts - part 2

I decided to find some time slot today to continue on the forecasts issue and indeed as expected the exponential trend line seems to be much closer to the data allocation one. The "doom" date for the IPv4 address space using this trend line is about one year earlier than in case of linear approximation - 1st of March 2013. However the same remarks apply as for the linear trned line (see Linear Trend Line forecasts).

Approximation/trend line fitting was based on the least squares fitting algorithm (taken from: http://mathworld.wolfram.com/LeastSquaresFittingExponential.html). The chart comparing two trend lines is presented below:

Network: IPv4 address space utilization forecasts

Today I have found to extend my Ruby scripts to make some forecasts about the "doom" date - the date in which there will be no IPv4 prefixes available for allocations. The trend line has been approximated using the y=ax+b line (using the formulas from http://www.fourmilab.ch/hackdiet/www/subsubsection1_4_1_0_8_4.html) and extended until the total number of available prefixes is reached. The forecasted date is actually in the near future, namely end of February 2014. As one can see the approaximation is not perfect (probably the exponential approximation would fit better here) since recently the allocation line goes much higher than the trend line but this was for me the starting point. I will still observe the allocations from different registries over time and publish the results on the blog (with possible corrections to the forecasts).

One only has to take into account few things like:

• the current growth is above the trend line (mainly due to the contribution from the APNIC registry, for which the number of allocations is recently grownig much faster than in the past - one has to observe the progress in the future) - which might mean that the IPv4 prefix exhaustion date might be even closer
• there is still some number of prefixes currently reserved for the IANA but that might be released for allocations in the future
• the number of broadcasted prefixes in BGP is much lower than the allocated ones (the chart has been prepared on the basis of the number of prefixes allocated by each registry)
  

Network: BGP vs RIR IPv4 assignments

I have compared the values obtained from each registry against the prefixes announced in BGP (BGP potaroo IPv4 stats) and the results are presented on the chart. As far as the biggest registry is concerned (ARIN) the number of "active" prefixes (broadcasted in BGP) is significantly lower (at level of 60%) comparing to the number of assigned prefixes. Utlization rate of the other rirs is on a quite high level (for the smallest ones there are one or two prerfixes not announced in BGP). In the article I enclose the chart and the table presenting the values.

Registry	BGP announced	Allocated	Percentage
Afrinic	1	2	50%
Apnic	34	43	79%
Arin	59	97	60%
Arin	59	97	60%
Lacnic	5	7	71%
Ripencc	32	40	80%

Network: IPv4 vs IPv6 statistics

In my master thesis I did some research on the usage of the IPv4 address space and decided to continue check that topic right now. I have created a ruby application that parsed the statistics published by each RIR and calculate the overall number of /8 being assigned to each of them. Additionally a group of special purpose addresses reserved by IANA has been identified and placed on the charts.

The chart enclosed on the left presents the distribution of /8 prefixes (status on 22.08.2010). As expected the biggest number of /8 assignment is to the ARIN registry (~40% of the total number of IPv4 /8 prefixes). The numbers of prefixes for APNIC and RIPE are very closed together - although last year RIPE was ahead of APNIC. The important information is that there is still 13% (32 prefixes) available to be assigned for further IPv4 development.

A very valuable information

is how the utilization of the IPv4 prefixes looked over time. There is a figure, which shows the statistics retrieved from the RIRs from th 2003 till now (22.08.2010). One can easily notice that for all RIRs the number of assigned IPv4 prefixes increases. As far as the biggest contributor ARIN is concerned, the increase is very small. The highest increased in the last months can be identified for the APNIC RIR, which last year was still below RIPE and from beginning of this year has overcome it and became number two RIR in terms of /8 prefix utilization.

Figure presenting the total number of prefixes used shows the overall IPv4 /8 prefix statistics (including the reserved space for IANA) over time. As one can see the number is constantly increasing and it seems righ t now that eventually it will reach the total number of available IPv4 /8 prefixes. The author thinks that based on this chart the date of the exhaustion of the IPv4 address space could be estimated (one of the next steps for the author).

NEXT STEPS:

1. Approximate the total IPv4 prefix utilization to make an estimate of the possible date of the exhaustion of the IPv4 address space

2. Verify the number of assigned prefixes against the broadcasted ones (BGP) - hopefully statistics from http://bgp.potaroo.net could be used

Ruby - sending mails with attachements

Recently I have worked on the ruby script that would do some processing and afterwards would send an email containing the results nad charts (generated with gruff).

At first I tried the plain Net:SMTP and it was sufficient for my needs until I reached the attachements part. With the low level API it was very difficult to make it working (I reached the state that the attachements were sent with the email but they were corrupted). Fortunately I found on the web mailfactory gem (http://rubyforge.org/projects/mailfactory/, can be installed using gem install mailfactory) that helps the programmer to construct the content of the email that will be send with the Net:SMTP mechanisms later on. I really recommend it for its simplicity and ease of use. Below I enclose some example to show show to construct basic message with attachements:

def createInitialMail(subject, msg, from, to)
mail = MailFactory.new
mail.to = to
mail.from = from
mail.subject = subject
mail.html = msg
return mail
end

mail = createInitialMail subject, msg, from, to
mail.attach filename

...

Net::SMTP.start(host, port, host, account, password, :plain) do smtp
to_address = mail.to
smtp.send_message mail.to_s, from, to_address
smtp.finish
end

The createInitialMessage method is used in the example to build the main mail object. I marked with green colour the place how add attachements to the message. At the end there is an example how to send the previously constructed message using the Net::SMTP.

Ruby - rmagick gem on windows

I have been using Ruby 1.9.1 and unfortunately the precompiled binary rmagick-win32 gem is available only for 1.8.6. In order to use it on windows one needs to recompile the sources and install the gem. Fortunately after checking several different proposals on how to do that I found one that worked for me - it can be found here: http://www.waydotnet.com/blog/2010/02/rmagick-on-ruby-1-9-1-i386-mingw32-work-d/

My configuration is:

identify -version
Version: ImageMagick 6.6.3-7 2010-08-14 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC
Features: OpenMP
ruby -v
ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-mingw32]

The OS in my case is Windows 7, 64-bit.

Please do not forget (as I did) to replace the types (xml file from imagemagick), otherwise you will experience problems with the examples from the rmagick gem (e.g. watermark.rb).

VMware player 2.5.4 - Linux Ubuntu 2.6.32

Experiencing trouble in installing the vmware player 2.5.4 on ubuntu with kernel 2.6.32? This short guide should help you in solving the problem.

The problem that I experienced with the VMware 2.5.4 (and also 2.5.3) installer was that it hung at the end of the installation process (no progress in /tmp/vmware-/setup-.log file). The last line in the setup-.log file was:

Jun 16 20:30:01.280: app| Building module with command: /usr/bin/make -C /tmp/vmware-root/modules/vmnet-only auto-build SUPPORT_SMP=1 HEADER_DIR=/lib/modules/2.6.32-22-generic/build/include CC=/usr/bin/gcc GREP=/usr/bin/make IS_GCC_3=no VMCCVER=4.4.3

The problem is that there are wrong header files included by the module source code files that come with the vmware player. A workaround is pretty simple:

1) Install vmware player 2.5.4 as follows:

# ./VMware-Player-2.5.4-246459.i386.bundle --ignore-errors

2) Build and configure

a) Unpack the modules into the tmp directory:

# cd /tmp/vmware-/
# mkdir modules
# cd modules
# tar xf /usr/lib/vmware/modules/source/vmnet.tar
# tar xf /usr/lib/vmware/modules/source/vmci.tar

b) Replace the included header files:

# cd vmnet-only/
# sed -i "/vnetInt.h/ a\#include \"compat_sched.h\"" vnetUserListener.c
# cd ../vmci-only/include
# sed -i "/compat_page.h/ a\#include \"compat_sched.h\"" pgtbl.h

c) Replace the original tar archives:

# cd ..
# cd ..
# tar cf /usr/lib/vmware/modules/source/vmnet.tar vmnet-only
# tar cf /usr/lib/vmware/modules/source/vmci.tar vmci-only

d) Configure/compile the modules:

# vmware-modconfig --console --install-all
...

Afterwards the compilation of modules should go fine and the installation of vmware is finished properly.