The Illustrated Network- P52 pdf

In fact, router confi guration of DHCP can be complicated because many routers mention only BOOTP relay agents and assume administrators know they are the same.. IPv6 includes elaborate

DHCP AND ROUTERS

DHCP takes advantage of the BOOTP relay agent concept In fact, router confi guration

of DHCP can be complicated because many routers mention only BOOTP relay agents and assume administrators know they are the same

A DHCP relay agent is usually a router, but it could also be a dual-homed host that uses a router to reach the DHCP server A typical confi guration using a router as a relay agent was shown in Figure 18.1

The DHCP relay agent listens for broadcast BOOTP request messages and sends them to the server The relay agent then receives replies from the DHCP server and replies to the client

DHCPv6

We haven’t done anything with DHCP in IPv6 There’s a reason for that, and it has to

do with the way IPv6 confi gures itself on a host

A lot of what DHCP does in IPv4 can also be done with RARP and ICMP Yet DHCP

is all over the place in IPv4 IPv6 includes elaborate neighbor and router discovery pro-tocols that allow IPv6 hosts to invent link-local IPv6 addresses and multicast groups for confi guration purposes Yet, just like IPv4 DHCP for IPv6 exists as DHCPv6 There are

at least three reasons DHCPv6 continues to make sense in IPv6

■ Not all networks support the multicasts needed for IPv6 autoconfi guration, like those consisting of point-to-point links or ATM and frame relay

■ Some small IPv6 networks might not have a router, which is required for

IPv6 autoconfi guration

■ Network managers might desire more control over device confi guration

than afforded by IPv6 autoconfi guration

DHCPv6 will not be used on the Illustrated Network There is no BOOTP support because it is not really needed in IPv6 In truth, a lot of DHCP parameters are superfl uous

in IPv6 It is enough for this chapter to point out that DHCPv6 can be triggered by options

in the IPV6 Router Advertisement messages, which we fi rst introduced in Chapter 5

DHCPv6 and Router Advertisements

DHCPv6 and its relationship to IPv6 addressing are described in a series of RFCs, most notably RFC 3315 and 3726 DHCPv6 can provide stateless or stateful address autoconfi guration information to IPv6 hosts Stateless address autoconfi guration is used to confi gure both link-local and additional non–link-local addresses through the exchange of Router Solicitation and Router Advertisement messages with routers State-ful address autoconfi guration is used to confi gure non–link-local addresses through the use of a confi guration protocol such as DHCP

How does a host know which one it can use? We did not emphasize it then, but our discussion of the IPv6 Router Advertisement protocol in Chapter 7 mentioned the M and O bit fl ags The Router Advertisement message can set the following:

bit instructs the host to use the configuration protocol to obtain a stateful (non–link-local) address

Other Stateful Configuration Flag, known as the O flag—When set to 1, this bit instructs the host to use the configuration protocol to obtain more configura-tion settings

There can be four different situations

1 Both M and O fl ags are 0 This is used when the local network has no DHCPv6 infrastructure IPv6 hosts use Router Advertisements and other methods, such as manual confi guration, to get non–link-local addresses and other settings

2 Both M and O fl ags are 1 In this case, DHCPv6 is used to obtain both addresses

and other confi guration settings This is known as the “DHCPv6 stateful” situa-tion, and DHCPv6 is used to assign stateful addresses to the IPv6 hosts

3 M fl ag is 0, O fl ag is 1 DHCPv6 is not used to provide addresses, but only other

confi guration settings, such as the location of DNS servers The routers are set to advertise non–link-local prefi xes from which the IPv6 hosts can confi gure state-less addresses This is known as “DHCPv6 statestate-less” because stateful addresses are not provided

4 M fl ag is 1, O fl ag is 0 DHCPv6 is used to provide addresses, but no other

set-tings This combination is allowed but unlikely, because IPv6 hosts need to know other things, such as the addresses of the DNS servers

Because we’re not using DHCPv6 on the Illustrated Network, we won’t detail the DHCPv4 message formats and exchange patterns—which are different for stateful and stateless operation

DHCPv6 Operation

All DHCP servers and relay agents are required to join the local All-DHCP-Agents multi-cast group, and all servers must join the local All-DHCP-Servers group All relay agents also join the local All-DHCP-Relays group

DHCPv6 servers and agents send to UDP port 546, and clients send to UDP port

547 There are six message types defi ned for DHCPv6, and one nice feature is that the operation code (or message type byte) comes fi rst in the message instead of being buried in the old BOOTP options fi eld (as is DHCP for IPv4)

QUESTIONS FOR READERS

Figure 18.13 shows some of the concepts discussed in this chapter and can be used to help you answer the following questions

1 The client sets the BOOTP hop count to zero initially If that is the case, what is the hop counter used for?

2 What is the hardware type and hardware address length for Ethernet?

3 How is the relay router IP address fi eld used?

4 What is the client ID option in DHCP?

5 What is the “magic cookie” IP address in BOOTP?

Opcode

Opcode Transaction ID (used to match request and reply)

Client Hardware Address

Flag Field

Client IP Address (if known to Client, otherwise all 0)

Server Host Name (Client can optionally identify Server)

File Name

Client IP Address (provided by Server in response)

IP Address of Server

Options

Relay Router IP Address

Hardware Type

Length of

Hw Address

Hop Counter

Unused

Client IP Address (if known to Client, otherwise all 0)

Client IP Address (provided by Server in response)

IP Address of Server (Server response: where Client should go for Boot file)

Relay Router IP Address

Server Host Name (Client can optionally identify Server)

Boot File Name (Client supplies generic name — “Windows”)

“Vendor-Specific Area”

Additional Parameters

Client Hardware Address

Hardware Type

Length of

Hw Address Transaction ID (used to match request and reply)

Seconds Elapsed Since Client

Sent First Request Message

Seconds Elapsed Since Client Sent First Request Message

Hop Counter

BOOTP Message Format and Fields

DHCP Message Format and Fields

FIGURE 18.13

The BOOTP and DHCP messages compared.

481

What You Will Learn

In this chapter, you will learn how DNS gives the Internet a more user-friendly way to access resources We’ll see how names are associated with IP addresses and how applications fi nd this information

You will learn how DNS servers provide information about local networks, and how this information is distributed and shared on the Internet We’ll also use show tools to help examine DNS

The Domain Name

The Domain Name System (DNS) is the distributed database used by the TCP/IP protocol suite to translate hostnames to IP addresses (both IPv4 and IPv6) and provide related information, such as email routing information DNS has been around as part of the Internet for so long that it is easy to forget that in the early days users needed a fi le named /etc/hosts (no extension) unless they wanted to type in the 32-bit IP address that went along with the hostname

Today, the database is distributed because no single site on the Internet knows everyone’s hostname and IP address Of course, placing every host’s IP address in a single text fi le would be impractical now, but people can still type www.juniper.net anywhere on the Internet and access the main Web page for the site The correct func-tioning of DNS is so ingrained in expectations that many users do not even realize that when DNS fails typing, http://207.17.137.68 yields the same result as the www entry For many, when DNS disappears the Internet might as well have vanished as well (except for some local and cached IP addresses, this is probably true enough)

Microsoft support services report that well over 70% of all calls, no matter what the reported symptom, end up being DNS calls How can something as apparently simple

as DNS cause such problems? Two big reasons are that the details of DNS functioning have changed a lot recently, and that many users and administrators know very little about the inner workings of DNS

Because of the abundance of new terminology, special operations, and new types

of servers, this chapter requires us to discuss some of the basics of DNS before looking

lo0: 192.168.0.1

fe-1/3/0: 10.10.11.1 MAC: 00:05:85:88:cc:db (Juniper_88:cc:db) IPv6: fe80:205:85ff:fe88:ccdb

P9

lo0: 192.168.9.1

PE5

lo0: 192.168.5.1

P4

lo0: 192.168.4.1

so-0/0/1 79.2

so-0/0/1 24.2

so-0/0/0 47.1

so-0/0/2 29.2

so-0/0/3 49.2

so-0/0/3 49.1

so-0/0/059.2

so-0/0/2 45.1

so-0/0 /2 45.2

so-0/0/059.1

ge-0/0/3 50.2

ge-0/0/350.1 DSL Link

Ethernet LAN Switch with Twisted-Pair Wiring

MAC: 00:d0:b7:1f:fe:e6 (Intel_1f:fe:e6) IPv6: fe80::2d0:

b7ff:fe1f:fee6

Primary DNS Server

LAN2: 10.10.11.51 MAC: 00:0e:0c:3b:88:3c (Intel_3b:88:3c) IPv6: fe80::20e:

cff:fe3b:883c

LAN2: 10.10.11.111

winsvr1

LAN1

Los Angeles

Office

Ace ISP

AS 65459

Wireless

in Home

“dig”

used

Solid rules ⫽ SONET/SDH

Dashed rules ⫽ Gig Ethernet

Note: All links use 10.0.x.y

addressing only the last

two octets are shown.

FIGURE 19.1

DNS on the Illustrated Network, showing the hosts used as primary and secondary DNS servers and utilities.

DNS Server

“nslookup”

Used

CE6

lo0: 192.168.6.1

fe-1/3/0: 10.10.12.1 MAC: 0:05:85:8b:bc:db (Juniper_8b:bc:db) IPv6: fe80:205:85ff:fe8b:bcdb Ethernet LAN Switch with Twisted-Pair Wiring

MAC: 00:0e:0c:3b:88:56 (Intel_3b:88:56) IPv6: fe80::20e:

cff:fe3b:8856

LAN2: 10.10.12.222 MAC: 00:02:b3:27:fa:8c IPv6: fe80::202: b3ff:fe27:fa8c

LAN2

New York

Office

P7

lo0: 192.168.7.1

PE1

lo0: 192.168.1.1

P2

lo0: 192.168.2.1

so-0/0/1

79.1

so-0/0/1

24.1

so-0/0/0

47.2

so-0/0/2

29.1

so-0/0/3 27.2

so-0/0/3 27.1

so-0/0/2 17.2

so-0/0/2 17.1

so-0/0/0 12.2

so-0/0/0 12.1

ge-0/0/3 16.2

ge-0/0/3 16.

1

Best ISP

AS 65127

Global Public Internet

at how DNS is employed on a network In this chapter, we’ll use the equipment in the roles shown in Figure 19.1 Discussion will be kept to a minimum and exploration is maximized in this chapter

DNS BASICS

Recall that two things are globally administered in TCP/IP: the network portion of the IPv4 or IPv6 address and the domain name that goes along with it The host portion

of the IP address and the further qualifi cation of the domain name are administered locally It is up to the local administrator to prevent duplicates at this level, and in large organizations this is not as easy as it sounds (In some cases there are valid reasons for duplicates to exist in an organization, such as due to “split horizon” issues.) Very large organizations often depend on several layers of administration (perhaps division, department, and so on) to dole out blocks of addresses and domain names correctly Along with this responsibility goes the duty to ensure that all of the detailed host addressing and the corresponding fully qualifi ed domain names (FQDNs) is correct so that all of the clients can fi nd the servers they are supposed to fi nd

Usually each site—whether it be a company, university, or other type of organiza-tion—maintains its own database of information and runs a server process (typically

on a dedicated system) other systems can query You can also get a third party (not the ISP) to manage a zone for you, and that is a service most registrars will do for a nominal fee (if not free) with the registration of a domain name

At one time, connection to the Internet required an organization to provide at least two DNS servers for the site The goal was resilience, but because missing authoritative name serves can cause all sorts of performance issues two non-topologically diverse name serves do not really solve anything Now, very small organizations (or individual users) often rely on their ISP to provide the DNS service and point all of their hosts

at these two “public” DNS servers for hostname resolution This arrangement poses its own set of problems, such as a recurring ISP charge to “maintain” the database records (surely the lowest maintenance task on the Internet) and the need to update the ISP’s database when changes to FQDN or IP addressing take place on the local network Dynamic IP addresses also cause problems for DNS, as detailed later in this chapter

The DNS Hierarchy

DNS servers are arranged in a hierarchical fashion That is, the hundreds of thousands

of systems that are authoritative for the FQDNs in their zone are found at the bottom

of the DNS “pyramid.” For ease of maintenance, when two or more DNS servers are involved only one of them is fl agged as the primary server for the zone, and the rest become secondary DNS servers Both are authoritative for the zone ISPs typically run their own DNS servers, often for their customers, with the actual number of systems for each ISP depending on the size of the ISP At the top of the pyramid is the “backbone.” There are root servers for the root zone and others for .com, .edu, and so on

DNS servers above the local authoritative level refer other name servers to the systems beneath them, and when appropriate each name server will cache informa-tion Information provided to hosts from any but the authoritative DNS system for the

domain is considered non-authoritative, a designation not refl ecting its reliability, but

rather its derived nature

Authoritative and non-authoritative servers can be further classifi ed into categories Authoritative servers can be:

■ Primary—The primary name server for a zone Find its information locally in

a disk fi le

■ Secondary—One or more secondary name servers for the zone They get their information from the primary

■ Stub—A special secondary that contains only name server data and not

host data

■ Distribution—An internal (or “stealth server”) name server known only by IP address

Keep in mind that the primary and secondary distinction is relevant only to the operator

of the systems and not to the querier, who treats them all the same Non- authoritative

servers (technically, only the response is non-authoritative) can be:

■ Caching—Contain no local zone information Just caches what it learns from other queries and responses it handles

■ Forwarder—Performs the queries for many clients Contains a huge cache

Root Name Servers

The root servers that stand at the tip of the DNS pyramid deserve more explanation in terms of operation and organization Today, the root servers are the entry points to the DNS service and rely more on caching than the passive databases that once character-ized the root server system With the explosion of the Internet, it made little sense to maintain records with the same “priority” for sites that are constantly bombarded with traffi c and those that are seldom visited The current database in a root name server is small

The current root servers only know which name server a local DNS needs to ask next to resolve a query So, any query for a .com sent to a root name server produces

a list of name servers that might know the answer The continuous caching of these answers means that there is less need to query the root servers after the fi rst query

Root Server Operation

The root server operators are not involved in the policymaking regarding Internet names and addresses, nor in modifi cation of the data They just take what is originated

by one of their number (Verisign Global Registry Services) and propagate it to the others The operators are encouraged to explore diversity in organizational structure,

locations, hardware, and software, while maintaining expected levels of physical sys-tem security and over-provisioning of capacity They maintain their own infrastructure for emergencies, including telephone hotlines, encrypted email, and secure credentials

The root servers use distributed anycast where practical, making many separate

sys-tems all over the world appear and act as one system with one IP address The use of anycast helps minimize the effects of denial-of-service attacks

We haven’t talked about anycast before In anycast, as in multicast, there is a one-to-many association between addresses and destinations (multicast has groups) on the

network Each destination address identifi es a set of receiver endpoints, but (in contrast

to multicast) only one of them (determined to be the “nearest” or the “best”) is chosen

at any particular time to receive information from a particular sender For example, in contrast to a broadcast (which goes to everyone) or a multicast (which goes to all inter-ested listeners) sent onto a LAN, a message to an anycast address goes to only one of a set of hosts and is then considered delivered Anycast (“send this to any one of these”)

is more suited to connectionless protocols (such as UDP) than stateful protocols (such

as TCP) that have to maintain state information

Root server operators often struggle to overcome a lot of misconceptions, even on the part of people who should know better Contrary to what some believe, all Internet

traffi c does not fl ow through the root servers (nor do they determine routes), not every DNS query goes to a root server, the “A” system is not special, and there are many more than just 13 machines.

Table 19.1 DNS Root Servers Listed by Operator, Locations, and IP Address

B Information Sciences Institute Marina Del Rey, CA

C Cogent Communications Herndon, VA; Los Angeles; New York; Chicago

D University of Maryland College Park, MD

E NASA Ames Research Center Mountain View, CA

F Internet Systems Consortium, Inc 43 sites all over the world

H U.S Army Research Lab Aberdeen, MD

I Autonomica/NORDUnet 31 sites all over the world

K Réseaux IP Européens–Network

Coordination Center

17 sites all over the world