What Is IP Routing?

More information:
Metaswitch provides a range of high function, portable IP routing software products
IP Routing is an umbrella term for the set of protocols that determine the path that data follows in
order to travel across multiple networks from its source to its destination. Data is routed from its
source to its destination through a series of routers, and across multiple networks. The IP Routing
protocols enable routers to build up a forwarding table that correlates final destinations with next
hop addresses.
These protocols include:
• BGP (Border Gateway Protocol)
• IS-IS (Intermediate System - Intermediate System)
• OSPF (Open Shortest Path First)
• RIP (Routing Information Protocol)
When an IP packet is to be forwarded, a router uses its forwarding table to determine the next hop
for the packet's destination (based on the destination IP address in the IP packet header), and
forwards the packet appropriately. The next router then repeats this process using its own
forwarding table, and so on until the packet reaches its destination. At each stage, the IP address in
the packet header is sufficient information to determine the next hop; no additional protocol headers
are required.
The Internet, for the purpose of routing, is divided into Autonomous Systems (ASs). An AS is a
group of routers that are under the control of a single administration and exchange routing
information using a common routing protocol. For example, a corporate intranet or an ISP network
can usually be regarded as an individual AS. The Internet can be visualized as a partial mesh of
ASs. An AS can be classified as one of the following three types.
• A Stub AS has a single connection to one other AS. Any data sent to, or received from, a
destination outside the AS must travel over that connection. A small campus network is an
example of a stub AS.
• A Transit AS has multiple connections to one or more ASs, which permits data that is not
destined for a node within that AS to travel through it. An ISP network is an example of a
transit AS.
• A Multihomed AS also has multiple connections to one or more ASs, but it does not permit
data received over one of these connections to be forwarded out of the AS again. In other
words, it does not provide a transit service to other ASs. A Multihomed AS is similar to a
Stub AS, except that the ingress and egress points for data traveling to or from the AS can be
chosen from one of a number of connections, depending on which connection offers the
shortest route to the eventual destination. A large enterprise network would normally be a
multihomed AS.
An Interior Gateway Protocol (IGP) calculates routes within a single AS. The IGP enables nodes
on different networks within an AS to send data to one another. The IGP also enables data to be
forwarded across an AS from ingress to egress, when the AS is providing transit services.
Routes are distributed between ASs by an Exterior Gateway Protocol (EGP). The EGP enables
routers within an AS to choose the best point of egress from the AS for the data they are trying to
route.
The EGP and the IGPs running within each AS cooperate to route data across the Internet. The EGP
determines the ASs that data must cross in order to reach its destination, and the IGP determines the
path within each AS that data must follow to get from the point of ingress (or the point of origin) to
the point of egress (or the final destination).
The diagram below illustrates the different types of AS in a network. OSPF, IS-IS and RIP are IGPs
used within the individual ASs; BGP is the EGP used between ASs.
The Dynamic Host Configuration Protocol (DHCP) is a computer networking protocol used by
hosts (DHCP clients) to retrieve IP address assignments and other configuration information.
DHCP uses a client-server architecture. The client sends a broadcast request for configuration
information. The DHCP server receives the request and responds with configuration information
from its configuration database.
In the absence of DHCP, all hosts on a network must be manually configured individually - a time-
consuming and often error-prone undertaking.
DHCP is popular with ISP's because it allows a host to obtain a temporary IP address.
Contents
• [hide]1
Historie
s
• 2
Technic
al
overvie
w
• 3
Technic
al
details
• 3
.
1

D
H
C
P

d
i
s
c
o
v
e
r
y

• 3
.
2

D
H
C
P

o
f
f
e
r

• 3
.
3
[edit] Histories
RFC 1531 initially defined DHCP as a standard-track protocol in October 1993, succeeding the
Bootstrap Protocol (BOOTP). The next update, RFC 2131 released in 1997 is the current DHCP
definition for Internet Protocol version 4 (IPv4) networks. The extensions of DHCP for IPv6
(DHCPv6) were published as RFC 3315.
Before BOOTP and DHCP, there was another protocol used to discover a host's network address.
The protocol was RARP (Reverse Address Resolution Protocol) RFC 906, published June 1984.
RARP, BOOTP, and DHCP provide a way to request a network layer address for a host.

[edit] Technical overview

Dynamic Host Configuration Protocol automates network-parameter assignment to network devices
from one or more DHCP servers. Even in small networks, DHCP is useful because it can make it
easy to add new machines to the network.
When a DHCP-configured client (a computer or any other network-aware device) connects to a
network, the DHCP client sends a broadcast query requesting necessary information from a DHCP
server. The DHCP server manages a pool of IP addresses and information about client configuration
parameters such as default gateway, domain name, the name servers, other servers such as time
servers, and so forth. On receiving a valid request, the server assigns the computer an IP address, a
lease (length of time the allocation is valid), and other IP configuration parameters, such as the
subnet mask and the default gateway. The query is typically initiated immediately after booting, and
must complete before the client can initiate IP-based communication with other hosts.
Depending on implementation, the DHCP server may have three methods of allocating IP-
addresses:
• dynamic allocation: A network administrator assigns a range of IP addresses to DHCP, and
each client computer on the LAN has its IP software configured to request an IP address
from the DHCP server during network initialization. The request-and-grant process uses a
lease concept with a controllable time period, allowing the DHCP server to reclaim (and
then reallocate) IP addresses that are not renewed (dynamic re-use of IP addresses).
• automatic allocation: The DHCP server permanently assigns a free IP address to a
requesting client from the range defined by the administrator. This is like dynamic
allocation, but the DHCP server keeps a table of past IP address assignments, so that it can
preferentially assign to a client the same IP address that the client previously had.
• static allocation: The DHCP server allocates an IP address based on a table with MAC
address/IP address pairs, which are manually filled in (perhaps by a network administrator).
Only requesting clients with a MAC address listed in this table will be allocated an IP
address. This feature (which is not supported by all devices) is variously called Static DHCP
Assignment (by DD-WRT), fixed-address (by the dhcpd documentation), DHCP reservation
or Static DHCP (by Cisco/Linksys), and IP reservation or MAC/IP binding (by various
other router manufacturers).

[edit] Technical details

DHCP uses the same two ports assigned by IANA for BOOTP: 67/udp for sending data to the
server, and 68/udp for data to the client.
DHCP operations fall into four basic phases: IP discovery, IP lease offer, IP request, and IP lease
acknowledgement.
Where a DHCP client and server are on the same subnet, they will communicate via UDP
broadcasts. When the client and server are on different subnets, IP discovery and IP request
messages are sent via UDP broadcasts, but IP lease offer and IP lease acknowledgement messages
are sent via unicast.

[edit] DHCP discovery

The client broadcasts messages on the physical subnet to discover available DHCP servers.
Network administrators can configure a local router to forward DHCP packets to a DHCP server
from a different subnet. This client-implementation creates a User Datagram Protocol (UDP) packet
with the broadcast destination of 255.255.255.255 or the specific subnet broadcast address.
A DHCP client can also request its last-known IP address (in the example below, 192.168.1.100). If
the client remains connected to a network for which this IP is valid, the server might grant the
request. Otherwise, it depends whether the server is set up as authoritative or not. An authoritative
server will deny the request, making the client ask for a new IP address immediately. A non-
authoritative server simply ignores the request, leading to an implementation-dependent timeout for
the client to give up on the request and ask for a new IP address.

[edit] DHCP offer

When a DHCP server receives an IP lease request from a client, it reserves an IP address for the
client and extends an IP lease offer by sending a DHCPOFFER message to the client. This message
contains the client's MAC address, the IP address that the server is offering, the subnet mask, the
lease duration, and the IP address of the DHCP server making the offer.
The server determines the configuration based on the client's hardware address as specified in the
CHADDR (Client Hardware Address) field. Here the server, 192.168.1.1, specifies the IP address in
the YIADDR (Your IP Address) field.

[edit] DHCP request

A client can receive DHCP offers from multiple servers, but it will accept only one DHCP offer and
broadcast a DHCP request message. Based on the Transaction ID field in the request, servers are
informed whose offer the client has accepted. When other DHCP servers receive this message, they
withdraw any offers that they might have made to the client and return the offered address to the
pool of available addresses. The DHCP request message is broadcast, instead of being unicast to a
particular DHCP server, because the DHCP client has still not received an IP address. Also, this
way one message can let all other DHCP servers know that another server will be supplying the IP
address without missing any of the servers with a series of unicast messages.

[edit] DHCP acknowledgement

When the DHCP server receives the DHCPREQUEST message from the client, the configuration
process enters its final phase. The acknowledgement phase involves sending a DHCPACK packet to
the client. This packet includes the lease duration and any other configuration information that the
client might have requested. At this point, the IP configuration process is completed.
The protocol expects the DHCP client to configure its network interface with the negotiated
parameters.
 DHCPDISCOVER DHCPREQUEST DHCPACK
UDP Src=0.0.0.0 sPort=68 UDP Src=0.0.0.0 sPort=68 UDP Src=192.168.1.1 sPort=67
Dest=255.255.255.255 dPort=67 Dest=255.255.255.255 Dest=255.255.255.255
OP HTYPE HLEN HOPS dPort=67 dPort=68
0x01 0x01 0x06 0x00 OP HTYPE HLEN HOPS OP HTYPE HLEN HOPS
XID 0x01 0x01 0x06 0x00 0x02 0x01 0x06 0x00
0x3903F326 XID XID
SECS FLAGS 0x3903F326 0x3903F326
0x0000 0x0000 SECS FLAGS SECS FLAGS
CIADDR 0x0000 0x0000 0x0000 0x0000
0x00000000 CIADDR CIADDR (Client IP Address)
YIADDR 0x00000000 0x00000000
0x00000000 YIADDR YIADDR (Your IP Address)
SIADDR 0xC0A80164 0xC0A80164
0x00000000 SIADDR SIADDR (Server IP Address)
GIADDR 0xC0A80101 0xC0A80101
0x00000000 GIADDR GIADDR (Gateway IP
CHADDR 0x00000000 Address switched by relay)
0x00053C04 CHADDR 0x00000000
0x8D590000 0x00053C04 CHADDR (Client Hardware
0x8D590000 Address)
0x00000000
0x00000000 0x00053C04
0x00000000
0x00000000 0x8D590000
192 octets of 0's. BOOTP legacy
192 octets of 0's. BOOTP 0x00000000
Magic Cookie
legacy 0x00000000
0x63825363
Magic Cookie 192 octets of 0's. BOOTP
DHCP Options legacy
DHCP option 53: DHCP 0x63825363
DHCP Options Magic Cookie
Discover
DHCP option 53: DHCP 0x63825363
DHCP option 50: 192.168.1.100
requested Request DHCP Options
DHCP option 55: Parameter DHCP option 50: DHCP option 53: DHCP ACK
Request List: 192.168.1.100 requested DHCP option 1: 255.255.255.0
DHCP option 54: 192.168.1.1 subnet mask
Request Subnet Mask (1), Router DHCP server. DHCP option 3: 192.168.1.1
(3), Domain Name (15), router
DHCP option 51: 86400s (1
Domain Name Server (6) day) IP lease time
DHCPOFFER DHCP option 54: 192.168.1.1
UDP Src=192.168.1.1 DHCP server
sPort=67 DHCP option 6: DNS servers
Dest=255.255.255.255 9.7.10.15, 9.7.10.16, 9.7.10.18
dPort=68
OP HTYPE HLEN HOPS
0x02 0x01 0x06 0x00
XID
0x3903F326
 SECS FLAGS
0x0000 0x0000
CIADDR
0x00000000
YIADDR
0xC0A80164
SIADDR
0xC0A80101
GIADDR
0x00000000
CHADDR
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0's. BOOTP
legacy
Magic Cookie
0x63825363
DHCP Options
DHCP option 53: DHCP Offer
DHCP option 1: 255.255.255.0
subnet mask
DHCP option 3: 192.168.1.1
router
DHCP option 51: 86400s (1
day) IP lease time
DHCP option 54: 192.168.1.1
DHCP server
DHCP option 6: DNS servers
9.7.10.15, 9.7.10.16, 9.7.10.18
After the client obtains an IP address, the client may use the Address Resolution Protocol (ARP) to
prevent IP conflicts caused by overlapping address pools of DHCP servers.

[edit] DHCP information

A DHCP client may request more information than the server sent with the original DHCPOFFER.
The client may also request repeat data for a particular application. For example, browsers use
DHCP Inform to obtain web proxy settings via WPAD. Such queries do not cause the DHCP server
to refresh the IP expiry time in its database.

[edit] DHCP releasing

The client sends a request to the DHCP server to release the DHCP information and the client
deactivates its IP address. As client devices usually do not know when users may unplug them from
the network, the protocol does not mandate the sending of DHCP Release.
[edit] Client configuration parameters in DHCP
A DHCP server can provide optional configuration parameters to the client. RFC 2132 describes the
available DHCP options defined by Internet Assigned Numbers Authority (IANA) - DHCP and
BOOTP PARAMETERS.
A DHCP client can select, manipulate and overwrite parameters provided by a DHCP server.[1]

[edit] Options
An option exists to identify the vendor and functionality of a DHCP client. The information is a
variable-length string of characters or octets which has a meaning specified by the vendor of the
DHCP client. One method that a DHCP client can utilize to communicate to the server that it is
using a certain type of hardware or firmware is to set a value in its DHCP requests called the
Vendor Class Identifier (VCI) (Option 60). This method allows a DHCP server to differentiate
between the two kinds of client machines and process the requests from the two types of modems
appropriately. Some types of set-top boxes also set the VCI (Option 60) to inform the DHCP server
about the hardware type and functionality of the device. The value that this option is set to give the
DHCP server a hint about any required extra information that this client needs in a DHCP response.

[edit] DHCP Relaying

In small networks DHCP typically uses broadcasts. However, in some circumstances, unicast
addresses will be used, for example: when networks have a single DHCP server that provides IP
addresses for multiple subnets. When a router for such a subnet receives a DHCP broadcast, it
converts it to unicast (with a destination MAC/IP address of the configured DHCP server, source
MAC/IP of the router itself). The GIADDR field of this modified request is populated with the IP
address of the router interface on which it received the original DHCP request. The DHCP server
uses the GIADDR field to identify the subnet of the originating device in order to select an IP
address from the correct pool. The DHCP server then sends the DHCP OFFER back to the router
via unicast. The router then converts the DHCP OFFER back to a broadcast, sent out on the
interface of the original device.

[edit] Reliability
A standard for implementing fault-tolerant DHCP servers has been discussed by the Internet
Engineering Task Force,[2] but the draft standard has expired. The draft standard proposed
redundant servers, one primary and one backup. The backup server tracks the IP address allocations
made by the primary and takes over if the primary fails.

[edit] Security
This section contains close paraphrasing of one or more non-free copyrighted sources.
Ideas in this article should be expressed in an original manner. See the talk page for details.
(March 2009)
The basic DHCP protocol became a standard before network security became a significant issue: it
includes no security features, and is potentially vulnerable to two types of attacks:[3]
• Unauthorized DHCP Servers: as you cannot specify the server you want, an unauthorized
server can respond to client requests, sending client network configuration values that are
beneficial to the attacker. As an example, a hacker can hijack the DHCP process to
configure clients to use a malicious DNS server or router (see also DNS cache poisoning).
• Unauthorized DHCP Clients: By masquerading as a legitimate client, an unauthorized client
can gain access to network configuration and an IP address on a network it should otherwise
 not be allowed to use. Also, by flooding the DHCP server with requests for IP addresses, it
is possible for an attacker to exhaust the pool of available IP addresses, disrupting normal
network activity (a denial of service attack).
To combat these threats RFC 3118 ("Authentication for DHCP Messages") introduced
authentication information into DHCP messages, allowing clients and servers to reject information
from invalid sources. Although support for this protocol is widespread, a large number of clients
and servers still do not fully support authentication, thus forcing servers to support clients that do
not support this feature. As a result, other security measures are usually implemented around the
DHCP server (such as IPsec) to ensure that only authenticated clients and servers are granted access
to the network.
Addresses should be dynamically linked to a secure DNS server, to allow troubleshooting by name
rather than by a potentially unknown address.[citation needed] Effective DHCP-DNS linkage
requires having a file of either MAC addresses or local names that will be sent to DNS that
uniquely identifies physical hosts, IP addresses, and other parameters such as the default gateway,
subnet mask, and IP addresses of DNS servers from a DHCP server. The DHCP server ensures that
all IP addresses are unique, i.e., no IP address is assigned to a second client while the first client's
assignment is valid (its lease has not expired). Thus IP address pool management is done by the
server and not by a network administrator.
The Loopback Interface
The very first interface to be activated is the loopback interface:
# ifconfig lo 127.0.0.1

Occasionally, you will also see the dummy hostname localhost being used instead of the IP-address.
ifconfig will look up the name in the hosts file where an entry should declare it as the hostname for
127.0.0.1:
# Sample /etc/hosts entry for localhost
localhost 127.0.0.1

To view the configuration of an interface, you invoke ifconfig giving it the interface name as
argument:
$ ifconfig lo
lo Link encap Local Loopback
inet addr 127.0.0.1 Bcast [NONE SET] Mask 255.0.0.0
UP BROADCAST LOOPBACK RUNNING MTU 2000 Metric 1
RX packets 0 errors 0 dropped 0 overrun 0
TX packets 0 errors 0 dropped 0 overrun 0

As you can see, the loopback interface has been assigned a netmask of 255.0.0.0, since 127.0.0.1 is
a class-A address. As you can see, the interface doesn't have a broadcast address set, which isn't
normally very useful for the loopback anyway. However, if you run the rwhod daemon on your
host, you may have to set the loopback device's broadcast address in order for rwho to function
properly. Setting the broadcast is explained in section ``All about ifconfig'' below.
Now, you can almost start playing with your mini-``network.'' What is still missing is an entry in
the routing table that tells IP that it may use this interface as route to destination 127.0.0.1. This is
accomplished by typing
# route add 127.0.0.1

Again, you can use localhost instead of the IP-address.

Next, you should check that everything works fine, for example by using ping. ping is the
networking equivalent of a sonar device and is used to verify that a given address is actually
reachable, and to measure the delay that occurs when sending a datagram to it and back again. The
time required for this is often referred to as the round-trip time.
# ping localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp seq=0 ttl=32 time=1 ms
64 bytes from 127.0.0.1: icmp seq=1 ttl=32 time=0 ms
64 bytes from 127.0.0.1: icmp seq=2 ttl=32 time=0 ms
^C

--- localhost ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0/0/1 ms
When invoking ping as shown here, it will go on emitting packets forever unless interrupted by the
user. The ^C above marks the place where we pressed Ctrl-C.
The above example shows that packets for 127.0.0.1 are properly delivered and a reply is returned
to ping almost instantaneously. This shows you have succeeded in setting up your first network
interface.
If the output you get from ping does not resemble that shown above, you are in trouble. Check any
error if they indicate some file hasn't been installed properly. Check that the ifconfig and route
binaries you use are compatible with the kernel release you run, and, above all, that the kernel has
been compiled with networking enabled (you see this from the presence of the /proc/net directory).
If you get an error message saying ``Network unreachable,'' then you probably have got the route
command wrong. Make sure you use the same address as you gave to ifconfig.
The steps described above are enough to use networking applications on a standalone host. After
adding the above lines to rc.inet1 and making sure both rc.inet scripts are executed from /etc/rc, you
may reboot your machine and try out various applications. For instance, ``telnet localhost'' should
establish a telnet connection to your host, giving you a login prompt.
However, the loopback interface is useful not only as an example in networking books, or as a test-
bed during development, but is actually used by some applications during normal operation.
Therefore, you always have to configure it, regardless of whether your machine is attached to a
network or not.