diff options
Diffstat (limited to 'doc/rfc/rfc4702.txt')
| -rw-r--r-- | doc/rfc/rfc4702.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc4702.txt b/doc/rfc/rfc4702.txt new file mode 100644 index 0000000..609d99f --- /dev/null +++ b/doc/rfc/rfc4702.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group M. Stapp +Request for Comments: 4702 B. Volz +Category: Standards Track Cisco Systems, Inc. + Y. Rekhter + Juniper Networks + October 2006 + + + The Dynamic Host Configuration Protocol (DHCP) Client + Fully Qualified Domain Name (FQDN) Option + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document describes a Dynamic Host Configuration Protocol for + IPv4 (DHCPv4) option that can be used to exchange information about a + DHCPv4 client's fully qualified domain name and about responsibility + for updating the DNS RR related to the client's address assignment. + + + + + + + + + + + + + + + + + + + + + + +Stapp, et al. Standards Track [Page 1] + +RFC 4702 The DHCP Client FQDN Option October 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Terminology ................................................3 + 1.2. Models of Operation ........................................3 + 2. The Client FQDN Option ..........................................4 + 2.1. The Flags Field ............................................5 + 2.2. The RCODE Fields ...........................................6 + 2.3. The Domain Name Field ......................................6 + 2.3.1. Deprecated ASCII Encoding ...........................7 + 3. DHCP Client Behavior ............................................7 + 3.1. Interaction with Other Options .............................7 + 3.2. Client Desires to Update A RRs .............................8 + 3.3. Client Desires Server to Do DNS Updates ....................8 + 3.4. Client Desires No Server DNS Updates .......................8 + 3.5. Domain Name and DNS Update Issues ..........................9 + 4. DHCP Server Behavior ...........................................10 + 4.1. When to Perform DNS Updates ...............................11 + 5. DNS RR TTLs ....................................................12 + 6. DNS Update Conflicts ...........................................12 + 7. IANA Considerations ............................................13 + 8. Security Considerations ........................................13 + 9. Acknowledgements ...............................................14 + 10. References ....................................................14 + 10.1. Normative References .....................................14 + 10.2. Informative References ...................................15 + + + + + + + + + + + + + + + + + + + + + + + + + +Stapp, et al. Standards Track [Page 2] + +RFC 4702 The DHCP Client FQDN Option October 2006 + + +1. Introduction + + DNS ([2], [3]) maintains (among other things) the information about + the mapping between hosts' Fully Qualified Domain Names (FQDNs) [11] + and IP addresses assigned to the hosts. The information is + maintained in two types of Resource Records (RRs): A and PTR. The + DNS update specification ([4]) describes a mechanism that enables DNS + information to be updated over a network. + + The Dynamic Host Configuration Protocol for IPv4 (DHCPv4 or just DHCP + in this document) [5] provides a mechanism by which a host (a DHCP + client) can acquire certain configuration information, along with its + address. This document specifies a DHCP option, the Client FQDN + option, which can be used by DHCP clients and servers to exchange + information about the client's fully qualified domain name for an + address and who has the responsibility for updating the DNS with the + associated A and PTR RRs. + +1.1. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [1]. + +1.2. Models of Operation + + When a DHCP client acquires a new address, a site's administrator may + desire that one or both of the A RR for the client's FQDN and the PTR + RR for the acquired address be updated. Therefore, two separate DNS + update transactions may occur. Acquiring an address via DHCP + involves two entities: a DHCP client and a DHCP server. In + principle, each of these entities could perform none, one, or both of + the transactions. However, in practice, not all permutations make + sense. The DHCP Client FQDN option is primarily intended to operate + in the following two cases: + + 1. DHCP client updates the A RR, DHCP server updates the PTR RR. + + 2. DHCP server updates both the A and the PTR RRs. + + The only difference between these two cases is whether the FQDN-to- + IP-address mapping is updated by a DHCP client or by a DHCP server. + The IP-address-to-FQDN mapping is updated by a DHCP server in both + cases. + + The reason these two are important, while others are unlikely, has to + do with authority over the respective DNS domain names. A DHCP + client may be given authority over mapping its own A RRs, or that + + + +Stapp, et al. Standards Track [Page 3] + +RFC 4702 The DHCP Client FQDN Option October 2006 + + + authority may be restricted to a server to prevent the client from + listing arbitrary addresses or associating its address with arbitrary + domain names. In all cases, the only reasonable place for the + authority over the PTR RRs associated with the address is in the DHCP + server that allocates the address. + + Note: A third case is supported: the client requests that the server + perform no updates. However, this case is presumed to be rare + because of the authority issues. + + It is considered local policy to permit DHCP clients and servers to + perform DNS updates to zones. This document does not require any + specific administrative policy and does not propose one. + Furthermore, this specification applies only to DHCP client and + server processes; it does not apply to other processes that initiate + DNS updates. + + This document describes a DHCP option which a client can use to + convey all or part of its domain name to a DHCP server. Site- + specific policy determines whether DHCP servers use the names that + clients offer or not, and what DHCP servers may do in cases where + clients do not supply domain names. + +2. The Client FQDN Option + + To update the IP-address-to-FQDN mapping, a DHCP server needs to know + the FQDN of the client to which the server leases the address. To + allow the client to convey its FQDN to the server, this document + defines a new DHCP option, called "Client FQDN". The Client FQDN + option also contains Flags, which DHCP servers can use to convey + information about DNS updates to clients, and two deprecated RCODEs. + + Clients MAY send the Client FQDN option, setting appropriate Flags + values, in both their DHCPDISCOVER and DHCPREQUEST messages. If a + client sends the Client FQDN option in its DHCPDISCOVER message, it + MUST send the option in subsequent DHCPREQUEST messages though the + contents of the option MAY change. + + Only one Client FQDN option MAY appear in a message, though it may be + instantiated in a message as multiple options [9]. DHCP clients and + servers supporting this option MUST implement DHCP option + concatenation [9]. In the terminology of [9], the Client FQDN option + is a concatenation-requiring option. + + The code for this option is 81. Len contains the number of octets + that follow the Len field, and the minimum value is 3 (octets). + + + + + +Stapp, et al. Standards Track [Page 4] + +RFC 4702 The DHCP Client FQDN Option October 2006 + + + The format of the Client FQDN option is: + + Code Len Flags RCODE1 RCODE2 Domain Name + +------+------+------+------+------+------+-- + | 81 | n | | | | ... + +------+------+------+------+------+------+-- + + The above figure follows the conventions of [12]. + +2.1. The Flags Field + + The format of the 1-octet Flags field is: + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | MBZ |N|E|O|S| + +-+-+-+-+-+-+-+-+ + + The "S" bit indicates whether the server SHOULD or SHOULD NOT perform + the A RR (FQDN-to-address) DNS updates. A client sets the bit to 0 + to indicate the server SHOULD NOT perform the updates and 1 to + indicate the server SHOULD perform the updates. The state of the bit + in the reply from the server indicates the action to be taken by the + server; if 1, the server has taken responsibility for A RR updates + for the FQDN. + + The "O" bit indicates whether the server has overridden the client's + preference for the "S" bit. A client MUST set this bit to 0. A + server MUST set this bit to 1 if the "S" bit in its reply to the + client does not match the "S" bit received from the client. + + The "N" bit indicates whether the server SHOULD NOT perform any DNS + updates. A client sets this bit to 0 to request that the server + SHOULD perform updates (the PTR RR and possibly the A RR based on the + "S" bit) or to 1 to request that the server SHOULD NOT perform any + DNS updates. A server sets the "N" bit to indicate whether the + server SHALL (0) or SHALL NOT (1) perform DNS updates. If the "N" + bit is 1, the "S" bit MUST be 0. + + The "E" bit indicates the encoding of the Domain Name field. 1 + indicates canonical wire format, without compression, as described in + [3], Section 3.1. This encoding SHOULD be used by clients and MUST + be supported by servers. 0 indicates a now-deprecated ASCII encoding + (see Section 2.3.1). A server MUST use the same encoding as that + + + + + + + +Stapp, et al. Standards Track [Page 5] + +RFC 4702 The DHCP Client FQDN Option October 2006 + + + used by the client. A server that does not support the deprecated + ASCII encoding MUST ignore Client FQDN options that use that + encoding. + + The remaining bits in the Flags field are reserved for future + assignment. DHCP clients and servers that send the Client FQDN + option MUST clear the MBZ bits, and they MUST ignore these bits. + +2.2. The RCODE Fields + + The two 1-octet RCODE1 and RCODE2 fields are deprecated. A client + SHOULD set these to 0 when sending the option and SHOULD ignore them + on receipt. A server SHOULD set these to 255 when sending the option + and MUST ignore them on receipt. + + As this option with these fields is already in wide use, the fields + are retained. These fields were originally defined for use by a DHCP + server to indicate to a DHCP client the Response Code from any A + (RCODE1) or PTR (RCODE2) RR DNS updates it has performed, or a value + of 255 was used to indicate that an update had been initiated but had + not yet completed. Each of these fields is one octet long. These + fields were defined before EDNS0 [13], which describes a mechanism + for extending the length of a DNS RCODE to 12 bits, which is another + reason to deprecate them. + + If the client needs to confirm that the DNS update has been done, it + MAY use a DNS query to check whether the mapping is up to date. + However, depending on the load on the DHCP and DNS servers and the + DNS propagation delays, the client can only infer success. If the + information is not found to be up to date in DNS, the authoritative + servers might not have completed the updates or zone transfers, or + caching resolvers may yet have updated their caches. + +2.3. The Domain Name Field + + The Domain Name part of the option carries all or part of the FQDN of + a DHCP client. The data in the Domain Name field SHOULD appear in + canonical wire format as specified in [3], Section 3.1. If the DHCP + client uses the canonical wire format, it MUST set the "E" bit in the + Flags field to 1. In order to determine whether the FQDN has changed + between message exchanges, the client and server MUST NOT alter the + Domain Name field contents unless the FQDN has actually changed. + + A client MAY be configured with a fully qualified domain name or with + a partial name that is not fully qualified. If a client knows only + part of its name, it MAY send a name that is not fully qualified, + indicating that it knows part of the name but does not necessarily + know the zone in which the name is to be embedded. + + + +Stapp, et al. Standards Track [Page 6] + +RFC 4702 The DHCP Client FQDN Option October 2006 + + + To send a fully qualified domain name, the Domain Name field is set + to the DNS-encoded domain name including the terminating zero-length + label. To send a partial name, the Domain Name field is set to the + DNS encoded domain name without the terminating zero-length label. + + A client MAY also leave the Domain Name field empty if it desires the + server to provide a name. + +2.3.1. Deprecated ASCII Encoding + + A substantial population of clients implemented an earlier draft of + this specification, which permitted an ASCII encoding of the Domain + Name field. Server implementations SHOULD be aware that clients that + send the Client FQDN option with the "E" bit set to 0 are using an + ASCII encoding of the Domain Name field. Servers MAY be prepared to + return an ASCII-encoded version of the Domain Name field to such + clients. Servers that are not prepared to return an ASCII-encoded + version MUST ignore the Client FQDN option if the "E" bit is 0. The + use of ASCII encoding in this option SHOULD be considered deprecated. + + A DHCP client that used ASCII encoding was permitted to suggest a + single label if it was not configured with a fully qualified name. + Such clients send a single label as a series of ASCII characters in + the Domain Name field, excluding the "." (dot) character. + + Clients and servers SHOULD follow the character set rules of [6], + fourth section ("Assumptions"), first 5 sentences, as modified by + [7], Section 2.1. However, implementers SHOULD also be aware that + some client software may send data intended to be in other character + sets. This specification does not require support for other + character sets. + +3. DHCP Client Behavior + + The following describes the behavior of a DHCP client that implements + the Client FQDN option. + +3.1. Interaction with Other Options + + Other DHCP options MAY carry data that is related to the Domain Name + field of the Client FQDN option. The Host Name option [12], for + example, contains an ASCII string representation of the client's host + name. In general, a client does not need to send redundant data, and + therefore clients that send the Client FQDN option in their messages + MUST NOT also send the Host Name option. Clients that receive both + the Host Name option and the Client FQDN option from a server SHOULD + + + + + +Stapp, et al. Standards Track [Page 7] + +RFC 4702 The DHCP Client FQDN Option October 2006 + + + prefer Client FQDN option data. Section 4 instructs servers to + ignore the Host Name option in client messages that include the + Client FQDN option. + +3.2. Client Desires to Update A RRs + + If a client that owns/maintains its own FQDN wants to be responsible + for updating the FQDN-to-IP-address mapping for the FQDN and + address(es) used by the client, the client MUST include the Client + FQDN option in the DHCPREQUEST message originated by the client. A + DHCP client MAY choose to include the Client FQDN option in its + DHCPDISCOVER messages as well as its DHCPREQUEST messages. The "S", + "O", and "N" bits in the Flags field in the option MUST be 0. + + Once the client's DHCP configuration is completed (the client + receives a DHCPACK message and successfully completes a final check + on the parameters passed in the message), the client MAY originate an + update for the A RR (associated with the client's FQDN) unless the + server has set the "S" bit to 1. If the "S" is 1, the DHCP client + SHOULD NOT initiate an update for the name in the server's returned + Client FQDN option Domain Name field. However, a DHCP client that is + explicitly configured with a FQDN MAY ignore the state of the "S" bit + if the server's returned name matches the client's configured name. + +3.3. Client Desires Server to Do DNS Updates + + A client can choose to delegate the responsibility for updating the + FQDN-to-IP-address mapping for the FQDN and address(es) used by the + client to the server. In order to inform the server of this choice, + the client SHOULD include the Client FQDN option in its DHCPREQUEST + message and MAY include the Client FQDN option in its DHCPDISCOVER. + The "S" bit in the Flags field in the option MUST be 1, and the "O" + and "N" bits MUST be 0. + +3.4. Client Desires No Server DNS Updates + + A client can choose to request that the server perform no DNS updates + on its behalf. In order to inform the server of this choice, the + client SHOULD include the Client FQDN option in its DHCPREQUEST + message and MAY include the Client FQDN option in its DHCPDISCOVER. + The "N" bit in the Flags field in the option MUST be 1, and the "S" + and "O" bits MUST be 0. + + Once the client's DHCP configuration is completed (the client + receives a DHCPACK message and successfully completes a final check + on the parameters passed in the message), the client MAY originate + + + + + +Stapp, et al. Standards Track [Page 8] + +RFC 4702 The DHCP Client FQDN Option October 2006 + + + its DNS updates provided the server's "N" bit is 1. If the server's + "N" bit is 0, the server MAY perform the PTR RR updates; it MAY also + perform the A RR updates if the "S" bit is 1. + +3.5. Domain Name and DNS Update Issues + + As there is a possibility that the DHCP server is configured to + complete or replace a domain name that the client sends, the client + MAY find it useful to send the Client FQDN option in its DHCPDISCOVER + messages. If the DHCP server returns different Domain Name data in + its DHCPOFFER message, the client could use that data in performing + its own eventual A RR update, or in forming the Client FQDN option + that it sends in its DHCPREQUEST message. There is no requirement + that the client send identical Client FQDN option data in its + DHCPDISCOVER and DHCPREQUEST messages. In particular, if a client + has sent the Client FQDN option to its server, and the configuration + of the client changes so that its notion of its domain name changes, + it MAY send the new name data in a Client FQDN option when it + communicates with the server again. This MAY cause the DHCP server + to update the name associated with the PTR record and, if the server + updated the A record representing the client, to delete that record + and attempt an update for the client's current domain name. + + A client that delegates the responsibility for updating the FQDN-to- + IP-address mapping to a server will not receive any indication + (either positive or negative) from the server as to whether the + server was able to perform the update. The client MAY use a DNS + query to check whether the mapping is up to date (see Section 2.2). + + If a client releases its lease prior to the lease expiration time and + is responsible for updating its A RR, the client SHOULD delete the A + RR associated with the leased address before sending a DHCPRELEASE + message. Similarly, if a client was responsible for updating its A + RR, but is unable to renew its lease, the client SHOULD attempt to + delete the A RR before its lease expires. A DHCP client that has not + been able to delete an A RR that it added (because it has lost the + use of its DHCP IP address) SHOULD attempt to notify its + administrator, perhaps by emitting a log message. + + A client that desires to perform DNS updates to A RRs SHOULD NOT do + so if the client's address is a private address [8]. + + + + + + + + + + +Stapp, et al. Standards Track [Page 9] + +RFC 4702 The DHCP Client FQDN Option October 2006 + + +4. DHCP Server Behavior + + The following describes the behavior of a DHCP server that implements + the Client FQDN option when the client's message includes the Client + FQDN option. + + The server examines its configuration and the Flag bits in the + client's Client FQDN option to determine how to respond: + + o If the client's "E" bit is 0 and the server does not support ASCII + encoding (Section 2.3.1), the server SHOULD ignore the Client FQDN + option. + + o The server sets to 0 the "S", "O", and "N" bits in its copy of the + option it will return to the client. The server copies the + client's "E" bit. + + o If the client's "N" bit is 1 and the server's configuration allows + it to honor the client's request for no server initiated DNS + updates, the server sets the "N" bit to 1. + + o Otherwise, if the client's "S" bit is 1 and the server's + configuration allows it to honor the client's request for the + server to initiate A RR DNS updates, the server sets the "S" to 1. + If the server's "S" bit does not match the client's "S" bit, the + server sets the "O" bit to 1. + + The server MAY be configured to use the name supplied in the client's + Client FQDN option, or it MAY be configured to modify the supplied + name or to substitute a different name. The server SHOULD send its + notion of the complete FQDN for the client in the Domain Name field. + The server MAY simply copy the Domain Name field from the Client FQDN + option that the client sent to the server. The server MUST use the + same encoding format (ASCII or DNS binary encoding) that the client + used in the Client FQDN option in its DHCPDISCOVER or DHCPREQUEST, + and it MUST set the "E" bit in the option's Flags field accordingly. + + If a client sends both the Client FQDN and Host Name option, the + server SHOULD ignore the Host Name option. + + The server SHOULD set the RCODE1 and RCODE2 fields to 255 before + sending the Client FQDN message to the client in a DHCPOFFER or + DHCPACK. + + + + + + + + +Stapp, et al. Standards Track [Page 10] + +RFC 4702 The DHCP Client FQDN Option October 2006 + + +4.1. When to Perform DNS Updates + + The server SHOULD NOT perform any DNS updates if the "N" bit is 1 in + the Flags field of the Client FQDN option in the DHCPACK messages (to + be) sent to the client. However, the server SHOULD delete any RRs + that it previously added via DNS updates for the client. + + The server MAY perform the PTR RR DNS update (unless the "N" bit is + 1). + + The server MAY perform the A RR DNS update if the "S" bit is 1 in the + Flags field of the Client FQDN option in the DHCPACK message (to be) + sent to the client. + + The server MAY perform these updates even if the client's DHCPREQUEST + did not carry the Client FQDN option. The server MUST NOT initiate + DNS updates when responding to DHCPDISCOVER messages from a client. + + The server MAY perform its DNS updates (PTR RR or PTR and A RR) + before or after sending the DHCPACK message to the client. + + If the server's A RR DNS update does not complete until after the + server has replied to the DHCP client, the server's interaction with + the DNS server MAY cause the DHCP server to change the domain name + that it associates with the client. This can occur, for example, if + the server detects and resolves a domain-name conflict [10]. In such + cases, the domain name that the server returns to the DHCP client + would change between two DHCP exchanges. + + If the server previously performed DNS updates for the client and the + client's information has not changed, the server MAY skip performing + additional DNS updates. + + When a server detects that a lease on an address that the server + leases to a client has expired, the server SHOULD delete any PTR RR + that it added via DNS update. In addition, if the server added an A + RR on the client's behalf, the server SHOULD also delete the A RR. + + When a server terminates a lease on an address prior to the lease's + expiration time (for instance, by sending a DHCPNAK to a client), the + server SHOULD delete any PTR RR that it associated with the address + via DNS update. In addition, if the server took responsibility for + an A RR, the server SHOULD also delete that A RR. + + + + + + + + +Stapp, et al. Standards Track [Page 11] + +RFC 4702 The DHCP Client FQDN Option October 2006 + + +5. DNS RR TTLs + + RRs associated with DHCP clients may be more volatile than statically + configured RRs. DHCP clients and servers that perform dynamic + updates should attempt to specify resource-record TTLs that reflect + this volatility, in order to minimize the possibility that answers to + DNS queries will return records that refer to DHCP IP address + assignments that have expired or been released. + + The coupling among primary, secondary, and caching DNS servers is + 'loose'; that is a fundamental part of the design of the DNS. This + looseness makes it impossible to prevent all possible situations in + which a resolver may return a record reflecting a DHCP-assigned IP + address that has expired or been released. In deployment, this + rarely, if ever, represents a significant problem. Most DHCP-managed + clients are infrequently looked up by name in the DNS, and the + deployment of IXFR ([16]) and NOTIFY ([17]) can reduce the latency + between updates and their visibility at secondary servers. + + We suggest these basic guidelines for implementers. In general, the + TTLs for RRs added as a result of DHCP IP address assignment activity + SHOULD be less than the initial lease time. The RR TTL on a DNS + record added SHOULD NOT exceed 1/3 of the lease time, but SHOULD NOT + be less than 10 minutes. We recognize that individual administrators + will have varying requirements: DHCP servers and clients SHOULD allow + administrators to configure TTLs and upper and lower bounds on the + TTL values, either as an absolute time interval or as a percentage of + the lease time. + + While clients and servers MAY update the TTL of the records as the + lease is about to expire, there is no requirement that they do so, as + this puts additional load on the DNS system with likely little + benefit. + +6. DNS Update Conflicts + + This document does not resolve how a DHCP client or server prevents + name conflicts. This document addresses only how a DHCP client and + server negotiate who will perform the DNS updates and the fully + qualified domain name requested or used. + + Implementers of this work will need to consider how name conflicts + will be prevented. If a DNS updater needs a security token in order + to successfully perform DNS updates on a specific name, name + conflicts can only occur if multiple updaters are given a security + token for that name. Or, if the fully qualified domains are based on + + + + + +Stapp, et al. Standards Track [Page 12] + +RFC 4702 The DHCP Client FQDN Option October 2006 + + + the specific address bound to a client, conflicts will not occur. + Or, a name conflict resolution technique as described in "Resolving + Name Conflicts" [10] SHOULD be used. + +7. IANA Considerations + + IANA has already assigned DHCP option 81 to the Client FQDN option. + As this document describes the option's use, IANA is requested to + reference this document for option 81. + +8. Security Considerations + + Unauthenticated updates to the DNS can lead to tremendous confusion, + through malicious attack or through inadvertent misconfiguration. + Administrators need to be wary of permitting unsecured DNS updates to + zones that are exposed to the global Internet. Both DHCP clients and + servers should use some form of update request origin authentication + procedure (e.g., Secure DNS Dynamic Update [14]) when performing DNS + updates. + + Whether a DHCP client is responsible for updating an FQDN-to-IP- + address mapping or whether this is the responsibility of the DHCP + server is a site-local matter. The choice between the two + alternatives is likely based on the security model that is used with + the DNS update protocol (e.g., only a client may have sufficient + credentials to perform updates to the FQDN-to-IP-address mapping for + its FQDN). + + Whether a DHCP server is always responsible for updating the FQDN- + to-IP-address mapping (in addition to updating the IP to FQDN + mapping), regardless of the wishes of an individual DHCP client, is + also a site-local matter. The choice between the two alternatives is + likely based on the security model that is being used with DNS + updates. In cases where a DHCP server is performing DNS updates on + behalf of a client, the DHCP server should be sure of the DNS name to + use for the client, and of the identity of the client. + + Currently, it is difficult for DHCP servers to develop much + confidence in the identities of its clients, given the absence of + entity authentication from the DHCP protocol itself. There are many + ways for a DHCP server to develop a DNS name to use for a client, but + only in certain relatively unusual circumstances will the DHCP server + know for certain the identity of the client. If DHCP Authentication + [15] becomes widely deployed, this may become more customary. + + One example of a situation that offers some extra assurances is when + the DHCP client is connected to a network through an Multimedia Cable + Network System (MCNS) cable modem, and the cable modem termination + + + +Stapp, et al. Standards Track [Page 13] + +RFC 4702 The DHCP Client FQDN Option October 2006 + + + system (CMTS), i.e., head-end, ensures that MAC address spoofing + simply does not occur. Another example of a configuration that might + be trusted is one where clients obtain network access via a network + access server using PPP. The NAS itself might be obtaining IP + addresses via DHCP, encoding a client identification into the DHCP + client-id option. In this case, the network access server as well as + the DHCP server might be operating within a trusted environment, in + which case the DHCP server could be configured to trust that the user + authentication and authorization procedure of the remote access + server was sufficient, and would therefore trust the client + identification encoded within the DHCP client-id. + + It is critical to implement proper conflict resolution, and the + security considerations of conflict resolution apply [10]. + +9. Acknowledgements + + Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter + Ford, Olafur Gudmundsson, Edie Gunter, Andreas Gustafsson, David W. + Hankins, R. Barr Hibbs, Kim Kinnear, Stuart Kwan, Ted Lemon, Ed + Lewis, Michael Lewis, Josh Littlefield, Michael Patton, Pekka Savola, + Jyrki Soini, and Glenn Stump for their review and comments. + +10. References + +10.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [3] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [4] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + + [6] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host + table specification", RFC 952, October 1985. + + [7] Braden, R., "Requirements for Internet Hosts - Application and + Support", STD 3, RFC 1123, October 1989. + + + +Stapp, et al. Standards Track [Page 14] + +RFC 4702 The DHCP Client FQDN Option October 2006 + + + [8] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. + Lear, "Address Allocation for Private Internets", BCP 5, + RFC 1918, February 1996. + + [9] Lemon, T. and S. Cheshire, "Encoding Long Options in the + Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, + November 2002. + + [10] Stapp, M. and B. Volz, "Resolution of Fully Qualified Domain + Name (FQDN) Conflicts among Dynamic Host Configuration Protocol + (DHCP) Clients", RFC 4703, October 2006. + +10.2. Informative References + + [11] Marine, A., Reynolds, J., and G. Malkin, "FYI on Questions and + Answers - Answers to Commonly asked "New Internet User" + Questions", FYI 4, RFC 1594, March 1994. + + [12] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, March 1997. + + [13] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, + August 1999. + + [14] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [15] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", + RFC 3118, June 2001. + + [16] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, + August 1996. + + [17] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes + (DNS NOTIFY)", RFC 1996, August 1996. + + + + + + + + + + + + + + + + +Stapp, et al. Standards Track [Page 15] + +RFC 4702 The DHCP Client FQDN Option October 2006 + + +Authors' Addresses + + Mark Stapp + Cisco Systems, Inc. + 1414 Massachusetts Ave. + Boxborough, MA 01719 + USA + + Phone: 978.936.1535 + EMail: mjs@cisco.com + + + Bernie Volz + Cisco Systems, Inc. + 1414 Massachusetts Ave. + Boxborough, MA 01719 + USA + + Phone: 978.936.0382 + EMail: volz@cisco.com + + + Yakov Rekhter + Juniper Networks + 1194 North Mathilda Avenue + Sunnyvale, CA 94089 + USA + + Phone: 408.745.2000 + EMail: yakov@juniper.net + + + + + + + + + + + + + + + + + + + + + +Stapp, et al. Standards Track [Page 16] + +RFC 4702 The DHCP Client FQDN Option October 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Stapp, et al. Standards Track [Page 17] + |