Unit of Competence Module Code & Title Learning Outcomes Duration

(In Hours)
Build Internet ICT HNS4 • Plan and design internet infrastructure
Infrastructure M03 0811 • Install and configure internet
Building infrastructure and services
Internet • Test security and internet access
Infrastructure • Ensure user accounts are verified for 230 hrs
security
• Manage and support internet

Learning Module
TVET PROGRAM TITLE: Hard ware and network Servicing
Module Title: Building Internet Infrastructure Module Code: ICT HNS4 M03 0811
Nominal Duration: 230hrs
Description:
This unit defines the competence required to design and implement an infrastructure
for internet services.
Learning Outcomes:
At the end of this module the trainee will be able to:
LO1: Plan and design internet infrastructure
LO2: Install and configure internet infrastructure and services
LO3: Test security and internet access
LO4: Ensure user accounts are verified for security
LO5: Manage and support internet
MODULE CONTENTS:

1 Planning and designing internet infrastructure

• Selecting internet infrastructure and requirements
• Evaluating the internet service performance
• Ensure hardware, software, network and security requirements in accordance with agreed
business and end-user specifications.
• Determining internet protocol address allocation based on the number of addresses needed.

2.Installing and configuring internet infrastructure and services

• Installing and testing cables where appropriate according to the standard.

• Building and testing Mail servers when needed.
• Installing and configuring Workstation software to access services
• Installing necessary hardware and software to connect the internet to intranets or network if
 required.
• Configuring domain names and internet protocol addresses to make internet access possible.
• Set up Software to provide services as required.
• Installing and configuring software that provides internet links with existing databases,
documents and files.

3. Testing security and internet access

• Testing and verifying Security access levels based on security policy.

• Monitoring and evaluating capability and reliability of security systems based on security policy.
• Make Changes to the system and ensure protection against known and potential threats.

4.Ensuring user accounts are verified for security

• Verifying user settings to ensure that they conform to security policies.

• Displaying legal notices at appropriate locations for system users.
• Checking passwords in accordance with business policies and verify with software utility tools.

5.Managing and supporting internet

• Assisting management in developing procedures and policies for maintaining the internet
infrastructure.
• Obtaining, installing and using management tools to assist in internet administration.
• Monitoring traffic, appropriateness of broadcasts, content access and hits over the internet.
• Optimizing Internet performance in accordance with business need.

LEARNING STRATEGIES:

➢ Lecture
➢ Discussion
➢ Group work
➢ Individual assignment
➢ Project work

Assessment Methods:

• Interview and Written Test

• Oral Questioning
• Observation and
• Demonstration

Assessment Criteria:
LO1: Plan and design internet infrastructure
• Make sure that internet infrastructure is selected in line with business and end-user requirements,
within budget limitations.
• Test the internet service is evaluated for satisfactory performance and confirmed that the service
 meets business and end-user requirements.
• Test out Hardware, software, network and security requirements are ensured in accordance with
agreed business and end-user specifications.
• Check internet protocol address allocation is determined based on the number of addresses
needed
LO2: Install and configure internet infrastructure and services
• Check cables is installed and tested where appropriate according to the standard.
• Make sure mail servers is built and tested
• Check Workstation software is installed and configured to access services
• Check Necessary hardware and software is installed to connect the internet to intranets or
network if required.
• Check Domain names and internet protocol addresses are configured to make internet access
possible.
• Check Software is set up to provide services as required.
• Check Software is installed and configured that provides internet links with existing databases,
documents and files.
LO3: Test security and internet access
• Test out security access levels is tested and verified based on security policy.
• Make sure that capability and reliability of security systems is monitored and evaluated based on
security policy.
• Check changes are made to system to ensure protection against known and potential threats.
LO4: Ensure user accounts are verified for security
• Prove user settings are verified to ensure that they conform to security policies.
• Verify legal notices are displayed at appropriate locations for system users.
• Make sure passwords are checked in accordance with business policies and verified with software
utility tools.
LO5: Manage and support internet
• Make sure that management is assisted in developing procedures and policies for maintaining the
internet infrastructure.
• Make sure that management tools are obtained, installed and used to assist in internet
administration.
• Test traffic, appropriateness of broadcasts, content access and hits are monitored over the internet.
• Test out internet performance is optimized in accordance with business need.

Resource requirement
 Recommended Ratio
Category/Item Description/Specifications Quantity
(Item :Trainee)

A. Learning Materials

CBLM CBLM prepared by Trainer 1pcs 1:10

Book From college library

E-Book From Internet 1:1
Internet Broad band
B. Learning Facilities &infrastructure

Laboratory
The college laboratory class 2 1:20
Library
The college library 1 1:40
Class room
Class room 1 1:40
C. Consumable Materials

A4 printer paper ,Duplicating

Paper 2desta 1:10
paper
Pen 1 packet
White Board 1pcs 1:40
White board Marker Maxflo-Push button
Blank CD CD-R,CD-RW 20pcs 1:2
Blank DVD DVD-R,DVD-RW 20pcs 1:2
Flash Disk Scandisk(2GB) 2pcs 1:5
Operating system Windows XP service 2 pcs for
Software pack1,windows XP SP2, each
MS-Office
2pcs for
Application Software 2003,2007,2010,Power Geez 1:5
each
2005,2006,2009
Printer driver, system 1pcs for
Driver Software 1:10
compatible drivers each
500m for
UTP CAT 5/5e/6
each
Network cable Coaxial cable(Thinnet &
200m
Thick net)
Fiber Optic cable 200m
RJ-45 1000 pcs 4:1
Network cable RJ-11 50 pcs 2:1
connector BNC-connector 50 pcs 2:1
Fiber optic connector 50 pcs 2:1
D. Tools and Equipments

Computer Pentium IV CPU 3.00 40pcs 1:1

 GHz,512/1GB/2GB
RAM,40/80/160 GB Hard
Disk,DVD-RW CD-ROM
drive
Printer HP Laser Jet 1pcs 1:40
Printer Color Compatible to printer 1pcs 1:40
Photo Copy machine Canon 1pcs 1:40
LCD projector LCD 1pcs 1:40
Phone Apparatus Any 1pcs 1:40
Network diagnostic
Softwares &hardwares 2sets 1:10
tools
Network Tool kits Hardware 2 sets 1:10
2pcs for
Network cable Tester Analog tester & digital tester 1:10
each
Cable Crimper 4pcs 1:4
Hub 24 port 2 1:24
Switch 32 port 2
Internal Modem 2 1:40
Router 24port 1 1:10
Pentium IV dual core 1TB
Server Computer 1 1:40
Hard Disk

Session Plan No. 01

Unit of Competence: Hard ware and network Servicing
Module Title Building Internet Infrastructure Module Code: ICT HNS4 M03 0811
Learning Outcome: Plan and design internet infrastructure
Session Objectives: At the end of this session the trainees shall able to:

• Identifying the Internet Infrastructure requirements

• General knowledge of the organization’s business needs and
functions
• Security knowledge, with understanding of general features
and capabilities, with limited depth in some areas (e.g. when
monitoring security and internet access
• Knowledge of internet technologies
• General understanding of LAN-based communications
technologies.

Nominal Learning
Activities Contents
Duration Methods
Lecture and
Introduction 30min Over view network infrastructure
Introduced
Brain-storming,
Selecting internet infrastructure based on business
lecture and
and end-user requirements, with budget limitations
Assignment
Evaluating the internet service for satisfactory
Lecture,
performance and confirm that the service meets
Demonstrate
Body business and end-user requirements
Ensure hardware, software, network and security
Group work and
requirements in accordance with agreed business
Demonstrate
and end-user specifications
Determining internet protocol address allocation Lecture and
based on the number of addresses needed assignment
Evaluations Oral question, Assignment, written test
Depend on the students evaluation giving some Lecture and
Summary summary each selected topics Demonstrate
✓ TTLM
✓ Internet
Resources ✓ E-Books from internet
✓ Books from library
 Hardware and Network Servicing Level IV
Building Internet Infrastructure (ICT HNS4 M03 0811)
1. Planning and Designing Internet Infrastructure
a. Overview network infrastructure
Planning network infrastructure is a complex task that needs to be performed so that the network
infrastructure needed by the organization can be designed and created. Proper planning is crucial
to ensure a highly available network and high performance network that result in reduced costs
and enhances business procedures for the organization.
To properly plan your network infrastructure, you have to be knowledgeable on a number of
factors, including the following:

• Requirements of the organization.

• Requirements of users.
• Existing networking technologies.
• Necessary hardware and software components.

Networking services which should be installed on the user’s computers so that they can perform
their necessary tasks. A typical network infrastructure planning strategy should include the
following:

• Determine the requirements of the organization and its users, and then
document these requirements.
• Define a performance baseline for all existing hardware devices.
• Define a baseline for network utilization as well.
• Identify the capacity for the physical network installation. This should
encompass the following:
o Server hardware, client hardware.
o Allocation of network bandwidth for the necessary networking
services and applications.
o Allocation of Internet bandwidth
• Determine which network protocol will be used.
• Determine which IP addressing method you will use.
• Determine which technologies, such as operating systems and routing
protocols are needed to cater for the organization’s needs as well as for
possible future expansions.
• Determine the security mechanisms which will be implemented to secure the
network and network communication.

After planning, the following step would be to implement the technologies which you have
identified. Implementation of the network infrastructure involves the following tasks:

• Installing the operating systems.

• Installing the necessary protocols and software components.
 • Deploying DNS or WINS name resolution.
• Designing the DNS namespace.
• Assigning IP addresses and subnet masks to computers.
• Deploying the necessary applications.
• Implementing the required security mechanisms.
• Defining and implementing IPSec policies.
• Determining the network infrastructure maintenance strategy which you will
employ once the network infrastructure is implemented. Network
infrastructure maintenance consists of the following activities:
o Upgrading operating systems.
o Upgrading applications.
o Monitoring network performance, processes and usage.
o Troubleshooting networking issues.
b. Select internet infrastructure based on business and end-user
requirements with budget

What is Internet Infrastructure?

All the hardware and services required to make a web page appear in your browser. Internet
infrastructure is a collective term for all hardware and software systems that constitute essential
components in the operation of the Internet. Physical transmission lines of all types, such as
wired, fiber optic and microwave links, along with routing equipment, the accompanying critical
software services like the Domain Name System (DNS), Email, website hosting, authentication
and authorization, storage systems, and database servers are considered critical Internet
components
Internet Infrastructure consisting of:

1. Data Centre

AData Centre is basically a specialist building that has the ability to power (and cool) massive
amounts of computer equipment. Typically a Data Centre would also have a very large amount
of network bandwidth to accommodate data transfer in and out of it.

A data center is a centralized repository computer facility used to house computer systems and
associated components, such as telecommunications and storage systems. It generally includes
redundant or backup power supplies, redundant data communications connections,
environmental controls (e.g., air conditioning, fire extinguisher) and security devices

2. Network
• Most important foundation block of Internet Infrastructure is the Network. Without a
network connection no data can pass between Data Centers, over the Internet, and
3. Internet Service Provider (ISP)
• Choosing the proper bandwidth and network connection (cable) is critical to the site's
web presence.
• The router and the communications interface (cable, modem, bridge or other device) and
the cables that connect them form the bridge from the Web server to the outside world.
Most of this equipment will be provided by the Internet Service Provider, but as the site
 grows more equipment such as switches, hubs, patch panels, wiring and firewalls will be
needed
4. Computer Equipment
Computer equipment refers to any or all of the many different parts of a computer, as well as
peripheral devices such as printers, external hard drives and servers. Basically, anything relating
to a computer is considered computer equipment.

5. Storage Services

Data Storage is a huge part of Internet Infrastructure. All those emails accessible online, all the
web pages on your favorite web site, all those photos on Face book … are all stored on a hard
drive in a DC somewhere. The basic level of storage is on-server storage, which means the hard
drives in the computer server.

6. Server Applications

The final piece of underlying Internet Infrastructure is the server applications themselves. In
order for a web application to be delivered from a server, that server requires
1. Operating System (typically Windows or Linux),
2. Web Server application (like Apache or Microsoft IIS), and
3. Database (such as MySQL, MS-SQL or Oracle).
There any many more variations here, but the basic web server has these 3 things. From here you
can install blog software, an ecommerce site, your new web 2.0 application, or any Internet
capable piece of software (more include – Instant Messaging Server, File Storage Server,
Message Board)
7. Internet security
Management Controls:
Focus on security policies, planning, guidelines, and standards that influence the selection of
operational and technical controls to protect the organization
 Security policy
- A high level management document that describes the management’s expectation
of the employees’ security practice and responsibilities.
- It sets a clear direction and demonstrates the management’s support for and
commitment to information security.
 Background checking of employees
 Training/awareness
 Physical and environmental protection

Technical Controls:
Involve the correct use of hardware and software security capabilities in systems. This range
from simple to complex measures that work together to secure critical and sensitive assets of the
organization.
 Login
 Encryption
 Authentication protocol
 Access control
 Firewall/proxy server
 Intrusion detection system
  etc

Operational Controls:
Address the correct implementation and use of security policies and standards, ensuring
consistency in security operations and correcting identified operational deficiencies. These
controls relate to mechanisms and procedures that are primarily implemented by people rather
than systems
 Backup/Restore
 Monitor audit trials
 Account/privilege management
 Monitoring and adjusting firewall
 Media disposal
 Patching
Overview
Requirement is a carful assessment of the needs that a system is to fulfill. It must say Why, a
system is needed, based on current and foreseen condition, which may be internal operations or
external market. It must say what system features will serve and satisfy this context. And it must
say how the system is to be constructed.

Why:
Enterprise requirements
Context analysis: the reason why the system to be created. Constraints on the environment in
which the system is to function
What:
Functional requirements (system)
A description of what the system is to do. What information needs to be maintained? What needs
to be processes?
Functional requirements capture the intended behavior of the system. This behavior may be
expressed as services, tasks or functions the system is required to perform.
How:
Non-functional requirements (system)
How the system is to be constructed and function.
The requirements documents are comprehensive; detailing what is required of an installation to
meet the business needs of users. Such a document can run to considerable length and would
normally be prepared by an IT analyst or project manager. The author of the functional
specification should be able to speak the language of both business and IT.
The functional requirements documents are the ‘blueprint’ for the project implementation.
Anything missed will appear at the end, and just as when building a house, if the plumbing
design is wrong then it will be expensive and time consuming to correct.
Often one of the first steps in large projects is to devise a functional specification, also known
as the functional requirements specification (FRS). After this, a technical specification can be
produced.
Requirements issues
When selecting and employing software and hardware tools, one of the first and most important
activities to embark on is identifying what the client wants and to ensure they sign-off on the
requirements. This may sound easy, but in many cases it is not.
For example, how can a client (who often has limited knowledge of IT architecture) indicate
what they want if they have not seen a working prototype to assess?
In many cases, inexperienced clients advise the developer on what they want, when they may not
really understand what is achievable technically. This issue can also be made more complex if
the process occurs in an organisation that has rigid IT policies, which can raise numerous
compatibility issues.
In addition, this is made even further complicated if you are in a situation where you are trying to
win a contract or compete for work. Others (e.g. competitors) may have promised the
unachievable and given an impression that ‘anything is possible’. If you are awarded the work or
win the contract, you may now be expected to deliver the impossible. An open and honest
assessment of what will be delivered is essential.
So, one of the tasks is to document the requirements.
This may include identifying or clarifying:
• the business case
• what the client considers the project’s main objectives are
• what IT infrastructure is already in place
• basic specifications (eg formats)
• conflicting or overlapping requirements
• maintenance and backup requirements
• bandwidth issues that may affect the project
• role definition of parties involved
• the nature of the data (eg banking details, multimedia)
• security needs (eg if the client needs logins, passwords, lockable sections, etc)
• available support resources
• Costing.

c. Evaluate internet service performance and confirm of

business and end users requirement s

Needs analysis
Various techniques can be used to define and refine the project needs, such as interviews
with the client, online JavaScript surveys/forms, user discussion groups and questionnaires
with samples of the target audience. A very important purpose of this analysis is to develop
an understanding of what is achievable within the project resources of skills, funds and time.
The process of needs analysis may result in a separate needs report, especially on large
projects. On smaller projects, the needs analysis and the information gathered can often be
documented with the proposed solution in the one document: the scope document. This
provides information on which design decisions will be based in the next stages of
development.
For most IT applications including multimedia, the needs analysis will need to focus on three
perspectives:
1 Business perspective: An outline of the current business climate, structure of company
and the emerging industry issues that are driving the project.
2 Technical perspective: An outline of existing IT systems/infrastructure of the company
including computer hardware specifications, numbers and locations, details on browsers,
operating systems, servers, security policies, networks, bandwidth capacity and so on.
3 Human perspective: An outline of the motivation of staff to use new IT systems. It may
also cover such considerations as PC literacy, industrial relations issues for staff, legalities
and even language issues for users.
 A common criticism over the last decade is that IT developers have focused too heavily on
the technology and not enough on the users’ needs or the long-term business goals. By giving
adequate attention to these different perspectives, you are likely to end up with a solution that
addresses the client’s real needs.
Scope documentation
The aim of the scope document is to identify, control and justify the proposed solution.
Typically, the project manager/developer will normally prepare the document after consultation
with the client and the project team. It should contain most, if not all, of the information that will
form the project contract. Data gathered in the needs analysis can also be included here.
The first draft of the scope document is rarely fully mutually agreed upon. There are usually
numerous negotiations to refine the specifications of the deliverables. These will, of course,
impact on the budget and schedule of the project.
The final scope document should clearly specify the milestones and sign-off points, including
possible points and conditions for revisions to the budget and schedules. A timeframe should be
included in the document, but a full timeline that has agreed delivery dates may not necessarily
be part of the document at this stage. (This depends on the size and complexity of the project).
As part of the scope, there must be clear agreement on issues such as reporting, documentation,
evaluation, testing and delivery requirements. This defines, in quantitative terms, how the client
and the developer/implementer will work together and how, through the process of sign-offs, a
mutual end agreement will be reached. This means that in the end the appropriate product has
been built in the agreed way and via the agreed strategies outlined in the scope document.
The approval of the contract generally involves representatives signing a specified agreement on
the last page of the scope document. Any variations to this agreement will also have to be
approved by authorised representatives of the client and development team.
As you can imagine, once hardware is approved, ordered and functioning it is very difficult for
the client to then request anything else. At this stage, many thousands of dollars in hardware and
software, not to mention IT specialist wages, may have been allocated. The basic plan must be
right at the start!
Throughout the project, the client and the development team must have a strategy in place to
inform each other of any event that may impact on successful progress and timely completion of
the project. The strategy again must be outlined in the scope document.

d. Internet infrastructure requirements of hardware, software,

network and security
Functional requirements specification:
The functional specification describes what the system will do, as opposed to how it will be
done. This distinction is important, because:
• the client may not be interested in the details of how a function is implemented, and the
technical details may simply cause confusion for the client
• the implementation details may need to change during the design and development of the
project
• you don’t want to have to negotiate changes to the functional specification just to change
details of implementation
• the technical specification for large projects will be detailed in a separate document, and
you should not entangle one with the other.
The language of the functional specification should be clear, concise and (as far as possible) non-
technical. It is very important to attend to details in the functional specification. One misplaced
word may commit a vendor company to develop extra functionality that was never intended, and
damage the profitability of the project.
Fixed requirements
Some requirements are fixed, and not derived from the ideal functionality that the product or
system should possess. These are often in the form of constraints set by the client. For example:
• A client may require a particular look-and-feel to their website.
• The client may require your system to interface to their existing systems in a particular
way.
Use cases
A use case is a list of steps, typically defining interactions between a role and a system, to
achieve a goal. The actor can be a human or an external system.
A use case is a very useful tool to help you start to determine the required functionality of a
system. Use cases have quickly become a standard tool for capturing functional requirements.
A use case is a diagram showing how the proposed system will be used in one particular
scenario, by a particular user. Use cases allow the designer to focus on details, but keep the
design grounded in the basics of how the system will be used. A large system will have many use
cases.

Examples of functional requirements

Functional requirements describe the way in which the different components and functions in the
solution will interact. They will clarify how the solution is going to work and how users can use
it.
Next are some examples of the questions you might ask in order to determine the functional
requirements of an IT system.
User requirements
• How many users are expected to use the system?
• How many people will be utilising the solution at one time?
• Where the users will be located (eg overseas, interstate or at home)?
• What navigation model will it use?
• What is the range of the content?
 • How much content will it include?
• How will the content be structured?

Technical requirements
• What types of computers/operating systems will the users operate?
• Are their desktops all the same?
• What bandwidth restrictions occur presently?
• What security (login) will they need?
• What backup policies need to be in place?
• Who will have administration rights?
• What will the business do if the system fails at any stage?
• Who is the project sponsor?
• What does management expect the system will do and won’t do?
Hardware requirements
• Compatibility: will the solution work with existing systems?
• Support for multimedia formats: will the existing systems and architecture support all
types of media?
• Will the new system be supported by existing resources within the company?
• Is there funding available for new hardware? (eg new servers)
• What is the backup strategy? Has this been costed?
• Does the system need to be copied?
• Will there be time delays to purchase and install hardware?
• Will you be relying on another group to set up the hardware? If they don’t consider your
project a priority, is that time delay factored into the delivery strategy?
• Are there other projects that you may be able to share hardware costs with?
• If the system needs to cater for multimedia, does there need to be extra attention paid to
being able to store and transmit large graphic, sound and video files?
• If you are a consultant or part time employee, will you be given permissions and rights to
install and support the system fully? (As some computer centres are secure).
Software requirements
• What is the true cost of the software?
• Are there licensing issues? (As the system is in development, should you pay for all the
licensing now, or when the system is in live mode?)
• Can the software be licensed for use by multiple users who use it on different machines?
(Concurrent licensing)
• How long has the software been on the market for?
• What happens if the software company becomes insolvent? Who supports it?
• Who owns the source code?
• What happens if the source code is modified; who supports the product then?
• Does the solution work with all other company software systems?
• If web-based, does the solution function on all common browsers?
• If security is a concern, can the software be delivered in a ‘locked down’ format?
• Does the software support all file formats? (This is especially important when working on
multimedia tasks.)
• Is the software easy to use or are there major training issues/costs?
 Support materials
You will need to consider the content and design requirements of all support materials. Support
materials could include:
• system specifications
• user guides
• knowledge banks
• intranet/Internet help sites/CD-ROMs
• training manuals
• General user documentation and print-based help.
You will also need to consider workshops, seminars or briefings you may need to run in order to
support the software/hardware/system.
During the development of the scope document you will have determined the kinds of support
materials that you will need. You will probably also establish who will be responsible for the
production of those materials.
Handover training is another important and time-consuming task. If a developer (who is a
specialist in the area) works on a project for, say, six months, how long will it take to train a
support officer to support the system? One day? One week? One month?
In conclusion, the project manager will generally be responsible for coordinating the
development of the support materials in parallel with the development of the package.

e. Determine internet protocol address allocation

IP versions
Two versions of the Internet Protocol (IP) are in use: IP Version 4 and IP Version 6. Each version defines
an IP address differently. Because of its prevalence, the generic term IP address typically still refers to
the addresses defined by IPv4. The gap in version sequence between IPv4 and IPv6 resulted from the
assignment of number 5 to the experimental Internet Stream Protocol in 1979, which however was never
referred to as IPv5.
Internet Protocol version 4 (IPv4) is the fourth version in the development of the Internet
Protocol (IP) Internet, and routes most traffic on the Internet. However, a successor protocol,
IPv6, has been defined and is in various stages of production deployment. IPv4 is described in
IETF publication, replacing an earlier definition.
IPv4 is a connectionless protocol for use on packet-switched networks. It operates on a best
effort delivery model; in that it does not guarantee delivery, nor does it assure proper sequencing
or avoidance of duplicate delivery. These aspects, including data integrity, are addressed by an
upper layer transport protocol, such as the Transmission Control Protocol (TCP).

Addressing
IPv4 uses 32-bit (four-byte) addresses, which limits the address space to 4294967296 (232)
addresses. As addresses were assigned to users, the number of unassigned addresses decreased.
IPv4 address exhaustion occurred on February 3, 2011, although it had been significantly
delayed by address changes such as class-full network design, Classless Inter-Domain Routing,
and network address translation (NAT).
This limitation of IPv4 stimulated the development of IPv6 in the 1990s, which has been in
commercial deployment since 2006.
IPv4 reserves special address blocks for private networks (~18 million addresses) and multicast
addresses (~270 million addresses).

Address representations

IPv4 addresses may be written in any notation expressing a 32-bit integer value, but for human
convenience, they are most often written in the dot-decimal notation, which consists of four
octets of the address expressed individually in decimal and separated by periods.
An IP address followed by a slash (/) and a number (i.e. 127.0.0.1/8) indicates a block of
addresses using a subnet mask. See CIDR notation.
The following table shows several representation formats:

Notation Value Conversion from dot-decimal

Dotted decimal 192.0.2.235 N/A
Dotted Each octet, preceded by 0x, is individually converted to
0xC0.0x00.0x02.0xEB
hexadecimal hexadecimal form.
Dotted octal 0300.0000.0002.0353 Each octet, preceded by 0, is individually converted into octal.
The 32-bit number is expressed as the concatenation of the
Hexadecimal 0xC00002EB
octets from the dotted hexadecimal.
Decimal 3221226219 The 32-bit number is expressed in decimal.
Octal 030000001353 The 32-bit number is expressed in octal.

Mixing decimal, octal and hexadecimal is allowed in dotted format per octet.
Note that in non-dotted formats, numbers bigger than 32-bit, can be given in some cases (e.g.
Firefox) and will get converted mod 232.

Allocation

Originally, an IP address was divided into two parts: the network identifier was the most
significant (highest order) octet of the address, and the host identifier was the rest of the address.
The latter was therefore also called the rest field. This enabled the creation of a maximum of 256
networks. This was quickly found to be inadequate.
To overcome this limit, the high order octet of the addresses was redefined to create a set of
classes of networks, in a system which later became known as classful networking. The system
defined five classes, Class A, B, C, D, and E. The Classes A, B, and C had different bit lengths
for the new network identification. The rest of an address was used as previously to identify a
host within a network, which meant that each network class had a different capacity to address
hosts. Class D was allocated for multicast addressing and Class E was reserved for future
applications.
Starting around 1985, methods were devised to subdivide IP networks. One method that has
proved flexible is the use of the variable-length subnet mask (VLSM).

Special-use addresses
Reserved IP addresses § Reserved IPv4 addresses

Range Description
 0.0.0.0/8 Current network (only valid as source address)
10.0.0.0/8 Private network
100.64.0.0/10 Shared Address Space
127.0.0.0/8 Loopback
169.254.0.0/16 Link-local
172.16.0.0/12 Private network
192.0.0.0/24 IETF Protocol Assignments
192.0.2.0/24 TEST-NET-1, documentation and examples
192.88.99.0/24 IPv6 to IPv4 relay
192.168.0.0/16 Private network
198.18.0.0/15 Network benchmark tests
198.51.100.0/24 TEST-NET-2, documentation and examples
203.0.113.0/24 TEST-NET-3, documentation and examples
224.0.0.0/4 IP multicast (former Class D network)
240.0.0.0/4 Reserved (former Class E network)
255.255.255.255 Broadcast

Private networks

Of the approximately four billion addresses allowed in IPv4, three ranges of address are reserved
for use in private networks. These ranges are not routable outside of private networks, and
private machines cannot directly communicate with public networks. They can, however, do so
through network address translation.
The following are the three ranges reserved for private networks:

Number of Largest CIDR

Name Address range Classful description
addresses block
24-bit
10.0.0.0–10.255.255.255 16777216 Single Class A 10.0.0.0/8
block
20-bit 172.16.0.0– Contiguous range of 16 Class
1048576 172.16.0.0/12
block 172.31.255.255 B blocks
16-bit 192.168.0.0– Contiguous range of 256
65536 192.168.0.0/16
block 192.168.255.255 Class C blocks

Virtual private networks

Packets with a private destination address are ignored by all public routers. Two private
networks (e.g., two branch offices) cannot communicate via the public internet, unless they use
an IP tunnel or a virtual private network (VPN). When one private network wants to send a
packet to another private network, the first private network encapsulates the packet in a protocol
layer so that the packet can travel through the public network. Then the packet travels through
the public network. When the packet reaches the other private network, its protocol layer is
removed, and the packet travels to its destination.
Optionally, encapsulated packets may be encrypted to secure the data while it travels over the
public network.

Link-local addressing

Defines the special address block 169.254.0.0/16 for link-local addressing. These addresses are
only valid on links (such as a local network segment or point-to-point connection) connected to a
host. These addresses are not routable. Like private addresses, these addresses cannot be the
source or destination of packets traversing the internet. These addresses are primarily used for
address autoconfiguration (Zeroconf) when a host cannot obtain an IP address from a DHCP
server or other internal configuration methods.
When the address block was reserved, no standards existed for address autoconfiguration.
Microsoft created an implementation called Automatic Private IP Addressing (APIPA), which
was deployed on millions of machines and became a de facto standard.

Loopback

The class A network 127.0.0.0 (classless network 127.0.0.0/8) is reserved for loopback. IP
packets whose source addresses belong to this network should never appear outside a host. The
modus operandi of this network expands upon that of a loopback interface:

• IP packets whose source and destination addresses belong to the network (or subnetwork) of the
same loopback interface are returned to that interface;
• IP packets whose source and destination addresses belong to networks (or subnetworks) of
different interfaces of the same host, one of them being a loopback interface, are forwarded
regularly.

Addresses ending in 0 or 255

IPv4 subnetting reference

Networks with subnet masks of at least 24 bits, i.e. Class C networks in classful networking, and
networks with CIDR suffixes /24 to /32 (255.255.255.0–255.255.255.255) may not have an
address ending in 0 or 255.
Classful addressing prescribed only three possible subnet masks: Class A, 255.0.0.0 or /8; Class
B, 255.255.0.0 or /16; and Class C, 255.255.255.0 or /24. For example, in the subnet
192.168.5.0/255.255.255.0 (192.168.5.0/24) the identifier 192.168.5.0 commonly is used to refer
to the entire subnet. To avoid ambiguity in representation, the address ending in the octet 0 is
reserved.
A broadcast address is an address that allows information to be sent to all interfaces in a given
subnet, rather than a specific machine. Generally, the broadcast address is found by obtaining the
bit complement of the subnet mask and performing a bitwise OR operation with the network
identifier. In other words, the broadcast address is the last address in the address range of the
subnet. For example, the broadcast address for the network 192.168.5.0 is 192.168.5.255. For
networks of size /24 or larger, the broadcast address always ends in 255.
However, this does not mean that every address ending in 0 or 255 cannot be used as a host
address. For example, in the /16 subnet 192.168.0.0/255.255.0.0, which is equivalent to the
address range 192.168.0.0–192.168.255.255, the broadcast address is 192.168.255.255. One can
use the following addresses for hosts, even though they end with 255: 192.168.1.255,
192.168.2.255, etc. Also, 192.168.0.0 is the network identifier and must not be assigned to an
interface. The addresses 192.168.1.0, 192.168.2.0, etc., may be assigned, despite ending with 0.
In the past, conflict between network addresses and broadcast addresses arose because some
software used non-standard broadcast addresses with zeros instead of ones.In networks smaller
than /24, broadcast addresses do not necessarily end with 255. For example, a CIDR subnet
203.0.113.16/28 has the broadcast address 203.0.113.31.

Address resolution

Domain Name System

Hosts on the Internet are usually known by names, e.g., www.example.com, not primarily by
their IP address, which is used for routing and network interface identification. The use of
domain names requires translating, called resolving, them to addresses and vice versa. This is
analogous to looking up a phone number in a phone book using the recipient's name.
The translation between addresses and domain names is performed by the Domain Name System
(DNS), a hierarchical, distributed naming system which allows for sub delegation of name
spaces to other DNS servers.

Address space exhaustion

IPv4 address exhaustion

Since the 1980s, it was apparent that the pool of available IPv4 addresses was being depleted at a
rate that was not initially anticipated in the original design of the network address system.The
threat of exhaustion was the motivation for remedial technologies, such as classful networks,
Classless Inter-Domain Routing (CIDR) methods, and network address translation (NAT).
Eventually, IPv6 was created, which has many more addresses available.
Several market forces accelerated IPv4 address exhaustion:

• Rapidly growing number of Internet users

• Always-on devices — ADSL modems, cable modems
• Mobile devices — laptop computers, PDAs, mobile phones

Some technologies mitigated IPv4 address exhaustion:

• Network address translation (NAT) is a technology that allows a private network to use one
public IP address. It permits private addresses in the private network.
• Use of private networks
• Dynamic Host Configuration Protocol (DHCP)
• Name-based virtual hosting of web sites
• Tighter control by regional Internet registries over the allocation of addresses to local Internet
registries
• Network renumbering to reclaim large blocks of address space allocated in the early days of the
Internet

Packet structure
Header

The IPv4 packet header consists of 14 fields, of which 13 are required. The 14th field is optional
(red background in table) and aptly named: options. The fields in the header are packed with the
most significant byte first (big endian), and for the diagram and discussion, the most significant
bits are considered to come first (MSB 0 bit numbering). The most significant bit is numbered 0,
so the version field is actually found in the four most significant bits of the first byte, for
example.

IPv4 Header Format

Offsets Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Version IHL DSCP ECN Total Length
4 32 Identification Flags Fragment Offset
8 64 Time To Live Protocol Header Checksum
12 96 Source IP Address
16 128 Destination IP Address
20 160 Options (if IHL > 5)
Version
The first header field in an IP packet is the four-bit version field. For IPv4, this has a value of 4
(hence the name IPv4).
Internet Header Length (IHL)
The second field (4 bits) is the Internet Header Length (IHL), which is the number of 32-bit
words in the header. Since an IPv4 header may contain a variable number of options, this field
specifies the size of the header (this also coincides with the offset to the data). The minimum
value for this field is 5, which is a length of 5×32 = 160 bits = 20 bytes. Being a 4-bit value, the
maximum length is 15 words (15×32 bits) or 480 bits = 60 bytes.
Total Length

This 16-bit field defines the entire packet (fragment) size, including header and data, in bytes.
The minimum-length packet is 20 bytes (20-byte header + 0 bytes data) and the maximum is
65,535 bytes — the maximum value of a 16-bit word. All hosts are required to be able to
reassemble datagrams of size up to 576 bytes, but most modern hosts handle much larger
packets. Sometimes subnet works impose further restrictions on the packet size, in which case
datagrams must be fragmented. Fragmentation is handled in either the host or router in IPv4.

Identification

This field is an identification field and is primarily used for uniquely identifying the group of
fragments of a single IP datagram. Some experimental work has suggested using the ID field for
other purposes, such as for adding packet-tracing information to help trace datagrams with
spoofed source addresses.

Flags

A three-bit field follows and is used to control or identify fragments. They are (in order, from
high order to low order):
 • bit 0: Reserved; must be zero.
• bit 1: Don't Fragment (DF)
• bit 2: More Fragments (MF)

If the DF flag is set, and fragmentation is required to route the packet, then the packet is dropped.
This can be used when sending packets to a host that does not have sufficient resources to handle
fragmentation. It can also be used for Path MTU Discovery, either automatically by the host IP
software, or manually using diagnostic tools such as ping or traceroute. For unfragmented
packets, the MF flag is cleared. For fragmented packets, all fragments except the last have the
MF flag set. The last fragment has a non-zero Fragment Offset field, differentiating it from an
unfragmented packet.

Fragment Offset

The fragment offset field, measured in units of eight-byte blocks (64 bits), is 13 bits long and
specifies the offset of a particular fragment relative to the beginning of the original unfragmented
IP datagram. The first fragment has an offset of zero. This allows a maximum offset of (213 – 1)
× 8 = 65,528 bytes, which would exceed the maximum IP packet length of 65,535 bytes with the
header length included (65,528 + 20 = 65,548 bytes).

Time To Live (TTL)

An eight-bit time to live field helps prevent datagrams from persisting (e.g. going in circles) on
an internet. This field limits a datagram's lifetime. It is specified in seconds, but time intervals
less than 1 second are rounded up to 1. In practice, the field has become a hop count—when the
datagram arrives at a router, the router decrements the TTL field by one. When the TTL field hits
zero, the router discards the packet and typically sends an ICMP Time Exceeded message to the
sender.
The program traceroute uses these ICMP Time Exceeded messages to print the routers used by
packets to go from the source to the destination.

Protocol

This field defines the protocol used in the data portion of the IP datagram. The Internet Assigned
Numbers Authority maintains a list of IP protocol numbers which was originally.

Data

The data portion of the packet is not included in the packet checksum. Its contents are interpreted
based on the value of the Protocol header field.
Some of the common protocols for the data portion are listed below:

Protocol Number Protocol Name Abbreviation

1 Internet Control Message Protocol ICMP
2 Internet Group Management Protocol IGMP
6 Transmission Control Protocol TCP
17 User Datagram Protocol UDP
41 IPv6 encapsulation ENCAP
89 Open Shortest Path First OSPF
132 Stream Control Transmission Protocol SCTP

Fragmentation and reassembly

The Internet Protocol enables networks to communicate with one another. The design
accommodates networks of diverse physical nature; it is independent of the underlying
transmission technology used in the Link Layer. Networks with different hardware usually vary
not only in transmission speed, but also in the maximum transmission unit (MTU). When one
network wants to transmit datagrams to a network with a smaller MTU, it may fragment its
datagrams. In IPv4, this function was placed at the Internet Layer, and is performed in IPv4
routers, which thus only require this layer as the highest one implemented in their design.
In contrast, IPv6, the next generation of the Internet Protocol, does not allow routers to perform
fragmentation; hosts must determine the path MTU before sending datagrams.

Fragmentation

When a router receives a packet, it examines the destination address and determines the outgoing
interface to use and that interface's MTU. If the packet size is bigger than the MTU, and the Do
not Fragment (DF) bit in the packet's header set to 0; the router may fragment the packet.
The router divides the packet into segments. The max size of each segment is the MTU minus
the IP header size (20 bytes minimum; 60 bytes maximum). The router puts each segment into its
own packet, each fragment packet having following changes:

• The total length field is the segment size.

• The more fragments (MF) flag is set for all segments except the last one, which is set to 0.
• The fragment offset field is set, based on the offset of the segment in the original data payload.
This is measured in units of eight-byte blocks.
• The header checksum field is recomputed.

For example, for an MTU of 1,500 bytes and a header size of 20 bytes, the fragment offsets
would be multiples of (1500–20)/8 = 185. These multiples are 0, 185, 370, 555, 740, ...
It is possible for a packet to be fragmented at one router, and for the fragments to be fragmented
at another router. For example, consider a packet with a data size of 4,500 bytes, no options, and
a header size of 20 bytes. So the packet size is 4,520 bytes. Assume that the packet travels over a
link with an MTU of 2,500 bytes. Then it will become two fragments:

Total Header Data "More fragments" Fragment offset (8-byte

Fragment
bytes bytes bytes flag blocks)
1 2500 20 2480 1 0
2 2040 20 2020 0 310

Note that the fragments preserve the data size: 2480 + 2020 = 4500.
Note how we get the offsets from the data sizes:

• 0.
 • 0 + 2480/8 = 310.

Assume that these fragments reach a link with an MTU of 1,500 bytes. Each fragment will
become two fragments:

Total Header Data "More fragments" Fragment offset (8-byte

Fragment
bytes bytes bytes flag blocks)
1 1500 20 1480 1 0
2 1020 20 1000 1 185
3 1500 20 1480 1 310
4 560 20 540 0 495

Note that the fragments preserve the data size: 1480 + 1000 = 2480, and 1480 + 540 = 2020.
Note how we get the offsets from the data sizes:

• 0.
• 0 + 1480/8 = 185
• 185 + 1000/8 = 310
• 310 + 1480/8 = 495

We can use the last offset and last data size to calculate the total data size: 495*8 + 540 = 3960 +
540 = 4500.