The domain name system dns other important utility protocols 635 413 31 summer 2007
Download
1 / 51

635413 Class 5 Sum .. - PowerPoint PPT Presentation


  • 290 Views
  • Uploaded on

The Domain Name System (DNS), & Other Important ‘Utility’ Protocols 635.413.31 – Summer 2007 Why is name resolution necessary? Allows the use of easily remembered names to access Internet resources instead of IP addresses Really set the stage for mass adoption of the Internet

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '635413 Class 5 Sum ..' - JasminFlorian


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
The domain name system dns other important utility protocols 635 413 31 summer 2007 l.jpg
The Domain Name System (DNS), & Other Important ‘Utility’ Protocols635.413.31 – Summer 2007


Why is name resolution necessary l.jpg
Why is name resolution necessary? ‘Utility’ Protocols

  • Allows the use of easily remembered names to access Internet resources instead of IP addresses

    • Really set the stage for mass adoption of the Internet

    • Originally accomplished with a static mapping table in each host

    • Static mapping could not scale with the tremendous growth of the Internet so a better system was necessary

    • In addition the original flat namespace could not scale either

  • The Domain Name System was developed in the early 80’s and formalized in RFCs 882 & 883

    • Updated in RFCs 1034 & 1035 along with numerous informational RFCs

  • DNS provides two things:

    • Name syntax & structure for delegation of authority

    • The protocol & other mechanisms necessary for mapping names to addresses


Goals of the domain name system l.jpg
Goals of the Domain Name System ‘Utility’ Protocols

  • There are four general goals for the Domain Name System

    • Be Efficient

      • Keep DNS local when possible

      • Cache data

    • Be Reliable

      • Multiple servers for redundancy

      • No single machine or network failure should take down DNS

    • Be General Purpose

      • As seen later, DNS provides for the mapping of different types of objects

      • Even the domain names and labels defined by the responsible Internet authorities could be changes or replaced in private DNS implementations

    • Be Distributed & Flexible

      • DNS is heirarchical, with the ability to delegate authority for portions of the namespace

      • Indeed, the logical structure of DNS does not have to follow the physical structure of the network


Basic example of how dns works l.jpg
Basic example of how DNS works ‘Utility’ Protocols

  • The host application wants to open a TCP connection

  • The application has domain name of the destination but needs an IP address to open the TCP connection

  • The application asks a special software process called the resolver on the local host to find the mapping from domain name to IP address

  • The local name server looks up the domain name and returns the mapping to the host resolver

  • The resolver returns IP address to application

  • The application then opens TCP connection using the IP address of the destination


The structure of domain names the dns tree l.jpg
The structure of domain names & the DNS tree ‘Utility’ Protocols

  • DNS defines a hierarchical namespace with structure that allows for delegation of authority

  • The structure of a domain name

    • A domain name consists of a series of alphanumeric labels up to 63 characters long separated by dots

    • The only generally accepted ‘special’ character is the dash (“-“); some name servers also allow the underscore (“_”)

  • The structure of the DNS tree

    • The top of the DNS tree (typically drawn upside down) is known as the ‘root’ or ‘dot’

    • Below the root are the Top Level Domains (TLDs)

    • ICANN (formerly IANA) is responsible for oversight of Top Level Domains and delegates authority for lower parts of the DNS tree


The structure of domain names the dns tree6 l.jpg
The structure of domain names & the DNS tree ‘Utility’ Protocols

Top Level Domains are currently organized into 3 different ‘groups’

1. The Organizational Top Level Domains or ‘generic’ TLDs

  • There are currently seven organizational TLDs

    • COM – commercial organizations

    • EDU – Universities and educational institutions

    • GOV – United States government

    • INT – international organizations formed by global treaty

    • MIL – United States military

    • NET – network providers and ISPs

    • ORG – organizations not fitting into any of the above categories (non-profit groups, etc)

  • GOV and MIL domains reserved exclusively for the U.S.government and military; INT and EDU have other restrictions

  • COM, NET, and ORG are generally available via registrars

  • Recently more TLDs have been defined by ICANN (.biz, .info, etc.) and are discussed later


The structure of domain names the dns tree7 l.jpg
The structure of domain names & the DNS tree ‘Utility’ Protocols

2. The Geographic Top Level Domains

  • Also known as the Country Domains because each country has a two character TLD in this group

  • Each country responsible for choosing a service provider to register domains under its TLD

  • Two letter country codes are defined by ISO (.us equals United States)

    3. The ARPA Top Level Domain

  • Defines the reverse (or inverse) mapping between domain names and IP addresses; reverse mapping is not as easy as it seems!

  • The whole IP address space laid out underneath this TLD

  • As explained later, implementation of reverse mapping handled independently from the name to IP address (forward) mapping


The structure of domain names the dns tree8 l.jpg
The structure of domain names & the DNS tree ‘Utility’ Protocols

  • How the structure of a domain name relates to the DNS tree

    • A Fully Qualified Domain Name (FQDN)

      • Traces the full path from the root to the node of the tree

      • The root node is unnamed or sometimes known as ‘dot’ because an FQDN ends with a ‘dot’

      • Provides a globally unique name

      • Queries must contain a FQDN!

    • A relative domain name

      • Provides a locally unique name only!

      • Hosts use relative names for efficiency


Primary secondary root servers l.jpg
Primary, Secondary, & Root Servers ‘Utility’ Protocols

  • Root servers form the top of the physical DNS hierarchy and contain the information necessary to contact the authoritative name servers for all second level domains

  • Every name server must know how to contact the root name servers

    • Typically the root name server IP addresses are configured into a name servers DNS configuration file

  • Currently 13 root name servers geographically distributed around the world

    • Root servers in the United States (some commercial, some military, & some at educational institutions)

    • Root servers in the rest of the world

    • Many of these machines are actually clusters for high reliability

    • Current list available at ftp://rs.internic.net/domain/named.root

  • The primary name server contains all the DNS information on disk and is the single administration point for all DNS information in its zone

  • Secondary name servers obtain all their DNS information by downloading it from the primary name server


Dns zones l.jpg
DNS Zones ‘Utility’ Protocols

  • A zone is a contiguous piece of the DNS tree that is administered separately from the rest of the tree

    • DNS zones do not necessarily have to correlate one-to-one to the IP address structure

    • There is a technical difference between domains and zones – domains denote namespace divisions and zones denote division of authority

  • Other characteristics of DNS Zones

    • Zones can be broken into sub-zones with delegated administration

    • The zone administrator must provide a primary name server for the zone and at least one secondary name server

    • The designated primary and secondary name servers are considered authoritative for their zone

    • The name servers should be as independent as possible to maximize availability

    • A set of primary & secondary name servers can serve more than one zone


Zone transfers l.jpg
Zone Transfers ‘Utility’ Protocols

  • The method of transferring a DNS mapping table from a primary to a secondary name server

  • Zones transfers are typically initiated by the secondary name server at regular intervals but if necessary they can be initiated on demand (e.g. - initialization of a new name server)

  • Zone transfers typically use TCP connections for reliability

  • For security zone transfers should be restricted to your network (if not down to the name servers themselves)


Dns caching l.jpg
DNS Caching ‘Utility’ Protocols

  • Caching minimizes name server load and network traffic (VERY important)

  • All name servers will cache the domain name information they receive

  • Depending on their complexity, host resolvers might cache DNS information

    • Most large multi-user systems cache for increased efficiency

    • Windows XP resolver (ipconfig /displaydns -> displays contents of the resolver cache)


Dns message format l.jpg
DNS Message format ‘Utility’ Protocols

  • A DNS message has three general parts:

    • Header

    • Questions

    • Resource Records (which are typically answers to questions)

  • General Structure of a DNS Message


Dns message format14 l.jpg
DNS Message format ‘Utility’ Protocols

  • Header

    • DNS messages have a fixed 12 byte header

    • IDENTIFICATION field

      • Set by client and used to match DNS replies with requests

    • FLAGS field

      • QR bit – bit set (=1) denotes a DNS response; otherwise it is a DNS query

      • OPCODE field (4 bits) – normally set to zero (standard query) but can be one (a reverse query) or two (DNS server status request)

      • AA bit – bit set (=1) denotes name server responding is the authoritative server for the domain in the question


Dns message format15 l.jpg
DNS Message format ‘Utility’ Protocols

  • Header Flags (continued)

    • RD bit – bit set (=1) denotes a request for the name server to perform a recursive query -- otherwise the request is for an iterative query

      • Recursive Query: If the name server does not have an authoritative answer it will handle the name resolution itself returning the answer to the originating name server

        • Resolvers almost always request recursive queries

      • Iterative Query: If the name server does not have an authoritative answer it will return to the requester the next name server to contact for the answer

        • Name servers use mostly iterative queries

        • Roots server typically do nothing but iterative queries because of load demands


Dns message format16 l.jpg
DNS Message format ‘Utility’ Protocols

  • Header Flags (continued)

    • RA bit – bit set (=1) in a response denotes the name server supports recursive queries

    • RCODE field (4 bits) – Specifies an error code (if any) in a DNS reply. Common values are zero (no error) or three (name error – the specified domain does not exist)


Dns message format17 l.jpg
DNS Message format ‘Utility’ Protocols

  • Questions

    • There is normally one question per DNS message

    • Question portion consists of three fields: query name, query type, & query class

      • Query Name: the domain name being looked up encoded in a special format

      • Query Type: denotes the type of question contained in the DNS message. Typical value is one (for a domain name lookup) or twelve (for a reverse lookup)

      • Query Class: should be one for IP (this field isn’t really necessary anymore; it was there to allow the DNS to handle name resolution for other network protocols)


Dns message format18 l.jpg
DNS Message format ‘Utility’ Protocols

  • Resource Records

    • The final part of a DNS message consists of three subparts which all share a common format called a Resource Record

    • The subparts are known as:

      • Answer Resource Records

      • Authority Resource Records

      • Additional Information Resource Records

    • Resource Record Format:


Dns message format19 l.jpg
DNS Message format ‘Utility’ Protocols

  • Common Fields in all Resource Records

    • Domain Name field (variable length): the data in this field specifies the name to which the data in the resource records pertains to

    • Type field (16 bits): specifies the resource record information type; same values as the Query Type field in the DNS Question

    • Class field (16 bits): as with the type field same as the Query Class field in the DNS Question

    • Time-to-Live field (32 bits): specifies the number of seconds that the Resource Record can be cached for in a non-authoritative name server. A typical TTL is two days

    • Resource Data length field (16 bits): the length in bytes of the data in the Resource Record

    • Resource Data field (variable): the data field length typically depends on the type of Resource Record (example: an A record’s data field would contain a four byte IP address)


Examples l.jpg
Examples ‘Utility’ Protocols

Root

Name Server

  • A DNS name resolution query in more detail

  • Example of a DNS Pointer query (Reverse Mapping)

    • Why is this functionality necessary?

      • Primarily for security (to discourage spoofing)

      • Also helps make server log files more readable

      • Reverse mapping of 128.220.10.11

ibm.com Zone

2

3

6

Destination

Host

fun.ibm.com

ibm.com

Name Server

5

jhu.edu

Name Server

Client

resolver

4

1


Other important dns resource records l.jpg
Other important DNS resource records ‘Utility’ Protocols

  • HINFO (Host Info)

    • Allows two sets of arbitrary character strings in the Resource Record typically to specify a hosts CPU and Operating System

    • Originally used to assist in troubleshooting network problems

    • Rarely used anymore for security reasons

  • MX (Mail Exchange)

    • Allows flexibility in how e-mail is delivered

    • Provides the following functionality:

      • Allows a site not permanently connected to the Internet to use a ‘proxy’ site as its mail exchanger (very important when UUCP was widely used)

      • Allows for the definition of ‘backup’ mail servers for redundancy

      • Allows the definition of a easy-to-remember virtual ‘mail’ domain ([email protected]) for users on the Internet

      • Allows organizations with firewalls to limit connectivity to internal systems

      • MX records include a 16 bit preference value; if multiple MX records exist for a destination the one with the lowest preference value will be used


Other important dns resource records22 l.jpg
Other important DNS resource records ‘Utility’ Protocols

  • SOA (Start of Authority)

    • Resource Record found specifying the primary name server for a zone and indicating its authority for the zone

    • Only one SOA RR found in the server at the start of the config file

    • Contains information necessary for operation of the secondary name servers (time between zone transfers, when the DNS configuration changes, etc.)

  • NS (Name server)

    • The name server record specifies the name server(s) for a domain

    • Most important use is specifying secondary name servers (the primary is also specified in the SOA RR)

  • CNAME (Canonical Name)

    • Also known as an alias

    • Allows one domain name to be mapped to another

    • VERY useful for organizations with general services (WWW, FTP, etc) that they would like to advertise at easy-to-remember names (www.acme.com, etc)

    • Allows the implementation of a rudimentary form of load sharing & redundancy


Example zone configuration l.jpg
Example Zone Configuration ‘Utility’ Protocols

  • Portion of an actual Zone File from a Name Server


Dns implementation l.jpg
DNS Implementation ‘Utility’ Protocols

  • Use of TCP and UDP

    • For queries and replies UDP is typically used though if the reply is larger than 512 bytes (the maximum size for a UDP datagram) the client will need to reissue the request; it and the reply will be via TCP

    • For both TCP and UDP, the DNS uses the well-known port 53

    • Zone transfers are done via TCP because of the size of the DNS configuration data and to provide high reliability

  • Name Server Software

    • BIND (Berkeley Internet Name Domain) and Named

      • Arguably the most widely used name server software in existence; found on most flavors of UNIX

      • Current version is 9.4.1, though versions 8.4, 9.2, & 9.3 are commonly used

    • Windows Family of Servers

      • NT Server 2000/2003 have a native DNS server

      • NT Server 4.0 supports several third party ports of BIND as well as a ‘native’ version in the NT Option Pack


Dns implementation25 l.jpg
DNS Implementation ‘Utility’ Protocols

  • Useful DNS commands for troubleshooting

    • Nslookup

      • Common way to check to see that DNS is working properly

      • Found on all common Unix variants & later Windows systems

      • Syntax: nslookup [-option ...] [host-to-find | -[server]]

      • Example:

        > nslookup www.yahoo.com

        Server: ns2.umd.edu

        Address: 128.8.76.2

        Non-authoritative answer:

        Name: www.yahoo.akadns.net

        Addresses: 216.109.118.66, 216.109.118.67, 216.109.118.69, 216.109.118.71

        216.109.118.72, 216.109.118.79, 216.109.117.205, 216.109.118.65

        Aliases: www.yahoo.com

        >


Dns implementation26 l.jpg
DNS Implementation ‘Utility’ Protocols

  • Another good DNS command: DIG

    > dig umd.edu mx

    ; <<>> DiG 8.3 <<>> umd.edu mx

    ;; res options: init recurs defnam dnsrch

    ;; got answer:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2

    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5

    ;; QUERY SECTION:

    ;; umd.edu, type = MX, class = IN

    ;; ANSWER SECTION:

    umd.edu. 16h40m IN MX 10 mailfw1.umd.edu.

    umd.edu. 16h40m IN MX 10 mailfw0.umd.edu.

    ;; AUTHORITY SECTION:

    umd.edu. 16h40m IN NS ns2.umd.edu.

    umd.edu. 16h40m IN NS noc.umd.edu.

    umd.edu. 16h40m IN NS ns1.umd.edu.

    ;; ADDITIONAL SECTION:

    mailfw0.umd.edu. 5M IN A 128.8.70.20

    mailfw1.umd.edu. 10M IN A 128.8.10.57

    noc.umd.edu. 5M IN A 128.8.5.2

    ns1.umd.edu. 16h40m IN A 128.8.74.2

    ns2.umd.edu. 16h40m IN A 128.8.76.2


Dns futures l.jpg
DNS Futures ‘Utility’ Protocols

  • New Top Level Domains (TLDs)

    • The growth in use of the Internet and domain names has spurred the creation of a new set of TLDs to augment the existing seven

    • Are now in use – see http://www.iana.org/gtld/gtld.htm

    • Some of the new TLDs that have been implemented

      • BIZ – for businesses

      • INFO – unrestricted use, but intended for information resources

      • PRO – unrestricted use, but for professionals

      • NAME – unrestricted use, for individuals

      • AERO – restricted use, for aviation industry

      • COOP – restricted use, for cooperatives

      • MUSEUM – restricted use

      • MOBI – for mobile providers and services

    • More are undoubtedly on the way!!


Dns futures28 l.jpg
DNS Futures ‘Utility’ Protocols

  • DNS competition

    • Competition is here for DNS registration – there is now a large number of organizations certified to register domain names in the central registry

    • Management of the core TLD registry for COM, ORG, and EDU is currently run by one company under contract to the Department of Commerce however other companies certified by ICANN can add to the registry (for a flat fee)

    • There have been attempts by other organizations to set up competing DNS trees and Top Level Domains

    • There is also a movement to create a set of non-English TLDs and corresponding DNS hierarchy

      • Proposals for IDNs (International Domain Names) are under debate within ICANN


Dns futures29 l.jpg
DNS Futures ‘Utility’ Protocols

  • Dynamic DNS

    • A protocol that allows automated configuration of DNS servers with updated name to IP address mapping

    • Supported in later versions of BIND (I believe anything version 8 and later), Windows 2000/2003, & Lucent’s QIP

      • Active Directory relies on D-DNS for fundamental operation

      • Also makes use of the SRV RR defined in RFC 2782

    • D-DNS protocol specified in RFC 2136

    • Implemented with AD but otherwise relatively uncommon (and there are security issues surrounding such functionality)

    • Supposed to conceptually work in conjunction with DHCP to automate host configuration


Dns futures30 l.jpg
DNS Futures ‘Utility’ Protocols

  • Secure DNS (aka DNSSec)

    • One big problem with DNS is its openness & lack of security

    • The DNS has been used as a basis of attack & been a target itself

    • DNSSec is supposed to help provide a solution

      • Defined in RFCs 4033, 4034, and 4035

      • Provides for authentication and integrity checking on DNS data

    • What DNSSec entails

      • A PKI-like public key infrastructure (keys & chains of trust from a root)

      • New Resource Records & DNS Message Fields (RRSIG, DNSKEY, etc.)

      • New Protocol Functions (e.g. – answering a negative reply with a special ‘signed’ NSEC RR response)

    • Current Challenges

      • Like PKI, deployment & maintenance of key infrastructure is a hurdle

      • Does not address privacy nor denial-of-service (DoS) attacks

      • Not really supported on Windows 2003 (OK on BIND 9.x)


The bootstrap protocol bootp l.jpg
The Bootstrap Protocol (BOOTP) ‘Utility’ Protocols


What is bootp used for l.jpg
What is BOOTP used for? ‘Utility’ Protocols

  • Designed to provide better support for systems that required dynamic network configuration

  • Intended to replace RARP for four reasons

    • Can provide more configuration data than RARP; which just provides an IP address

    • Requests and replies can be forwarded by routers (RARP only good on the local subnet)

    • More bandwidth efficient because replies are not typically broadcast

    • RARP is a very low level protocol that usually requires direct hardware access; difficult to implement in applications

  • Defined in RFC 951 & updated in RFC 1542

  • Uses UDP for transport and well-known port numbers 68 for the BOOTP server and 69 for the BOOTP client


What is bootp used for33 l.jpg
What is BOOTP used for? ‘Utility’ Protocols

  • BOOTP Message Format


Bootp message format l.jpg
BOOTP message format ‘Utility’ Protocols

  • Always 300 bytes long

  • Opcode field (8 bits): specifies whether message is a BOOTP request (=1) or a BOOTP reply (=2)

  • Hardware type field (8 bits) & HW address length fields (8 bits): specifies the physical/DL layer protocols in use (Ethernet = 1)

  • Hop Count field (8 bits): set to zero by a BOOTP client; used by BOOTP relay agents to record how far the message has been sent (it is SUGGESTED that any relay agent receiving a BOOTP message with a Hop Count greater than three should toss it)

  • Transaction ID field (32 bits): set by the client to a locally unique value; used by the client to match a response with a request

  • Number of Seconds field (16 bits): set by the client with the time since it began trying to boot; allows a secondary server to respond only if the primary appears to be down


Bootp message format35 l.jpg
BOOTP message format ‘Utility’ Protocols

  • IP Address fields

    • Client IP address: contains either the client IP address if known or 0.0.0.0 if the client is issuing a BOOTP request for its IP address

    • Your IP address: field filled in by the BOOTP server with the client’s IP address

    • Server IP address: IP address of the BOOTP server issuing the reply

    • Gateway IP address: filled in by a BOOTP relay agent if it forwards a request to a BOOTP server on a remote network

  • Client Hardware Address field (16 bytes): filled in by the client when issuing request; actual length of the hardware address is usually less than 16 bytes

  • Server Hostname field (64 bytes): filled in by the server in a reply (optional)

  • Boot filename field (128 bytes): used to specify an optional null-terminated pathname of a file to boot from

  • Vendor-specific information field (64 bytes): can be used by server in a reply to supply additional information necessary for the client to complete its bootstrap routine


Bootp in use l.jpg
BOOTP in use ‘Utility’ Protocols

A typical example for a diskless workstation

  • Client boots and issues a limited broadcast (source = 0.0.0.0 and destination = 255.255.255.255) BOOTP request message

  • BOOTP server constructs and issues reply with a valid IP address and a bootfile name in the bootfile field (Note: more than one BOOTP server can respond)

  • Client uses the BOOTP reply from the first server to respond and broadcasts gratuitous ARP with its new mapping

  • Client broadcasts ARP request for BOOTP server it chose

  • BOOTP server issues an ARP reply

  • Client initiates file transfer (typically using a protocol called TFTP studied later) to download bootfile

  • Transfer of bootfile completes and workstation continues to boot using its new configuration information


Bootp implementation l.jpg
BOOTP implementation ‘Utility’ Protocols

BOOTP Server Design

  • In some instances a server will need to broadcast its BOOTP reply

  • The RFCs do not cover any details on the implementation of the BOOTP server client configuration database; typically a static mapping table is used

    Implementation Issues

  • Multi-homed hosts: each network interface requires a separate BOOTP negotiation

  • BOOTP clients force the use of UDP checksums and does not allow fragmentation


Bootp through a router l.jpg
BOOTP through a router ‘Utility’ Protocols

  • Routers can be configured to act as BOOTP relay agents (This function is separate than its IP forwarding function and typically has to be explicitly configured)

  • BOOTP relay agents will receive a broadcast BOOTP request from a client on a directly connected network and reissue a unicast BOOTP request to the server

  • All other BOOTP relay agents between the initial relay agent and the server will do nothing to the unicast BOOTP request except increment the hop count

  • Only the BOOTP relay agent filling in the Gateway IP address field should intercept a BOOTP server reply and attempt to send it to the requesting client.


Transmission of vendor specific information via bootp l.jpg
Transmission of vendor specific information via BOOTP ‘Utility’ Protocols

  • Format of this field covered in RFC 2132 (DHCP Options & BOOTP Vendor Extensions)

  • If the server wants to use this field the first data in the field must be the Magic Cookie (the value equal to the IP address 99.130.83.99)

  • Following the Magic Cookie are a list of items structured in TLV format (Type, Length, & Value fields)

    • Pad: one byte with type=0

    • End: one byte with type=255

    • Subnet Mask: type=1, length=4, and data equals a four byte subnet mask

    • Time Offset: type=2, length=4, and data equal to the number of seconds past midnight GMT January 1, 1900

    • Gateway(s): type=3, length = 4 x N where N= number of gateways, and list equals a set N of gateways from most to least preferred

    • Other items are defined for more specific purposes


The dynamic host configuration protocol dhcp l.jpg
The Dynamic Host Configuration Protocol ‘Utility’ Protocols(DHCP)


Introduction to dhcp l.jpg
Introduction to DHCP ‘Utility’ Protocols

  • DHCP is designed to be an enhancement to BOOTP by moving closer to the goal of completely automated network host configuration

  • Defined in RFC 2131

  • Uses the same message structure as BOOTP with some enhancements

    • Special item in Option field differentiates a DHCP message from a BOOTP message

    • In general DHCP is much more flexible than BOOTP, which cannot easily accommodate mobile and multi-boot systems

    • The two protocols are generally compatible (more on this later)


Differences between bootp and dhcp l.jpg
Differences between BOOTP and DHCP ‘Utility’ Protocols

DHCP has two major advantages over BOOTP:

  • The vendor specific field is no longer fixed size and can hold a lot more configuration information

  • DCHP supports two more IP address allocation methods besides the manual allocation mode also found in BOOTP

    • With manual allocation means the network administrator explicitly configures a permanent IP address for a client into the BOOTP/DHCP server mapping file

    • Automatic allocation

      • The DHCP server permanently assigns an IP address to a client as in manual allocation

      • The particular IP address assigned to the client is determined internally in the server: first-come first-served, geographically, through some formula, etc.


Differences between bootp and dhcp43 l.jpg
Differences between BOOTP and DHCP ‘Utility’ Protocols

  • DHCP Address Allocation Modes

    • Dynamic allocation

      • Address is assigned dynamically from a pool of IP Addresses

      • Addresses are ‘leased’ to a client for a defined period of time

      • When lease expires the client should relinquish the IP address

        • Infinite leases are possible

        • Client can request extension of the lease

        • Servers should try to reallocate the same address to clients though it should never be assumed by clients that they will get the same one


Interoperability with bootp l.jpg
Interoperability with BOOTP ‘Utility’ Protocols

  • DHCP servers should service BOOTP clients (though BOOTP clients have no concept of IP address ‘leasing’)

    • A DHCP server will have to make provisions for the simplicity and ignorance of BOOTP clients (especially with address ‘leasing’)

  • BOOTP servers should be able to respond to typical DHCP client requests

    • DHCP clients should prefer an Offer from a DHCP server over a reply from a BOOTP server

  • Routing acting as BOOTP relay agents should also act as DHCP relay agents (and vice versa)


Dhcp options l.jpg
DHCP Options ‘Utility’ Protocols

  • DHCP does not add fields to the BOOTP message nor does it change the meanings of most fields

  • Most DHCP enhancements are encoded in the options field

  • Options are encoded in TLV (type-length-value) format

  • The most important options for DHCP operation are the DHCP message types

  • There is also a special Option Overload option, which allows the DHCP server to use the SERVER HOST NAME and BOOT FILE NAME fields for transmission of additional DHCP options


Dhcp message types l.jpg
DHCP Message Types ‘Utility’ Protocols

  • DHCP Discover (Client->Server) - Client broadcast to locate available servers

  • DHCP Offer (S->C) - Response from one or more servers to DHCPDISCOVER with offer of configuration parameters

  • DHCP Request (C->S) – Client request in one of the following situations:

    • Accepting configuration parameters from one server and implicitly declining parameters from any other DHCP servers that responded with an offer.

    • Confirming correctness of assigned IP address after some event such as a system reboot

    • Extending the lease on an IP address


Dhcp message types47 l.jpg
DHCP Message Types ‘Utility’ Protocols

  • DHCP ACK (S->C) - Servers response that the offered configuration parameters are correct and committed to the DHCP client

  • DHCP NAK (S->C) - Server’s response to a client that the client’s notion of its assigned IP address is incorrect or informing a client that its lease has expired

  • DHCP Decline (C->S) - Client informing server that the offered network address is already in use

  • DHCP Release (C->S) - Client informing server that it is relinquishing lease on and use of a particular IP address

  • DHCP Inform (C->S) - Client requesting only local configuration parameters; used when client already has an IP address


Dhcp state diagram l.jpg
DHCP State Diagram ‘Utility’ Protocols


Dhcp in action l.jpg
DHCP in Action ‘Utility’ Protocols

  • An example of a client configuration sequence (match with the state diagram in the textbook)

    1. Client boots

    2. Client broadcasts DHCP Discover message

    3. One or more servers responds with a DHCP Offer message containing IP address and network configuration parameters based on the DHCP administrator’s policies

    4. The client chooses one of the DHCP Offer messages and broadcasts a DHCP Request with the chosen server specified in the ‘server identifier’ field – all other DHCP servers that responded with offers know by examining the request that they were not chosen


Dhcp in action50 l.jpg
DHCP in Action ‘Utility’ Protocols

  • Client configuration example (continued)

    5. The chosen DHCP server receives the Request message and commits the client’s assigned address in its database. The server responds (typically unicast) to the client with a DHCP ACK confirming successful reservation of the IP address

    • If the client detects that the IP address is in use by another host (and they should check using a ping) instead of sending an ACK it should send a DCHP Decline

    • If for some reason the server believes the client is using an incorrect IP address (via the DHCP Request message it received) it will send a DHCP NAK message and the client will be forced to restart the configuration process

      6. After receiving the DHCP ACK the client should be fully configured and able to communicate on the TCP/IP network


Reading homework l.jpg
Reading & Homework ‘Utility’ Protocols

  • Reading

    • Comer: Chapters 23 and 24

  • Homework Assignment #3 (due Thursday 6/28)

    • Chapter 13: 13.1

    • Chapter 14: 14.4, 14.9

    • Chapter 15: 15.8, 15.12, and 15.14

    • Chapter 16: 16.4, 16.7, and 16.9

    • Chapter 22: 22.9, 22.11, and 22.12

    • Chapter 23: 23.13 and 23.14

    • A number of organizations run controlled interfaces to their routers that allow limited access to outsiders for troubleshooting. A list of these ‘looking glass’ routers can be found at http://www.caida.org/analysis/routing/reversetrace/ Use at least three routers on different continents to do BGP path lookups and traceroutes to www.apl.jhu.edu. List your results and explain the differences and similarities you see.

  • Note: These five classes cover all the material on the mid-term!


ad