Dependence on Internet Protocol Version 4 in application software source code

(1)

P.O. Box 79071 1070 NC Amsterdam The Netherlands t +31 20 314 0950 September 2010

Hans van Oosten Xander Schrijen Joost Visser

Public

(2)

Dependencies on internet protocol version 4 in application software source code • SIG analysis report

1070 NC Amsterdam The Netherlands

(3)

the Internet Protocol (IPv4).

The IPv4 Internet addresses that are currently being assigned to computers on the In-ternet are bound to run out in a couple of years. When switching to the next version (IPv6), more addresses will become available, but systems with hard-coded dependen-cies are then at risk of malfunctioning.

We found that IPv4 dependencies are present in the source code of one in every 12 ap-plications.

(4)

(5)

2 SCANNED SYSTEMS ...7

3 METHOD OF SCANNING ...8

4 SCAN RESULTS ...9

(6)

1 Introduction

Internet Protocol versions 4 and 6

Information communication over the Internet is currently mainly done with version 4 of the Internet Protocol (IPv4). Since 1981, this protocol specifies how computers are identified within the communication network by a unique address. In IPv4, the maxi-mum number of such addresses that can be assigned to computers is 4 billion.

With the growing number of people who are using mobile computers and telephones the amount of available unique addresses is getting exhausted quickly. People estimate that the last IPv4 address will be allocated in January 20121_.

Internet Protocol version 6 (IPv6), developed as a successor to IPv4, offers a solution to this problem with an enormously big supply of unique addresses. During the nineties of the past century IPv6 has been developed and standardized. However the usage and application of IPv6 is staying behind expectation. Organisations seem to stick to IPv4.

Scanning for IPv4 dependencies

We have performed an explorative scan of the source code of a large number of informa-tion systems to find out whether they contain unexpected technical dependencies on specifics of the Internet protocol.

Normally application software should not contain any specific references to the com-munication protocols that are used. Such details should be abstracted over by making use of development libraries or other abstraction mechanisms. If dependencies on IPv4 do exist, the application may fail when the underlying deployment environment switches from IPv4 to IPv6.

The remainder of this report is structured as follows. In chapter 2 we describe the set of software systems on which we performed our scan. In chapter 3 we describe the light-weight method of scanning that we employed. In chapter 4 we present the scan results. In chapter 5 we discuss the relevance of our findings.

(7)

been submitted for analysis to our software analysis laboratory.

The laboratory of the SIG performs analysis of software systems for its clients in the con-text of several services: Software Risk Assessments, Software Monitoring, and Software Product Certification. These software systems have been developed in-house or by ex-ternal suppliers to support a wide range of business domains. Typically, several differ-ent programming languages have been applied in the construction of these applica-tions.

From the entire collection of systems that have been analysed by our lab, we have made a selection of about 130 systems. Two important selection criteria have been the age of the system’s source code and the programming languages used in its construction. The source code of all systems we scanned is younger than 18 months with the greater ma-jority younger than 9 months. We only scanned systems that contain source code writ-ten in C, C#, Java or combinations of these. Finally, we have only scanned systems that can be classified as “application software” and we have excluded “systems software” and “developer tools”.

An overview of the systems selected for scanning is shown in Table 1. As can be seen in the table, Java and C# are more commonly used to construct business applications than the C language. Note that some systems make use of multiple programming languages.

Programming language

Number of scanned applications

Average rebuild value of scanned applications

C 14 158 person months

C# 39 83 person months

Java 86 159 person months

Total 132 138 person months

Table 1: Scanned systems per technology.

The table also shows the average size of the systems in terms of their “rebuild value”. The rebuild value stands for the number of person-months that would on average need to be invested to rebuild the system from scratch, based on industry-average productiv-ity statistics for each programming language.

(8)

3 Method of scanning

We applied a lightweight scan, consisting of a limited number of search patterns, to find out whether IPv4 dependence exists. For different technologies, we applied differ-ent patterns.

Scanned patterns for the C language

In the C programming language, the BSD socket library is typically used for making IPv4 connections. On Windows platforms, the Microsoft WinSock library is also used quite often as an alternative. Both libraries use certain constant values when setting up an IPv4 connection.

We scanned for the presence of the constant value “PF_INET” that is typical for the pro-tocol family of IP within BSD. We also scanned for “AF_INET” that is typical for the ad-dress family of BSD. Both literals are also common within Microsoft platforms applying the WinSock library.

Scanned patterns for the C# and Java languages

In object-oriented programming languages such as C# and Java, standard libraries allow abstraction over low-level details such as the version of the IP. When using these librar-ies, any remaining version-dependent information, such as specific IP addresses should be specified in configuration files, not hard-coded in source code.

We have scanned for the occurrence of IPv4-specific address formats in source code. IPv4 addresses have a particular format, which is distinct from the IPv6 address format. We have scanned for IPv4-specific address formats.

How to interpret scan results

The patterns we scanned for are not intended to be exhaustive. When a pattern is found in a given system, this means an IPv4 dependency exists, but not necessarily vice

versa. In other words, when no patterns are found, some other kind of IPv4 dependency

might still exist.

We have only scanned the source code of selected systems, not other artefacts such as configuration code. IPv4 dependencies in configuration code can be seen as relatively harmless, because in principle these dependencies can be removed by reconfiguration only. But IPv4 dependencies in source code can not be remedied by reconfiguration. They require development and testing effort, recompilation, and redeployment of the application. Thus, when one of our patterns is found in the source code of an application this indicates that substantial effort may be necessary to remove the dependency that was found.

(9)

over the various scanned technologies is listed in Table 2.

Technology Systems in which IPv4 dependencies were found

C 5 out of 14 (36%)

C# 1 out of 39 (2.6%)

Java 7 out of 86 (8.1%)

Total 11 out of 132 (8.3%)

Table 2: Scan results.

When we look at the results per technology, we can observe that the degree of infection in program code written in the C language is much higher (one in three systems) than for program code written in the object-oriented languages C# and Java.

(10)

5 Discussion

We have found IPv4 dependencies in one in every twelve software systems that we have investigated. Dependencies were found in all three technologies scanned, with the highest number of dependencies found in C code.

Will dependencies always lead to malfunction?

Will those systems in which we found malfunctions crash with certainty or otherwise malfunction when the network in which they operate switches from IPv4 to IPv6? No, in some cases it may be possible that in spite of the dependency, the system keeps func-tioning correctly. Further investigation of the dependency is needed in order to deter-mine with certainty how the dependency influences the functioning of the system and whether repairs are needed.

Does the scan reveal all dependencies?

Are the scanned systems in which no dependencies were found with certainty free of IPv4-related problems? No, we performed a lightweight scan for a limited number of patterns. It is possible that a more thorough scan would reveal some further dependen-cies even in the systems where no hits were registered so far.

Does the scan reveal more general issues?

The systems that were scanned are not systems software, but application programs. In the greater majority of cases, a well-constructed application program should be pro-grammed at a sufficient level of abstraction to be independent of any low-level com-munication protocols, storage formats, or other hardware-dependent details. A finding of IPv4 dependence in an application may be seen as symptomatic for a more general problem that the system is not programmed at the right level of abstraction. As a re-sult, the system may be hard to adapt to changing deployment environments or ing user requirements. A change from IPv4 to IPv6 is only one example of such a chang-ing environment.

What are the repair costs?

Repair costs of IPv4 dependencies depend on a number of factors. The number of de-pendencies and how broadly they are spread out through the program code is one such factor. The general technical quality or maintainability of the software system is an-other. Finally, the moment at which repair is needed, and hence its urgency may be-come an important cost driver. When software defects are found early in the lifecycle, i.e. before the system is tested, integrated, deployed, and enhanced, the repair costs can be kept to a minimum. When defects are found late in the lifecycle, their repair costs are generally (much) higher.

What actions are recommended?

A general piece of good advice to system owners is to search for and detect IPv4 depend-encies early, such that repairs can be performed as part of regular maintenance rather than as emergency response to imminent or actual system failure.