Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8156

DHCPv6 Failover Protocol

Pages: 96
Proposed Standard
Part 5 of 5 – Pages 85 to 96
First   Prev   None

Top   ToC   RFC8156 - Page 85   prevText

9. DNS Update Considerations

DHCP servers (and clients) can use "DNS update" as described in RFC 2136 [RFC2136] to maintain DNS name mappings as they maintain DHCP leases. Many different administrative models for DHCP-DNS integration are possible. Descriptions of several of these models, and guidelines that DHCP servers and clients should follow in carrying them out, are laid out in RFC 4704 [RFC4704]. The nature of the failover protocol introduces some issues concerning DNS updates that are not part of non-failover environments. This section describes these issues and defines the information that failover partners should exchange in order to ensure consistent behavior. The presence of this section should not be interpreted as a requirement that an implementation of the DHCPv6 failover protocol also support DNS updates. The purpose of this discussion is to clarify the areas where the failover and DHCP DNS update protocols intersect for the benefit of implementations that support both protocols, not to introduce a new requirement into the DHCPv6 failover protocol. Thus, a DHCP server that implements the failover protocol MAY also support DNS updates, but if it does support DNS updates it SHOULD utilize the techniques described here in order to correctly distribute them between the failover partners. See RFC 4704 [RFC4704] as well as RFC 4703 [RFC4703] for information on how DHCP servers deal with potential conflicts when updating DNS even without failover.
Top   ToC   RFC8156 - Page 86
   From the standpoint of the failover protocol, there is no reason why
   a server that is utilizing the DNS update protocol to update a DNS
   server should not be a partner with a server that is not utilizing
   the DNS update protocol to update a DNS server.  However, a server
   that is not able to support DNS update or is not configured to
   support DNS update SHOULD output a warning message when it receives
   BNDUPD messages that indicate that its failover partner is configured
   to support the DNS update protocol to update a DNS server.  An
   implementation MAY consider this an error and refuse to accept the
   BNDUPD message by returning the status DNSUpdateNotSupported in an
   OPTION_STATUS_CODE option in the BNDREPLY message, or it MAY choose
   to operate anyway, having warned the administrator of the problem in
   some way.

9.1. Relationship between Failover and DNS Update

The failover protocol describes the conditions under which each failover server may renew a lease to its current DHCP client and describes the conditions under which it may grant a lease to a new DHCP client. An analogous set of conditions determines when a failover server should initiate a DNS update, and when it should attempt to remove records from the DNS. The failover protocol's conditions are based on the desired external behavior: avoiding duplicate address and prefix assignments, allowing clients to continue using leases that they obtained from one failover partner even if they can only communicate with the other partner, and allowing the secondary DHCP server to grant new leases even if it is unable to communicate with the primary server. The desired external DNS update behavior for DHCPv6 failover servers is similar to that described above for the failover protocol itself: 1. Allow timely DNS updates from the server that grants a lease to a client. Recognize that there is often a DNS update "lifecycle" that parallels the DHCP lease lifecycle. This is likely to include the addition of records when the lease is granted and the removal of DNS records when the lease is subsequently made available for allocation to a different client. 2. Communicate enough information between the two failover servers to allow one to complete the DNS update lifecycle even if the other server originally granted the lease. 3. Avoid redundant or overlapping DNS updates where both failover servers are attempting to perform DNS updates for the same lease-client binding.
Top   ToC   RFC8156 - Page 87
   4.  Avoid situations where one partner is attempting to add resource
       records (RRs) related to a lease binding while the other partner
       is attempting to remove RRs related to the same lease binding.

   While DHCPv6 servers configured for DNS update typically perform
   these operations on both the AAAA and the PTR RRs, this is not
   required.  It is entirely possible that a DHCPv6 server could be
   configured to only update the DNS with PTR records, and the DHCPv6
   clients could be responsible for updating the DNS with their own AAAA
   records.  In this case, the discussions here would apply only to the
   PTR records.

9.2. Exchanging DNS Update Information

In order for either server to be able to complete a DNS update or to remove DNS records that were added by its partner, both servers need to know the FQDN associated with the lease-client binding. In addition, to properly handle DNS updates, additional information is required. All of the following information needs to be transmitted between the failover partners: 1. The FQDN that the client requested be associated with the lease. If the client doesn't request a particular FQDN and one is synthesized by the failover server or if the failover server is configured to replace a client-requested FQDN with a different FQDN, then the server-generated value would be used. 2. The FQDN that was actually placed in the DNS for this lease. It may differ from the client-requested FQDN due to some form of disambiguation or other DHCP server configuration (as described above). 3. The status of any DNS update operations in progress or completed. 4. Information sufficient to allow the failover partner to remove the FQDN from the DNS, should that become necessary. These data items are the minimum necessary set to reliably allow two failover partners to successfully share the responsibility to keep the DNS up to date with the leases allocated to clients. This information would typically be included in BNDUPD messages sent from one failover partner to the other. Failover servers MAY choose not to include this information in BNDUPD messages if there has been no change in the status of any DNS update related to the lease.
Top   ToC   RFC8156 - Page 88
   The partner server receiving BNDUPD messages containing the DNS
   update information SHOULD compare the status information and the FQDN
   with the current DNS update information it has associated with the
   lease binding and update its notion of the DNS update status
   accordingly.

   Some implementations will instead choose to send a BNDUPD message
   without waiting for the DNS update to complete and then will send a
   second BNDUPD message once the DNS update is complete.  Other
   implementations will delay sending the partner a BNDUPD message until
   the DNS update has been acknowledged by the DNS server, or until some
   time limit has elapsed, in order to avoid sending a second BNDUPD
   message.

   The FQDN option contains the FQDN that will be associated with the
   AAAA RR (if the server is performing a AAAA RR update for the
   client).  The PTR RR can be generated automatically from the IPv6
   address value.  The FQDN may be composed in any of several ways,
   depending on server configuration and the information provided by the
   client in its DHCP messages.  The client may supply a hostname that
   it would like the server to use in forming the FQDN, or it may supply
   the entire FQDN.  The server may be configured to attempt to use the
   information the client supplies, it may be configured with an FQDN to
   use for the client, or it may be configured to synthesize an FQDN.

   Since the server interacting with the client may not have completed
   the DNS update at the time it sends the first BNDUPD message about
   the lease binding, there may be cases where the FQDN in later BNDUPD
   messages does not match the FQDN included in earlier messages.  For
   example, the responsive server may be configured to handle situations
   where two or more DHCP client FQDNs are identical by modifying the
   most-specific label in the FQDNs of some of the clients in an attempt
   to generate unique FQDNs for them (a process sometimes called
   "disambiguation").  Alternatively, at sites that use some or all of
   the information that clients supply to form the FQDN, it's possible
   that a client's configuration may be changed so that it begins to
   supply new data.  The server interacting with the client may react by
   removing the DNS records that it originally added for the client and
   replacing them with records that refer to the client's new FQDN.  In
   such cases, the server SHOULD include the actual FQDN that was used
   in subsequent DNS update options in any BNDUPD messages exchanged
   between the failover partners.  This server SHOULD include relevant
   information in its BNDUPD messages.  This information may be
   necessary in order to allow the non-responsive partner to detect
   client configuration changes that change the hostname or FQDN data
   that the client includes in its DHCPv6 requests.
Top   ToC   RFC8156 - Page 89

9.3. Adding RRs to the DNS

A failover server that is going to perform DNS updates SHOULD initiate the DNS update when it grants a new lease to a client. The server that did not grant the lease SHOULD NOT initiate a DNS update when it receives the BNDUPD message after the lease has been granted. The failover protocol ensures that only one of the partners will grant a lease to any individual client, so it follows that this requirement will prevent both partners from initiating updates simultaneously. The server initiating the update SHOULD follow the protocol in RFC 4704 [RFC4704]. The server may be configured to perform a AAAA RR update on behalf of its clients, or not. Ordinarily, a failover server will not initiate DNS updates when it renews leases. In two cases, however, a failover server MAY initiate a DNS update when it renews a lease to its existing client: 1. When the lease was granted before the server was configured to perform DNS updates, the server MAY be configured to perform updates when it next renews existing leases. 2. If a server is in PARTNER-DOWN state, it can conclude that its partner is no longer attempting to perform an update for the existing client. If the remaining server has not recorded that an update for the binding has been successfully completed, the server MAY initiate a DNS update. It may initiate this update immediately upon entry into PARTNER-DOWN state, it may perform this in the background, or it may initiate this update upon next hearing from the DHCP client. Note that, regardless of the use of failover, there is a use case for updating the DNS on every lease renewal. If there is a concern that the information in the DNS does not match the information in the DHCP server, updating the DNS on lease renewal is one way to gradually ensure that the DNS has information that corresponds correctly to the information in the DHCP server.
Top   ToC   RFC8156 - Page 90

9.4. Deleting RRs from the DNS

The failover server that makes a lease PENDING-FREE SHOULD initiate any DNS deletes if it has recorded that DNS records were added on behalf of the client. A server not in PARTNER-DOWN state "makes a lease PENDING-FREE" when it initiates a BNDUPD message with a binding-status of FREE, FREE-BACKUP, EXPIRED, or RELEASED. Its partner confirms this status by acking that BNDUPD message, and upon receipt of the BNDREPLY message the server has "made the lease PENDING-FREE". Conversely, a server in PARTNER-DOWN state "makes a lease PENDING-FREE" when it sets the binding-status to FREE, since in PARTNER-DOWN state no communications with the partner are required. It is at this point that it should initiate the DNS operations to delete RRs from the DNS. Its partner SHOULD NOT initiate DNS deletes for DNS records related to the lease binding as part of sending the BNDREPLY message. The partner MAY have issued BNDUPD messages with a binding-status of FREE, EXPIRED, or RELEASED previously, but the other server will have rejected these BNDUPD messages. The failover protocol ensures that only one of the two partner servers will be able to make a lease PENDING-FREE. The server making the lease PENDING-FREE may be doing so while it is communicating in NORMAL state with its partner, or it may be in PARTNER-DOWN state. If a server is in PARTNER-DOWN state, it may be performing DNS deletes for RRs that its partner added originally. This allows a single remaining partner server to assume responsibility for all of the DNS update activity that the two servers were undertaking. Another implication of this approach is that no DNS RR deletes will be performed while either server is in COMMUNICATIONS-INTERRUPTED state, since no leases are moved into the PENDING-FREE state during that period. A failover server SHOULD ensure that a server failure while making a lease PENDING-FREE and initiating a DNS delete does not somehow leave the lease with an RR in the DNS with nothing recorded in the lease state database to trigger a DNS delete.
Top   ToC   RFC8156 - Page 91

9.5. Name Assignment with No Update of DNS

In some cases, a DHCP server is configured to return a name to the DHCP client but not enter that name into the DNS. This is typically a name that it has discovered or generated from information it has received from the client. In this case, this name information SHOULD be communicated to the failover partner, if only to ensure that they will return the same name in the event the partner becomes the server with which the DHCP client begins to interact.

10. Security Considerations

DHCPv6 failover is an extension of a standard DHCPv6 protocol, so all security considerations from Section 23 of [RFC3315] and Section 15 of [RFC3633] related to the server apply. The use of TCP introduces some additional concerns. Attacks that attempt to exhaust the DHCP server's available TCP connection resources can compromise the ability of legitimate partners to receive service. Malicious requestors who succeed in establishing connections but who then send invalid messages, partial messages, or no messages at all can also exhaust a server's pool of available connections. DHCPv6 failover can operate in secure or insecure mode. Secure mode (using Transport Layer Security (TLS) [RFC5246]) would be indicated when the TCP connection between failover partners is open to external monitoring or interception. Insecure mode should only be used when the TCP connection between failover partners remains within a set of protected systems. Details of such protections are beyond the scope of this document. Failover servers MUST use the approach documented in Section 9.1 of [RFC7653] to decide whether or not to use TLS when connecting with the failover partner. The threats created by using failover directly mirror those from using DHCPv6 itself: information leakage through monitoring, and disruption of address assignment and configuration. Monitoring the failover TCP connection provides no additional data beyond that available from monitoring the interactions between DHCPv6 clients and the DHCPv6 server. Likewise, manipulating the data flow between failover servers provides no additional opportunities to disrupt address assignment and configuration beyond that provided by acting as a counterfeit DHCP server. Protection from both threats is easier than with basic DHCPv6, as only a single TCP connection needs to be protected. Either use secure mode to protect that TCP connection or ensure that it can only exist with a set of protected systems.
Top   ToC   RFC8156 - Page 92
   When operating in secure mode, TLS is used to secure the connection.
   The recommendations in [RFC7525] SHOULD be followed when negotiating
   a TLS connection.

   Servers SHOULD offer configuration parameters to limit the sources of
   incoming connections through validation and use of the digital
   certificates presented to create a TLS connection.  They SHOULD also
   limit the number of accepted connections and limit the period of time
   during which an idle connection will be left open.

   Authentication for DHCPv6 messages [RFC3315] MUST NOT be used to
   attempt to secure transmission of the messages described in this
   document.  If authentication is desired, secure mode using TLS SHOULD
   be employed as described in Sections 8.2 and 9.1 of [RFC7653].

11. IANA Considerations

IANA has assigned values for the following new DHCPv6 message types in the registry maintained at <http://www.iana.org/assignments/ dhcpv6-parameters>: o BNDUPD (24) o BNDREPLY (25) o POOLREQ (26) o POOLRESP (27) o UPDREQ (28) o UPDREQALL (29) o UPDDONE (30) o CONNECT (31) o CONNECTREPLY (32) o DISCONNECT (33) o STATE (34) o CONTACT (35)
Top   ToC   RFC8156 - Page 93
   IANA has assigned values for the following new DHCPv6 option codes in
   the registry maintained at <http://www.iana.org/assignments/
   dhcpv6-parameters>:

   o  OPTION_F_BINDING_STATUS (114)

   o  OPTION_F_CONNECT_FLAGS (115)

   o  OPTION_F_DNS_REMOVAL_INFO (116)

   o  OPTION_F_DNS_HOST_NAME (117)

   o  OPTION_F_DNS_ZONE_NAME (118)

   o  OPTION_F_DNS_FLAGS (119)

   o  OPTION_F_EXPIRATION_TIME (120)

   o  OPTION_F_MAX_UNACKED_BNDUPD (121)

   o  OPTION_F_MCLT (122)

   o  OPTION_F_PARTNER_LIFETIME (123)

   o  OPTION_F_PARTNER_LIFETIME_SENT (124)

   o  OPTION_F_PARTNER_DOWN_TIME (125)

   o  OPTION_F_PARTNER_RAW_CLT_TIME (126)

   o  OPTION_F_PROTOCOL_VERSION (127)

   o  OPTION_F_KEEPALIVE_TIME (128)

   o  OPTION_F_RECONFIGURE_DATA (129)

   o  OPTION_F_RELATIONSHIP_NAME (130)

   o  OPTION_F_SERVER_FLAGS (131)

   o  OPTION_F_SERVER_STATE (132)

   o  OPTION_F_START_TIME_OF_STATE (133)

   o  OPTION_F_STATE_EXPIRATION_TIME (134)
Top   ToC   RFC8156 - Page 94
   IANA has assigned values for the following new DHCPv6 status codes in
   the registry maintained at <http://www.iana.org/assignments/
   dhcpv6-parameters>:

   o  AddressInUse (16)

   o  ConfigurationConflict (17)

   o  MissingBindingInformation (18)

   o  OutdatedBindingInformation (19)

   o  ServerShuttingDown (20)

   o  DNSUpdateNotSupported (21)

   o  ExcessiveTimeSkew (22)

12. References

12.1. Normative References

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <http://www.rfc-editor.org/info/rfc2136>. [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003, <http://www.rfc-editor.org/info/rfc3633>.
Top   ToC   RFC8156 - Page 95
   [RFC4703]  Stapp, M. and B. Volz, "Resolution of Fully Qualified
              Domain Name (FQDN) Conflicts among Dynamic Host
              Configuration Protocol (DHCP) Clients", RFC 4703,
              DOI 10.17487/RFC4703, October 2006,
              <http://www.rfc-editor.org/info/rfc4703>.

   [RFC4704]  Volz, B., "The Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
              Option", RFC 4704, DOI 10.17487/RFC4704, October 2006,
              <http://www.rfc-editor.org/info/rfc4704>.

   [RFC5007]  Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
              "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007,
              September 2007, <http://www.rfc-editor.org/info/rfc5007>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC5460]  Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
              DOI 10.17487/RFC5460, February 2009,
              <http://www.rfc-editor.org/info/rfc5460>.

   [RFC6607]  Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet
              Selection Options for DHCPv4 and DHCPv6", RFC 6607,
              DOI 10.17487/RFC6607, April 2012,
              <http://www.rfc-editor.org/info/rfc6607>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525,
              May 2015, <http://www.rfc-editor.org/info/rfc7525>.

   [RFC7653]  Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6
              Active Leasequery", RFC 7653, DOI 10.17487/RFC7653,
              October 2015, <http://www.rfc-editor.org/info/rfc7653>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
              RFC 2119 Key Words", BCP 14, RFC 8174,
              DOI 10.17487/RFC8174, May 2017,
              <http://www.rfc-editor.org/info/rfc8174>.
Top   ToC   RFC8156 - Page 96

12.2. Informative References

[RFC7031] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover Requirements", RFC 7031, DOI 10.17487/RFC7031, September 2013, <http://www.rfc-editor.org/info/rfc7031>.

Acknowledgements

This document extensively uses concepts, definitions, and other parts of an effort to document failover for DHCPv4. The authors would like to thank Shawn Routhier, Greg Rabil, Bernie Volz, and Marcin Siodelski for their significant involvement and contributions. In particular, Bernie Volz and Shawn Routhier provided detailed and substantive technical reviews of the document. The RFC Editor also caught several important technical issues. The authors would like to thank Vithalprasad Gaitonde, Krzysztof Gierlowski, Krzysztof Nowicki, and Michal Hoeft for their insightful comments.

Authors' Addresses

Tomek Mrugalski Internet Systems Consortium, Inc. 950 Charter Street Redwood City, California 94063 United States of America Email: tomasz.mrugalski@gmail.com Kim Kinnear Cisco Systems, Inc. 200 Beaver Brook Road Boxborough, Massachusetts 01719 United States of America Phone: +1 978 936 0000 Email: kkinnear@cisco.com