Dynamic Host Configuration Protocol

From Wikipedia, the free encyclopedia - View original article

 
  (Redirected from DHCP)
Jump to: navigation, search
A DHCP Server settings tab

The Dynamic Host Configuration Protocol (DHCP) is a standardized networking protocol used by servers on an IP network to allocate IP addresses to computers. The purpose of DHCP is to automate the IP address configuration of a computer without a network administrator. IP addresses are typically selected from a range of assigned IP addresses stored in a database on the server and issued to a computer which requests a new IP address. An IP address is assigned to a computer for a set interval, after which, the computer must renew the IP address or acquire a new one.

Overview[edit]

Non-technical[edit]

DHCP allows computers (clients) to be assigned settings from a server in a client-server model. DHCP is very common in modern networks[1] and is used in home networks as well as larger campus networks. In home networks, the Internet Service Provider's server may assign a globally unique external IP address to a home router (or modem) and this IP address is used in Internet communications. The home router (or modem) may also use DHCP to supply a usable IP address to devices connected to the home network, allowing these devices to communicate on The Internet. The global unique IP address assigned by the Internet Service Provider (ISP) is different from any of the IP addresses assigned to the devices connected to the home router.[2] This is because of a design consideration of IPv4 to help conserve IPv4 addresses.

Technical[edit]

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 makes 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 to 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. Upon disconnecting, the IP address is returned to the pool for use by another computer. This way, many other computers can use the same IP address within minutes of each other.

Because the DHCP protocol must work correctly even before DHCP clients have been configured, the DHCP server and DHCP client usually must be connected to the same network link. In larger networks, this is not practical. On such networks, each network link contains one or more DHCP relay agents. These DHCP relay agents receive messages from DHCP clients and forward them to DHCP servers. DHCP servers send responses back to the relay agent, and the relay agent then sends these responses to the DHCP client on the local network link.

Depending on implementation, the DHCP server may have three methods of allocating IP-addresses:

History[edit]

DHCP was first defined as a standards track protocol in RFC 1531 in October 1993, as an extension to the Bootstrap Protocol (BOOTP). The motivation for extending BOOTP was that BOOTP required manual intervention to add configuration information for each client, and did not provide a mechanism for reclaiming unused IP addresses. This means that connecting a computer to the internet was a manual process.[3]

Many worked to clarify the protocol as it gained popularity, and in 1997 RFC 2131 was released, and remains as of 2011 the standard for IPv4 networks. DHCPv6 is documented in RFC 3315. RFC 3633 added a DHCPv6 mechanism for prefix delegation. DHCPv6 was further extended to provide configuration information to clients configured using stateless address autoconfiguration in RFC 3736.

The BOOTP protocol itself was first defined in RFC 951 as a replacement for the Reverse Address Resolution Protocol RARP. The primary motivation for replacing RARP with BOOTP was that RARP was a data link layer protocol. This made implementation difficult on many server platforms, and required that a server be present on each individual network link. BOOTP introduced the innovation of a relay agent, which allowed the forwarding of BOOTP packets off the local network using standard IP routing, thus one central BOOTP server could serve hosts on many IP subnets.[4]

Example[edit]

An example of use of the protocol is in a residential local area network (LAN). In this case, a DHCP server is contained in the router[5] while the clients are hosts, e.g., personal computers, smart phones, or printers on the local network. The router itself is a client within the network of the Internet service provider (ISP) and receives its configuration information upstream from the ISP's DHCP server.

IP protocols[edit]

DHCP is used for Internet Protocol version 4 (IPv4), as well as IPv6. While both versions serve the same purpose, the details of the protocol for IPv4 and IPv6 are sufficiently different that they may be considered separate protocols.[6] IPv6 devices may alternatively use stateless address autoconfiguration. IPv4 hosts may use link-local addressing to achieve limited local connectivity.

Technical details[edit]

DHCP uses the same two ports assigned by IANA for BOOTP: destination UDP port 67 for sending data to the server, and UDP port 68 for data to the client. DHCP communications are connectionless in nature.

DHCP operations fall into four basic phases: IP discovery, IP lease offer, IP request, and IP lease acknowledgment. These points are often abbreviated as DORA for discovery, offer, request, and acknowledgment.

DHCP clients and servers on the same subnet communicate via UDP broadcasts, initially. If the client and server are on different subnets, a DHCP Helper or DHCP Relay Agent may be used. Clients requesting renewal of an existing lease may communicate directly via UDP unicast, since the client already has an established IP address at that point.

DHCP discovery[edit]

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 which resides on 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 may 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.

DHCPDISCOVER
UDP Src=0.0.0.0 sPort=68
Dest=255.255.255.255 dPort=67
OPHTYPEHLENHOPS
0x010x010x060x00
XID
0x3903F326
SECSFLAGS
0x00000x0000
CIADDR (Client IP Address)
0x00000000
YIADDR (Your IP Address)
0x00000000
SIADDR (Server IP Address)
0x00000000
GIADDR (Gateway IP Address)
0x00000000
CHADDR (Client Hardware Address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s, or overflow space for additional options. BOOTP legacy
Magic Cookie
0x63825363
DHCP Options
DHCP option 53: DHCP Discover
DHCP option 50: 192.168.1.100 requested
DHCP option 55: Parameter Request List:

Request Subnet Mask (1), Router (3), Domain Name (15), Domain Name Server (6)

DHCP offer[edit]

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 client's IP address in the YIADDR (Your IP Address) field.

DHCPOFFER
UDP Src=192.168.1.1 sPort=67
Dest=Client's IP Address | dPort=68
OPHTYPEHLENHOPS
0x020x010x060x00
XID
0x3903F326
SECSFLAGS
0x00000x0000
CIADDR (Client IP Address)
0x00000000
YIADDR (Your IP Address)
0xC0A80164
SIADDR (Server IP Address)
0xC0A80101
GIADDR (Gateway IP Address)
0x00000000
CHADDR (Client Hardware Address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s. 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

DHCP request[edit]

In response to the DHCP offer, the client replies with a DHCP request, broadcast to the server, requesting the offered address. A client can receive DHCP offers from multiple servers, but it will accept only one DHCP offer. Based on required server identification option in the request and broadcast messaging, servers are informed whose offer the client has accepted.[7] 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.

DHCPREQUEST
UDP Src=0.0.0.0 sPort=68
Dest=255.255.255.255 dPort=67
OPHTYPEHLENHOPS
0x010x010x060x00
XID
0x3903F326
SECSFLAGS
0x00000x0000
CIADDR (Client IP Address)
0x00000000
YIADDR (Your IP Address)
0x00000000
SIADDR (Server IP Address)
0xC0A80101
GIADDR (Gateway IP Address)
0x00000000
CHADDR (Client Hardware Address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s. BOOTP legacy
Magic Cookie
0x63825363
DHCP Options
DHCP option 53: DHCP Request
DHCP option 50: 192.168.1.100 requested
DHCP option 54: 192.168.1.1 DHCP server.

DHCP acknowledgement[edit]

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.

DHCPACK
UDP Src=192.168.1.1 sPort=67
Dest=255.255.255.255 dPort=68
OPHTYPEHLENHOPS
0x020x010x060x00
XID
0x3903F326
SECSFLAGS
0x00000x0000
CIADDR (Client IP Address)
0x00000000
YIADDR (Your IP Address)
0xC0A80164
SIADDR (Server IP Address)
0xC0A80101
GIADDR (Gateway IP Address switched by relay)
0x00000000
CHADDR (Client Hardware Address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s. BOOTP legacy
Magic Cookie
0x63825363
DHCP Options
DHCP option 53: DHCP ACK
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.

DHCP information[edit]

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.

DHCP releasing[edit]

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.

Client configuration parameters in DHCP[edit]

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.[8]

A DHCP client can select, manipulate and overwrite parameters provided by a DHCP server.[9]

DHCP options[edit]

Options are variable length octet strings. The first octet is the option code, the second octet is the number of following octets and the remaining octets are code dependent. For example, the DHCP Message type option for an Offer would appear as 0x35,0x01,0x02, where 0x35 is code 53 for "DHCP Message Type", 0x01 means one octet follows and 0x02 is the value of "Offer".

The following tables list the available DHCP options, as stated in RFC2132.[10]

RFC1497 vendor extensions[10]:Section 3
CodeNameLengthNotes
0Pad[10]:Section 3.11 octetCan be used to pad other options so that they are aligned to the word boundary
1Subnet Mask[10]:Section 3.34 octetsMust be sent after the router option (option 3) if both are included
2Time Offset[10]:Section 3.44 octets
3Routermultiples of 4 octetsAvailable routers, should be listed in order of preference
4Time Servermultiples of 4 octetsAvailable time servers to synchronise with, should be listed in order of preference
5Name Servermultiples of 4 octetsAvailable IEN116 name servers, should be listed in order of preference
6Domain Name Servermultiples of 4 octetsAvailable DNS servers, should be listed in order of preference
7Log Servermultiples of 4 octetsAvailable log servers, should be listed in order of preference.
8Cookie Servermultiples of 4 octets
9LPR Servermultiples of 4 octets
10Impress Servermultiples of 4 octets
11Resource Location Servermultiples of 4 octets
12Host Nameminimum of 1 octet
13Boot File Size2 octetsLength of the boot image in 4KiB blocks
14Merit Dump Fileminimum of 1 octetPath where crash dumps should be stored
15Domain Nameminimum of 1 octet
16Swap Server4 octets
17Root Pathminimum of 1 octet
18Extensions Pathminimum of 1 octet
255End0 octetsUsed to mark the end of the vendor option field
IP Layer Parameters per Host[10]:Section 4
CodeNameLengthNotes
19IP Forwarding Enable/Disable1 octet
20Non-Local Source Routing Enable/Disable1 octet
21Policy Filtermultiples of 8 octets
22Maximum Datagram Reassembly Size2 octets
23Default IP Time-to-live1 octet
24Path MTU Aging Timeout4 octets
25Path MTU Plateau Tablemultiples of 2 octets
IP Layer Parameters per Interface[10]:Section 5
CodeNameLengthNotes
26Interface MTU2 octets
27All Subnets are Local1 octet
28Broadcast Address4 octets
29Perform Mask Discovery1 octet
30Mask Supplier1 octet
31Perform Router Discovery1 octet
32Router Solicitation Address4 octets
33Static Routemultiples of 8 octetsA list of destination/router pairs
Link Layer Parameters per Interface[10]:Section 6
CodeNameLengthNotes
34Trailer Encapsulation Option1 octet
35ARP Cache Timeout4 octets
36Ethernet Encapsulation1 octet
TCP Parameters[10]:Section 7
CodeNameLengthNotes
37TCP Default TTL1 octet
38TCP Keepalive Interval4 octets
39TCP Keepalive Garbage1 octet
Application and Service Parameters[10]:Section 8
CodeNameLengthNotes
40Network Information Service Domainminimum of 1 octet
41Network Information Serversmultiples of 4 octets
42Network Time Protocol Serversmultiples of 4 octets
43Vendor Specific Informationminimum of 1 octets
44NetBIOS over TCP/IP Name Servermultiples of 4 octets
45NetBIOS over TCP/IP Datagram Distribution Servermultiples of 4 octets
46NetBIOS over TCP/IP Node Type1 octet
47NetBIOS over TCP/IP Scopeminimum of 1 octet
48X Window System Font Servermultiples of 4 octets
49X Window System Display Managermultiples of 4 octets
64Network Information Service+ Domainminimum of 1 octet
65Network Information Service+ Serversmultiples of 4 octets
68Mobile IP Home Agentmultiples of 4 octets
69Simple Mail Transport Protocol (SMTP) Servermultiples of 4 octets
70Post Office Protocol (POP3) Servermultiples of 4 octets
71Network News Transport Protocol (NNTP) Servermultiples of 4 octets
72Default World Wide Web (WWW) Server)multiples of 4 octets
73Default Finger Servermultiples of 4 octets
74Default Internet Relay Chat (IRC) Servermultiples of 4 octets
75StreetTalk Servermultiples of 4 octets
76StreetTalk Directory Assistance (STDA) Servermultiples of 4 octets
DHCP Extensions[10]:Section 9
CodeNameLengthNotes
50Requested IP Address4 octets
51IP Address Lease Time4 octets
52Option Overload1 octet
53DHCP Message Type1 octet
54Server Identifier4 octets
55Parameter Request Listminimum of 1 octet
56Messageminimum of 1 octet
57Maximum DHCP Message Size2 octets
58Renewal (T1) Time Value4 octets
59Rebinding (T2) Time Value4 octets
60Vendor class identifierminimum of 1 octet
61Client-identifierminimum of 2 octets
66TFTP server nameminimum of 1 octet
67Bootfile nameminimum of 1 octet

Vendor identification[edit]

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 this option is set to gives the DHCP server a hint about any required extra information that this client needs in a DHCP response.

DHCP relaying[edit]

In small networks, where only one IP subnet is being managed, DHCP clients communicate directly with DHCP servers. However, DHCP servers can also provide IP addresses for multiple subnets. In this case, a DHCP client that has not yet acquired an IP address cannot communicate directly with the DHCP server using IP routing, because it doesn't have a routable IP address, nor does it know the IP address of a router. In order to allow DHCP clients on subnets not directly served by DHCP servers to communicate with DHCP servers, DHCP relay agents can be installed on these subnets. The DHCP client broadcasts on the local link; the relay agent receives the broadcast and transmits it to one or more DHCP servers using unicast. The relay agent stores its own IP address in the GIADDR field of the DHCP packet. The DHCP server uses the GIADDR to determine the subnet on which the relay agent received the broadcast, and allocates an IP address on that subnet. When the DHCP server replies to the client, it sends the reply to the GIADDR address, again using unicast. The relay agent then retransmits the response on the local network.

Reliability[edit]

The DHCP protocol provides reliability in several ways: periodic renewal, rebinding, and failover. DHCP clients are allocated leases that last for some period of time. Clients begin to attempt to renew their leases once half the lease interval has expired. They do this by sending a unicast DHCPREQUEST message to the DHCP server that granted the original lease. If that server is down or unreachable, it will fail to respond to the DHCPREQUEST. However, the DHCPREQUEST will be repeated by the client from time to time,[specify] so when the DHCP server comes back up or becomes reachable again, the DHCP client will succeed in contacting it, and renew its lease.

If the DHCP server is unreachable for an extended period of time,[specify] the DHCP client will attempt to rebind, by broadcasting its DHCPREQUEST rather than unicasting it. Because it is broadcast, the DHCPREQUEST message will reach all available DHCP servers. If some other DHCP server is able to renew the lease, it will do so at this time.

In order for rebinding to work, when the client successfully contacts a backup DHCP server, that server must have accurate information about the client's binding. Maintaining accurate binding information between two servers is a complicated problem; if both servers are able to update the same lease database, there must be a mechanism to avoid conflicts between updates on the independent servers. A standard for implementing fault-tolerant DHCP servers was developed at the Internet Engineering Task Force.[11][note 1]

If rebinding fails, the lease will eventually expire. When the lease expires, the client must stop using the IP address granted to it in its lease. At that time, it will restart the DHCP process from the beginning by broadcasting a DHCPDISCOVER message. Since its lease has expired, it will accept any IP address offered to it. Once it has a new IP address, presumably from a different DHCP server, it will once again be able to use the network. However, since its IP address has changed, any ongoing connections will be broken.

Security[edit]

The base DHCP protocol does not include any mechanism for authentication.[12] Because of this, it is vulnerable to a variety of attacks. These attacks fall into three main categories:

Because the client has no way to validate the identity of a DHCP server, unauthorized DHCP servers (commonly called "rougue DHCP") can be operated on networks, providing incorrect information to DHCP clients.[14] This can serve either as a denial-of-service attack, preventing the client from gaining access to network connectivity,[15] or as a man-in-the-middle attack.[16] Because the DHCP server provides the DHCP client with server IP addresses, such as the IP address of one or more DNS servers,[13] an attacker can convince a DHCP client to do its DNS lookups through its own DNS server, and can therefore provide its own answers to DNS queries from the client.[17] This in turn allows the attacker to redirect network traffic through itself, allowing it to eavesdrop on connections between the client and network servers it contacts, or to simply replace those network servers with its own.[17]

Because the DHCP server has no secure mechanism for authenticating the client, clients can gain unauthorized access to IP addresses by presenting credentials, such as client identifiers, that belong to other DHCP clients.[14] This also allows DHCP clients to exhaust the DHCP server's store of IP addresses—by presenting new credentials each time it asks for an address, the client can consume all the available IP addresses on a particular network link, preventing other DHCP clients from getting service.[14]

DHCP does provide some mechanisms for mitigating these problems. The Relay Agent Information Option protocol extension (RFC 3046, usually referred to in the industry by its actual number as Option 82[18][19]) allows network operators to attach tags to DHCP messages as these messages arrive on the network operator's trusted network. This tag is then used as an authorization token to control the client's access to network resources. Because the client has no access to the network upstream of the relay agent, the lack of authentication does not prevent the DHCP server operator from relying on the authorization token.[12]

Another extension, Authentication for DHCP Messages (RFC 3118), provides a mechanism for authenticating DHCP messages. Unfortunately RFC 3118 has not seen (as of 2002) widespread adoption because of the problems of managing keys for large numbers of DHCP clients.[20] A 2007 book about DSL technologies remarked that "there were numerous security vulnerabilities identified against the security measures proposed by RFC 3118. This fact, combined with the introduction of 802.1x, slowed the deployment and take-rate of authenticated DHCP, and it has never been widely deployed."[21] A 2010 book notes that "[t]here have been very few implementations of DHCP Authentication. The challenged of key management and processing delyas due to hash computation have been deemed too heavy a price to pay for the perceived benefits."[22]

More recent (2008) architectural proposals involve authenticating DHCP requests using 802.1x or PANA (both of which transport EAP).[23] An IETF proposal was made for including EAP in DHCP itself, the so-called EAPoDHCP;[24] this does not appear to have progressed beyond IETF draft level, the last of which dates to 2010.[25]

Confidentiality[edit]

In an ISP context, DHCP logs of address assignments either contain or are linked to personally identifying confidential information, the contact details of the client. These are attractive to spammers, and may be sought for "fishing expeditions" by police agencies or litigators. At least one implementation[citation needed] mimics the Canadian Library Association policy for book circulation and does not retain identifying information once the "loan" has ended.

See also[edit]

Notes[edit]

  1. ^ The IETF proposal provided a mechanism whereby two servers could remain loosely in sync with each other in such a way that even in the event of a total failure of one server, the other server could recover the lease database and continue operating. Due to the length and complexity of the specification, it was never published as a standard; however, the techniques described in the specification are in wide use, with one open source implementation in the ISC DHCP server as well as several commercial implementations.

References[edit]

  1. ^ Peterson LL, Davie BS. (2011). Computer Networks: A Systems Approach.
  2. ^ What is the difference between a public and private IP address?. Slingbox Support.
  3. ^ What is DHCP?. whatismyipaddress.com.
  4. ^ Bill Croft; John Gilmore (September 1985). "RFC 951 - Bootstrap Protocol". Network Working Group. 
  5. ^ What is DHCP?. whatismyip.com.
  6. ^ Ralph Droms; Ted Lemon (2003). The DHCP Handbook. SAMS Publishing. p. 436. ISBN 0-672-32327-3. 
  7. ^ RFC 2131 section 3.1, item 3
  8. ^ "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters". Iana.org. Retrieved 2013-11-28. 
  9. ^ In Unix-like systems this client-level refinement typically takes place according to the values in a /etc/dhclient.conf configuration file.
  10. ^ a b c d e f g h i j k Alexander, Steve; Droms, Ralph (March 1997). DHCP Options and BOOTP Vendor Extensions. IETF. RFC 2132. https://tools.ietf.org/html/rfc2132. Retrieved June 10, 2012.
  11. ^ Droms, Ralph; Kinnear, Kim; Stapp, Mark; Volz, Bernie; Gonczi, Steve; Rabil, Greg; Dooley, Michael; Kapur, Arun (March 2003). DHCP Failover Protocol. IETF. I-D draft-ietf-dhc-failover-12. https://tools.ietf.org/html/draft-ietf-dhc-failover-12. Retrieved May 09, 2010.
  12. ^ a b Michael Patrick (January 2001). "RFC 3046 - DHCP Relay Agent Information Option". Network Working Group. 
  13. ^ a b c d Ralph Droms (March 1997). "RFC 2131 - Dynamic Host Configuration Protocol". Network Working Group. 
  14. ^ a b c Timothy Stapko (2011). Practical Embedded Security: Building Secure Resource-Constrained Systems. Newnes. p. 39. ISBN 978-0-08-055131-9. 
  15. ^ Derrick Rountree (2013). Windows 2012 Server Network Security: Securing Your Windows Network Systems and Infrastructure. Newnes. p. 22. ISBN 978-1-59749-965-1. 
  16. ^ Timothy Rooney (2010). Introduction to IP Address Management. John Wiley & Sons. p. 180. ISBN 978-1-118-07380-3. 
  17. ^ a b Sergey Golovanov (Kaspersky Labs) (June 2011). "TDSS loader now got "legs"". 
  18. ^ Francisco J. Hens; José M. Caballero (2008). Triple Play: Building the converged network for IP, VoIP and IPTV. John Wiley & Sons. p. 239. ISBN 978-0-470-75439-9. 
  19. ^ David H. Ramirez (2008). IPTV Security: Protecting High-Value Digital Contents. John Wiley & Sons. p. 55. ISBN 978-0-470-72719-5. 
  20. ^ Ted Lemon (April 2002). "Implementation of RFC 3118". 
  21. ^ Philip Golden; Hervé Dedieu; Krista S. Jacobsen (2007). Implementation and Applications of DSL Technology. Taylor & Francis. p. 484. ISBN 978-1-4200-1307-8. 
  22. ^ Timothy Rooney (2010). Introduction to IP Address Management. John Wiley & Sons. pp. 181–182. ISBN 978-1-118-07380-3. 
  23. ^ Rebecca Copeland (2008). Converging NGN Wireline and Mobile 3G Networks with IMS. Taylor & Francis. pp. 142–143. ISBN 978-1-4200-1378-8. 
  24. ^ Ramjee Prasad; Albena Mihovska (2009). New Horizons in Mobile and Wireless Communications: Networks, services, and applications 2. Artech House. p. 339. ISBN 978-1-60783-970-5. 
  25. ^ http://tools.ietf.org/search/draft-pruss-dhcp-auth-dsl-07

External links[edit]