* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Ralph`s DHCP #2a
Survey
Document related concepts
Wake-on-LAN wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
SIP extensions for the IP Multimedia Subsystem wikipedia , lookup
Distributed firewall wikipedia , lookup
Wireless security wikipedia , lookup
Server Message Block wikipedia , lookup
Extensible Authentication Protocol wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Hypertext Transfer Protocol wikipedia , lookup
Remote Desktop Services wikipedia , lookup
Transcript
The Future of DHCP Dr. Ralph Droms Bucknell University Futures Draft Standard status New options DHCP and DNS Inter-server protocol Authentication DHCPv6 DHCP to “Draft Standard” DHCP has been accepted as a “Draft Standard” - Rules for progression in STD 1 (currently, RFC 1920) - Multiple, independent, interoperable implementations - Sufficient time for review as ”Proposed Standard” Will be submitted for full “Standard” status New options will progress through New Options Acceptance New options must have nonoverlapping option codes Numbers handed out by Internet Assigned Numbers Authority (IANA) New mechanism approves each new option as a separate RFC (like TELNET) User Class Identifier Encodes category or type of user or applications - for example, ACCOUNTING or SALES Classes locally defined by DHCP administrator Client may specify more than one class Server interpretation is implementation dependent; policy is determined by DHCP administrator Server returns class in response so client knows if it was accepted See “The User Class Option for DHCP, “ by Stump and Droms (draft-ietf-dhc- FQDN Modifier Options that identify servers only allow for 32-bit IP addresses If servers change IP addresses, clients may not be informed FQDN (Fully Qualified Domain Name) modifier allow options to replace IP addresses with FQDNs See “An Option for FQDNs in DHCP Options,” by Rekhter and Droms (draft-ietf-dhc-fqdn-opt-03.txt) FQDN Modifier Example FQDN modifier XX 56 NIS server 41 16 LPR server LPR server 12 12 17 17 'n' 'i' 's' '.' 'b' 'u' 'c' 'k' 'n' 'e' 'l' 'l' '.' 'e' 'd' 'u' 'l' 'p' 'r' '1' '.' 'b' 'u' 'c' 'k' 'n' 'e' 'l' 'l' '.' 'e' 'd' 'u' 'l' 'p' 'r' '2' '.' 'b' 'u' 'c' 'n' 'e' 'l' 'l' '.' 'e' 'd' 'u' 'k' Option Extension BOOTP established 0-127 as globally defined, 128-254 as locally defined options Currently have defined roughly 80 options Option extension defines option 127 as a tag for more suboptions See “An Extension to the DHCP Option Codes,” by Droms (draft-ietfdhc-options-opt127-03.txt) Server Selection Option Client may receive multiple OFFERs and must choose one server OFFERs may not include enough information for client to make “good” choice Server selection option will include server identification on which client can base selection See “The Server Selection Option for DHCP,” by Stump and Gupta (draft-ietf-dhc-sso-00.txt) Allocation From Network With Multiple Subnets Relay agent must pick one address to put in ‘giaddr’ If there are multiple subnets on one physical network, which address should relay agent choose? - Always picking one limits flexibility in allocation - Specifying rules requires configuration of each relay agent Allocation From Network With Multiple Subnets (con’t) Server must have knowledge of network architecture and set of policies about allocating addresses based on ‘giaddr’ - Different relay agents may insert different values for ‘giaddr’ - Must be described as set of subnets that appear on same physical subnet DHCP administrator can use classing options to define allocation policy See “Subnet Selection Option for DHCP,” by Townsley (draft-ietf-dhc-subsel-00.txt) Other New Options Options for Service Location Protocol IEEE 1003.1 POSIX timezone specification Relay agent information Multicast address allocation Netware/IP and NDS Subnet selection Domain search See www.bucknell.edu/~droms/dhcp Dynamic DNS When client is allocated a new address, DNS records need to be updated - A record: Name to IP address - PTR record: IP address to name Newly defined extensions to DNS for dynamic updates allow updates through the network DHCP extended to allow coordination between client and server Inter-Server Communication Becomes a distributed database problem Windows when information managed by servers is inconsistent - Newly allocated addresses - Extended leases - Released addresses Solution - look at those windows carefully - Determine which are really a Windows Newly allocated address, not yet propagated to other servers - Other servers can’t provide redundancy - Won’t return incorrect information Extended lease, not yet propagated to other servers - Client can choose longest outstanding lease - Early expiration simply implies server discards lease from database Released lease, not yet propagated to other servers Reusing Addresses When reusing an address, must be very careful to ensure that it is not in use All servers must be polled to make sure there are no outstanding leases In response to a RELEASE, server informs all other servers to terminate that lease - Server can’t reuse until all other servers have been polled Inter-Server Protocol “An Inter-server Protocol for DHCP,” by Kinnear, Cole and Droms (draftietf-interserver-02.txt) addresses the “windows” Based on the Server Cache Synchronization Protocol (draft-ietfion-scsp-01.txt) - From IP-over-ATM (ION) WG - Used for, e.g., ATMARP Currently under discussion in WG Security / Authentication Unauthorized - either intentional or accidental - server can cause denial of service problems - Server authentication allows clients to discard messages from bogus servers Some sites may want to limit IP address allocation to authorized client - Client authentication allows servers Security / Authentication (con’t) Authentication based on shared private key, an authentication ticket and a message digest Assures source of message is valid and message hasn’t been tampered with en route ‘giaddr’ causes problems with endto-end IP security Security / Authentication (con’t) Alternative 1: simple cleartext identifier in message Alternative 2: shared secret between server and client (Schiller/Huitema) Alternative 3: public key exchange (Gudmundsson) Change Management Many new options have been proposed Some make fundamental changes to DHCP as interpreted by client and server Others involve new data types (e.g., FQDN) Each change requires development and deployment of new software DHCPv2 ? “Freeze” DHCP at present state and study process for developing new options Define and deploy new option set - Accommodate data typing for options that may carry multiple types - Use new “cookie” value to identify new syntax IPv6 IP Version 6 (aka IPv6 or IPng) is a new internet protocol to replace IP Includes new features for host configuration: - Router advertisement - Autoconfiguration - Link-local addresses To accommodate sites that want centralized management of addresses, DHCP for IPv6 (DHCPv6) is being developed by the DHC WG. DHCPv6 DHCPv6 client uses link-local address to find relay agent and server Client puts relay agent and server addresses in request - avoids relay agent modifying message - client must perform PMTU fragmentation Client can request multiple addresses from server - May use DHCPv6 more than once to Reconfiguring IPv6 Clients IPv6 accommodates dynamic renumbering Server may need to force clients to reconfirm current addresses RECONFIGURE message tells client to contact server for new configuration information Summary DHCP works today as a tool for automatic configuration of TCP/IP hosts It is an open Internet standard and interoperable client implementations are widely available Ongoing work will extend DHCP with authentication, DHCP-DNS interaction and inter-server communication