The network layer Addressing and routing

1
The network layer
Addressing and routing
1. Mobility and addressing
1. What is the DHCP protocol used for?
Assign IP addresses and network conguration of automatic way.
2. What are the advantages of DHCP in comparison with a manual configuration?
Disadvantages of manual conguration:
(A) it is possible to assign an IP address has two different stations,
(B) to err in the conguration (subnet mask, network, default gateway)
(C) generates a high administrative burden in case of "nomadic" users.
Benefits of DHCP server provides all the information conguration TCP / IP with the
customer. The user no longer needs to visit his administrator for information on its
conguration
3. What is the difference between DHCP and the BOOTP or RARP protocols?
DHCP is based on BOOTP and maintains some backward compatibility. The main
difference is that BOOTP was designed for manual pre-conguration of the host
information in a server database, while DHCP allows for dynamic allocation of network
addresses and congurations to newly attached hosts. Additionally, DHCP allows for
recovery and reallocation of network addresses through a leasing mechanism. RARP is a
protocol used by Sun and other vendors that allows a computer to find out its own IP
number, which is one of the protocol parameters typically passed to the client system by
DHCP or BOOTP. RARP doesn’t support other parameters and using it, a server can only
serve a single LAN. DHCP and BOOTP are designed so they can be routed.
4. What is the Client ID used for?
What is termed the Client ID for the purposes of the DHCP protocol is whatever is
used by the protocol to identify the client computer. By default, DHCP implementations
typically employ the client’s MAC address for this purpose, but the DHCP protocol
allows other options. Some DHCP implementations have a setup option to specify the
client ID you want. One alternative to the MAC address is simply a character string of
your choice. In any case, in order for DHCP to function, you must be certain that no other

client is using the client ID you choose, and you must be sure the DHCP server will accept
it.
5. What are the four phases necessary so that a customer DHCP obtains a configuration of a
DHCP server?
(A) Dissemination of IP lease request
(B) Dissemination of a proposed lease IP server in response to the request
(C) The customer selects a lease that suits him (Sending a message to request a rental
lease)
2
(D) The server responds originally meant the proposal and other DHCP servers withdraw
their proposal
6. Can a DHCP server be used as backup for another DHCP server?
You can have two or more servers handing out leases for different addresses. If each has a
dynamic pool accessible to the same clients, then even if one server is down, one of those
clients can lease an address from the other server. However, without communication
between the two servers to share their information on current leases, when one server is
down, any client with a lease from it will not be able to renew their lease with the other
server. Such communication is the purpose of the "server to server protocol" (see next
question). It is possible that some server vendors have addressed this issue with their own
proprietary server-to-server communication.
7. Does that have a direction to think that a computer which was already seen allocating an
address by DHCP in request another temporarily to this same server?
There is nothing in the protocol to keep a client that already has a leased or permanent IP
number from getting a(nother) lease on a temporary basis on another subnet (i.e., for that
laptop which is almost always in one oce, but occasionally is plugged in in a conference
room or class room). Thus it is left to the server implementation to support such a feature.
I’ve heard that Microsoft’s NT-based server can do it.
8. How to choose the lease length of an address? Define the standard which appear
important to you.
I’ve asked sites about this and have heard answers ranging from 15 minutes to a year.

Most administrators will say it depends upon your goals, your site’s usage patterns, and
service arrangements for your DHCP server. A very relevant factor is that the client starts
trying to renew the lease when it is halfway through : thus, for example, with a 4 day lease,
the client which has lost access to its DHCP server has 2 days from when it rst tries to
renew the lease until the lease expires and the client must stop using the network. During a
2-day outage, new users cannot get new leases, but no lease will expire for any computer
turned on at the time that the outage commences. Another factor is that the longer the
lease the longer time it takes for client conguration changes controlled by DHCP to
propogate. Some relevant questions in deciding on a lease time : Do you have more users
than addresses ? If so, you want to keep the lease time short so people don’t end up sitting
on leases. Naturally, there are degrees. In this situation, I’ve heard examples cited of 15
minutes, 2 hours, and 2 days. Naturally, if you know you will have 20 users using 10
addresses in within a day, a 2 day lease is not practical. Are you supporting mobile users ?
If so, you may be in the situation of having more users than addresses on some particular
IP number range. See above. Do you have a typical or minimum amount of time that you
are trying to support ? If your typical user is on for an hour at minimum, that suggest a
hour lease at minimum. How many clients do you have and how fast are the
communications lines over which the DHCP packets will be run ? The shorter the lease,
the higher the server and network load. In general, a lease of at least 2 hours is long
enough that the load of even thousands of clients is negligible. For shorter leases, there
may be a point beyond which you will want to watch the load. Note that if you have a
communication line down for a long enough time for the leases to expire, you might see
3
an unusually high load it returns. If the lease-time is at least double the communication
line outage, this is avoided.
How long would it take to bring back up the DHCP server, and to what extent can your
users live without it ? If the lease time is at least double the server outage, then running
clients who already have leases will not lose them. If you have a good idea of your longest
likely server outage, you can avoid such problems. For example, if your server-coverage
is likely to recover the server within three hours at any time that clients are using their

addresses, then a six hour lease will handle such an outage. If you might have a server go
down on Friday right after work and may need all Monday’s work-day to x it, then your
maximum outage time is 3 days and a 6-day lease will handle it. Do you have users who
want to tell other users about their IP number ? If your users are setting up their own web
servers and telling people how to get to them either by telling people the IP number or
through a permanent DNS entry, then they are looking for an IP number that won’t be
changing. While some sites would manually allocate any address that people expected to
remain stable, other sites want to use DHCP’s ability to automate distribution of relatively
permanent addresses. The relevant time is the maximum amount of time that you wish to
allow the user to keep their machine turned o yet keep their address. For example, in a
university, if students might have their computers turned o for as long as three weeks
between semesters, and you wish them to keep their IP address, then a lease of six weeks
or longer would suffice.
Some examples of lease-times that sites have used and their rationals : 15 minutes : To
keep the maximum number of addresses free for distribution in cases where there will be
more users than addresses. 6 hours : Long enough to allow the DHCP server to be xed, e.g.
3 hours. 12 hours : If you need to take back an address, then you know that it will only take
one night for the users’ lease to expire. 3 days : This is apparently Microsoft’s default,
thus many sites use it. 6 days :Long enough that a weekend server outage that gets xed on
Monday will not result in leases terminating. 4 months : Long enough that students can
keep their IP address over the summer hiatus. I believe this rational is workable if the
summer hiatus is no more than 2 months. One year : If a user has not used their address in
six months, then they are likely to be gone. Allows administrator to recover those
addresses after someone has moved on.
9. Can the server control if the allocated addresses are always used by the clients?
There is no ideal answer : you have to give something up or do some extra work. You
can put all your clients on a subnet of your own along with your own DHCP server. You
can use manual allocation. Perhaps you can nd DHCP server software that allows you to
list which MAC addresses the server will accept. DHCP servers that support roaming
machines may be adapted to such use. You can use the user class option assuming your

clients and server support it : it will require you to congure each of your clients with a user
class name. You still depend upon the other clients to respect your wishes.
10. Can a DHCP server prohibit machines not to allocate itself an IP address that it manages?
This would have to be done using a mechanism other than DHCP. DHCP does not prevent
other clients from using the addresses it is set to hand out nor can it distinguish between a
computer’s permanent MAC address and one set by the computer’s user. DHCP can
impose no restrictions on what IP address can use a particular port nor control the IP
4
address used by any client.
11. Explain what would be the problem if an intruder on a network has taken a place
mischievously in a DHCP server?
A malicious user could make trouble by putting up an unocial DHCP server. The
immediate problem would be a server passing out numbers already belonging to some
computer yielding the potential for two or more "innocent bystander" nodes ending up
with the same IP number. Net result is problems using the nodes, possibly intermittent of
one or the other is sometimes turned o. A lot of problems are possible if a renegade server
manages to get a client to accept its lease oering, and feeds the client its own version of
other booting parameters. One scenario is a client that loads its OS over the network via
tftp being directed to a different le (possibly on a different server), thus allowing the
perpetrator to take over the client. Given that boot parameters are often made to control
many different things about the computers’ operation and communication, many other
scenarios are just as serious. Note that BOOTP has the same vulnerabilities. The
"broadcast ag" : DHCP includes a way in which client implementations unable to receive
a packet with a specic IP address can ask the server or relay agent to use the broadcast IP
address in the replies (a "ag" set by the client in the requests). The denition of DHCP states
that implementations "should" honor this ag, but it doesn’t say they "must". Some
Microsoft TCP/IP implementations used this ag, which meant in practical terms, relay
agents and servers had to implement it. A number of BOOTP-relay-agent
implementations (e.g. in routers) handled DHCP just ne except for the need for this
feature, thus they announced new versions stated to handle DHCP. Some of the virtual

LAN schemes, i.e., those that use the packet’s IP number to decide which "virtual LAN" a
client-computer is on for the purposes of TCP/IP, don’t work when using DHCP to
dynamically assign addresses. DHCP servers and relay agents use their knowledge of
what LAN the client-station is on to select the subnet number for the client-station’s new
IP address whereas such switches use the subnet number sent by the client-station to
decide which (virtual) LAN to put the station on. Routers are sometimes congured so that
one LAN on one port has multiple network (or subnet) numbers. When the router is
relaying requests from such a LAN to the DHCP server, it must pass along as IP number
that is associated with one of the network (or subnet) numbers. The only way the DHCP
server can allocate addresses on one of the LAN’s other network (or subnet) numbers is if
the DHCP server is specically written to have a feature to handle such cases, and it has a
conguration describing the situation.
The knowledge that a particular IP number is associated with a particular node is often
used for various functions. Examples are : for security purposes, for network
management, and even for identifying resources. Furthermore, if the DNS’s names are
going to identify IP numbers, the numbers, the IP numbers have to be stable. Dynamic
conguration of the IP numbers undercuts such methods. For this reason, some sites try to
keep the continued use of dynamically allocatable IP numbers to a minimum. With two or
more servers serving a LAN, clients that are moved around (e.g. mobile clients) can end
up with redundant leases. Consider a home site with two DHCP servers, a remote site with
DHCP services, and a mobile client. The client rst connects to the home site and receives
an address from one of the two serves. He/she then travels to the remote site (without
releasing the lease at the home site) and attempts to use the acquired address. It is of
5
course NAK’ed and the client receives an address appropriate for the remote site. The
client then returns home and tries to use the address from the remote site. It is NAK’ed but
now the client broadcasts a DHCPDISCOVER to get a address.
The server that holds the previous lease will oer the address back to the client but there is
no guarantee that the client will accept that address ; consequently, it is possible for the
client to acquire an address on the other server and therefore have two leases within the

site. The problem can be solved by using only one server per subnet/site and can be
mitigated by short lease lengths. But in a very mobile environment, it is possible for these
transient clients to consume more than their fair share of addresses. If departments, oces,
or individuals run DHCP servers with their own small address pools on LANs shared by
other departments, oces, or individuals, they can nd that their addresses are being used by
anyone on the LAN that happens to set their IP conguration to use DHCP. An easy
mistake to make in setting up a DHCP server is to fail to set all the necessary global
parameters. This can result in some functions working while others are not, or functions
working when the client is set up manually, but failing to work when set to use DHCP.
Long leases can be disadvantageous in cases where you need to change a conguration
parameter or withdraw an address from use. The length of the lease can mean the dierence
between having to go to every aected client and rebooting it, or merely waiting a certain
amount of time for the leases to be renewed. (Note : one workaround is to fool with the
client computer’s clock).
12. A DHCP relay must in theory always use the same server of destination for the
BOOTPREQUEST messages that it receives of a client given. Nevertheless an
implementation of relay agent which was developed proposes to use a mechanism of
Round-Robin for determine towards which DHCP server to send the request. Comment
on the advantages and disadvantages of this solution.
Advantage: allows load balancing among multiple DHCP servers.
Disadvantages: Each time it receives a new BOOTREQUEST message,it relays the
message to the next BOOTP server in a list of servers. Thus, with this relay agent,
multiple consecutive BOOTREQUEST messages from a given client will be delivered
todifferent servers. Unfortunately, this well-intentioned scheme reacts badly with DHCP
[3] and perhaps other variations of the BOOTP protocol which depend on multiple
exchanges of BOOTREQUEST and BOOTREPLY messages between clients and servers.
Therefore, al BOOTREQUEST messages from a given client MUST be relay d to the
same destination (or set of destinations). One way to meet this requirement while
providing some load-balancing benet is to hash the client’s link-layer address (or some
other reliable client-identifying information) and use the resulting hash value to select the

appropriate relay destination (or set of destinations). The simplest solution, of course, is to
not use a load-balancing scheme and just relay ALL received BOOTREQUEST messages
to the same destination (or set of destinations). When transmitting the request to its next
destination, the relay agent may set the IP Time-To-Live eld to either the default value for
new datagrams originated by the relay agent, or to the TTL of the original
BOOTREQUEST decremented by (at least) one.
13. It is supposed that 2 IP sub-network share physically the same LAN. The stations on each
sub-network then will see circulating all the packets diffused on the physic network.
6
a) Which problem can occur if two DHCP servers coexist on this shared LAN?
Suppose that two sub-IP networks share physically in a same physical support (2 VLANs
coexist on the same Ethernet). The stations on each subnet will then see all the packets
travel over the network physical dius. A computer can be assigned an address of a subnet
but does not know a priori which one. There may be conflicts during? Access to local
resources, such as name servers, NIS server?
b) Can one solve the problem? Propose a solution.
We can define the level of the server (or client for some implementations) the MAC
address associated with each IP address and thus define what address will be attributed to
a particular machine.
14. Why does one define the number of associations (MAC address – IP address) in the of
configuration files of DHCP server?
Because this limits the number of machines that can transit on the network.
15. By basing you on the extract of RFC 1542 whose extracts are given to you in appendix,
explain how a DHCP server managing several ranges of addresses will know to choose
the IP address in answer to a request.
Problem
A network administrator must reconsider the network plan of his company. He must conceive
the new network plan detail who will have to allow the automatic attribution of TCP/IP
configurations. The IP address of the network is 194.12.230.0, but the structure of the network
must reflect the organization in 3 distinct departments: Direction and Administrative

Departments, Engineer and R&D, Marketing and Commercial Service. These 3 domains are
connected to a router who is used as link towards the Internet. The IP address of this router is
fixed and does not belong with any the precedents domain. These three departments have
currently and respectively of 15, 45 and 12 workstations but the number of workstations is
brought to increase in the future. Each sub-network will have to allocate the configurations with
assistance of distinct DHCP servers. In order to make functionary the network in the same
breakdown case of one of DHCP servers, the other server must be able to take the relay. They
must if possible ensure that at least 25 % of the machines will be able to obtain a valid
configuration in their sub-network.
The configurations will have to be static in the case of some machines (server, router…) and
dynamic for the others. The DHCP servers will have to always obtain highest IP address available
in each sub-network, while the links will have the lowest IP address.
MAC address list of hosts which a fixed address must be allocate:
- Administrative DNS Server: 00-32-DE-5A-78-9C
- Administrative network link: 1F-7A-90-02-F0-F0
- Administrative network link towards the external router: 1F-7A-90-02-5F-4G