draft-ietf-dhc-dhcpv6-failover-protocol-03.txt   draft-ietf-dhc-dhcpv6-failover-protocol-04.txt 
Dynamic Host Configuration (DHC) T. Mrugalski Dynamic Host Configuration (DHC) T. Mrugalski
Internet-Draft ISC Internet-Draft ISC
Intended status: Standards Track K. Kinnear Intended status: Standards Track K. Kinnear
Expires: April 16, 2017 Cisco Expires: July 24, 2017 Cisco
October 13, 2016 January 20, 2017
DHCPv6 Failover Protocol DHCPv6 Failover Protocol
draft-ietf-dhc-dhcpv6-failover-protocol-03 draft-ietf-dhc-dhcpv6-failover-protocol-04
Abstract Abstract
DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6 DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)" (RFC3315) does not offer server redundancy. This document (DHCPv6)" (RFC3315) does not offer server redundancy. This document
defines a protocol implementation to provide DHCPv6 failover, a defines a protocol implementation to provide DHCPv6 failover, a
mechanism for running two servers with the capability for either mechanism for running two servers with the capability for either
server to take over clients' leases in case of server failure or server to take over clients' leases in case of server failure or
network partition. It meets the requirements for DHCPv6 failover network partition. It meets the requirements for DHCPv6 failover
detailed in "DHCPv6 Failover Requirements" (RFC7031). detailed in "DHCPv6 Failover Requirements" (RFC7031).
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 16, 2017. This Internet-Draft will expire on July 24, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 21 skipping to change at page 2, line 21
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Failover Concepts and Mechanisms . . . . . . . . . . . . . . 8 4. Failover Concepts and Mechanisms . . . . . . . . . . . . . . 8
4.1. Required Server Configuration . . . . . . . . . . . . . . 8 4.1. Required Server Configuration . . . . . . . . . . . . . . 8
4.2. IPv6 Address and Delegable Prefix Allocation . . . . . . 9 4.2. IPv6 Address and Delegable Prefix Allocation . . . . . . 9
4.2.1. Independent Allocation . . . . . . . . . . . . . . . 9 4.2.1. Independent Allocation . . . . . . . . . . . . . . . 9
4.2.2. Proportional Allocation . . . . . . . . . . . . . . . 10 4.2.2. Proportional Allocation . . . . . . . . . . . . . . . 10
4.3. Lazy Updates . . . . . . . . . . . . . . . . . . . . . . 13 4.3. Lazy Updates . . . . . . . . . . . . . . . . . . . . . . 13
4.4. Maximum Client Lead Time (MCLT) . . . . . . . . . . . . . 13 4.4. Maximum Client Lead Time (MCLT) . . . . . . . . . . . . . 13
4.4.1. MCLT example . . . . . . . . . . . . . . . . . . . . 14 4.4.1. MCLT example . . . . . . . . . . . . . . . . . . . . 14
5. Message and Option Definitions . . . . . . . . . . . . . . . 16 5. Message and Option Definitions . . . . . . . . . . . . . . . 18
5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 16 5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 18
5.2. Failover Message Format . . . . . . . . . . . . . . . . . 16 5.2. Failover Message Format . . . . . . . . . . . . . . . . . 18
5.3. Messages . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3. Messages . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3.1. BNDUPD . . . . . . . . . . . . . . . . . . . . . . . 17 5.3.1. BNDUPD . . . . . . . . . . . . . . . . . . . . . . . 19
5.3.2. BNDREPLY . . . . . . . . . . . . . . . . . . . . . . 18 5.3.2. BNDREPLY . . . . . . . . . . . . . . . . . . . . . . 20
5.3.3. POOLREQ . . . . . . . . . . . . . . . . . . . . . . . 18 5.3.3. POOLREQ . . . . . . . . . . . . . . . . . . . . . . . 20
5.3.4. POOLRESP . . . . . . . . . . . . . . . . . . . . . . 18 5.3.4. POOLRESP . . . . . . . . . . . . . . . . . . . . . . 20
5.3.5. UPDREQ . . . . . . . . . . . . . . . . . . . . . . . 18 5.3.5. UPDREQ . . . . . . . . . . . . . . . . . . . . . . . 20
5.3.6. UPDREQALL . . . . . . . . . . . . . . . . . . . . . . 18 5.3.6. UPDREQALL . . . . . . . . . . . . . . . . . . . . . . 20
5.3.7. UPDDONE . . . . . . . . . . . . . . . . . . . . . . . 19 5.3.7. UPDDONE . . . . . . . . . . . . . . . . . . . . . . . 21
5.3.8. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 19 5.3.8. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 21
5.3.9. CONNECTREPLY . . . . . . . . . . . . . . . . . . . . 19 5.3.9. CONNECTREPLY . . . . . . . . . . . . . . . . . . . . 21
5.3.10. DISCONNECT . . . . . . . . . . . . . . . . . . . . . 19 5.3.10. DISCONNECT . . . . . . . . . . . . . . . . . . . . . 21
5.3.11. STATE . . . . . . . . . . . . . . . . . . . . . . . . 19 5.3.11. STATE . . . . . . . . . . . . . . . . . . . . . . . . 21
5.3.12. CONTACT . . . . . . . . . . . . . . . . . . . . . . . 19 5.3.12. CONTACT . . . . . . . . . . . . . . . . . . . . . . . 21
5.4. Transaction Id . . . . . . . . . . . . . . . . . . . . . 20 5.4. Transaction Id . . . . . . . . . . . . . . . . . . . . . 22
5.5. Options . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.5. Options . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.5.1. OPTION_F_BINDING_STATUS . . . . . . . . . . . . . . . 20 5.5.1. OPTION_F_BINDING_STATUS . . . . . . . . . . . . . . . 22
5.5.2. OPTION_F_CONNECT_FLAGS . . . . . . . . . . . . . . . 21 5.5.2. OPTION_F_CONNECT_FLAGS . . . . . . . . . . . . . . . 23
5.5.3. OPTION_F_DNS_REMOVAL_INFO . . . . . . . . . . . . . . 22 5.5.3. OPTION_F_DNS_REMOVAL_INFO . . . . . . . . . . . . . . 24
5.5.4. OPTION_F_DNS_HOST_NAME . . . . . . . . . . . . . . . 23 5.5.4. OPTION_F_DNS_HOST_NAME . . . . . . . . . . . . . . . 25
5.5.5. OPTION_F_DNS_ZONE_NAME . . . . . . . . . . . . . . . 23 5.5.5. OPTION_F_DNS_ZONE_NAME . . . . . . . . . . . . . . . 25
5.5.6. OPTION_F_DNS_FLAGS . . . . . . . . . . . . . . . . . 24 5.5.6. OPTION_F_DNS_FLAGS . . . . . . . . . . . . . . . . . 26
5.5.7. OPTION_F_EXPIRATION_TIME . . . . . . . . . . . . . . 25 5.5.7. OPTION_F_EXPIRATION_TIME . . . . . . . . . . . . . . 27
5.5.8. OPTION_F_MAX_UNACKED_BNDUPD . . . . . . . . . . . . . 26 5.5.8. OPTION_F_MAX_UNACKED_BNDUPD . . . . . . . . . . . . . 28
5.5.9. OPTION_F_MCLT . . . . . . . . . . . . . . . . . . . . 26 5.5.9. OPTION_F_MCLT . . . . . . . . . . . . . . . . . . . . 28
5.5.10. OPTION_F_PARTNER_LIFETIME . . . . . . . . . . . . . . 27 5.5.10. OPTION_F_PARTNER_LIFETIME . . . . . . . . . . . . . . 29
5.5.11. OPTION_F_PARTNER_LIFETIME_SENT . . . . . . . . . . . 27 5.5.11. OPTION_F_PARTNER_LIFETIME_SENT . . . . . . . . . . . 29
5.5.12. OPTION_F_PARTNER_DOWN_TIME . . . . . . . . . . . . . 28 5.5.12. OPTION_F_PARTNER_DOWN_TIME . . . . . . . . . . . . . 30
5.5.13. OPTION_F_PARTNER_RAW_CLT_TIME . . . . . . . . . . . . 29 5.5.13. OPTION_F_PARTNER_RAW_CLT_TIME . . . . . . . . . . . . 31
5.5.14. OPTION_F_PROTOCOL_VERSION . . . . . . . . . . . . . . 29 5.5.14. OPTION_F_PROTOCOL_VERSION . . . . . . . . . . . . . . 31
5.5.15. OPTION_F_KEEPALIVE_TIME . . . . . . . . . . . . . . . 30 5.5.15. OPTION_F_KEEPALIVE_TIME . . . . . . . . . . . . . . . 32
5.5.16. OPTION_F_RECONFIGURE_DATA . . . . . . . . . . . . . . 30 5.5.16. OPTION_F_RECONFIGURE_DATA . . . . . . . . . . . . . . 32
5.5.17. OPTION_F_RELATIONSHIP_NAME . . . . . . . . . . . . . 31 5.5.17. OPTION_F_RELATIONSHIP_NAME . . . . . . . . . . . . . 33
5.5.18. OPTION_F_SERVER_FLAGS . . . . . . . . . . . . . . . . 32 5.5.18. OPTION_F_SERVER_FLAGS . . . . . . . . . . . . . . . . 34
5.5.19. OPTION_F_SERVER_STATE . . . . . . . . . . . . . . . . 33 5.5.19. OPTION_F_SERVER_STATE . . . . . . . . . . . . . . . . 35
5.5.20. OPTION_F_START_TIME_OF_STATE . . . . . . . . . . . . 34 5.5.20. OPTION_F_START_TIME_OF_STATE . . . . . . . . . . . . 36
5.5.21. OPTION_F_STATE_EXPIRATION_TIME . . . . . . . . . . . 35 5.5.21. OPTION_F_STATE_EXPIRATION_TIME . . . . . . . . . . . 37
5.6. Status Codes . . . . . . . . . . . . . . . . . . . . . . 36 5.6. Status Codes . . . . . . . . . . . . . . . . . . . . . . 38
6. Connection Management . . . . . . . . . . . . . . . . . . . . 37 6. Connection Management . . . . . . . . . . . . . . . . . . . . 39
6.1. Creating Connections . . . . . . . . . . . . . . . . . . 37 6.1. Creating Connections . . . . . . . . . . . . . . . . . . 39
6.1.1. Sending a CONNECT message . . . . . . . . . . . . . . 38 6.1.1. Sending a CONNECT message . . . . . . . . . . . . . . 40
6.1.2. Receiving a CONNECT message . . . . . . . . . . . . . 38 6.1.2. Receiving a CONNECT message . . . . . . . . . . . . . 40
6.1.3. Receiving a CONNECTREPLY message . . . . . . . . . . 40 6.1.3. Receiving a CONNECTREPLY message . . . . . . . . . . 42
6.2. Endpoint Identification . . . . . . . . . . . . . . . . . 40 6.2. Endpoint Identification . . . . . . . . . . . . . . . . . 42
6.3. Sending a STATE message . . . . . . . . . . . . . . . . . 41 6.3. Sending a STATE message . . . . . . . . . . . . . . . . . 43
6.4. Receiving a STATE message . . . . . . . . . . . . . . . . 42 6.4. Receiving a STATE message . . . . . . . . . . . . . . . . 44
6.5. Connection Maintenance Parameters . . . . . . . . . . . . 42 6.5. Connection Maintenance Parameters . . . . . . . . . . . . 44
6.6. Unreachability detection . . . . . . . . . . . . . . . . 43 6.6. Unreachability detection . . . . . . . . . . . . . . . . 45
7. Binding Updates and Acks . . . . . . . . . . . . . . . . . . 44 7. Binding Updates and Acks . . . . . . . . . . . . . . . . . . 46
7.1. Time Skew . . . . . . . . . . . . . . . . . . . . . . . . 44 7.1. Time Skew . . . . . . . . . . . . . . . . . . . . . . . . 46
7.2. Information model . . . . . . . . . . . . . . . . . . . . 44 7.2. Information model . . . . . . . . . . . . . . . . . . . . 46
7.3. Times Required for Exchanging Binding Updates . . . . . . 48 7.3. Times Required for Exchanging Binding Updates . . . . . . 50
7.4. Sending Binding Updates . . . . . . . . . . . . . . . . . 49 7.4. Sending Binding Updates . . . . . . . . . . . . . . . . . 51
7.5. Receiving Binding Updates . . . . . . . . . . . . . . . . 52 7.5. Receiving Binding Updates . . . . . . . . . . . . . . . . 54
7.5.1. Monitoring Time Skew . . . . . . . . . . . . . . . . 52 7.5.1. Monitoring Time Skew . . . . . . . . . . . . . . . . 54
7.5.2. Acknowledging Reception . . . . . . . . . . . . . . . 52 7.5.2. Acknowledging Reception . . . . . . . . . . . . . . . 54
7.5.3. Processing Binding Updates . . . . . . . . . . . . . 52 7.5.3. Processing Binding Updates . . . . . . . . . . . . . 54
7.5.4. Accept or Reject? . . . . . . . . . . . . . . . . . . 53 7.5.4. Accept or Reject? . . . . . . . . . . . . . . . . . . 55
7.5.5. Accepting Updates . . . . . . . . . . . . . . . . . . 55 7.5.5. Accepting Updates . . . . . . . . . . . . . . . . . . 57
7.6. Sending Binding Replies . . . . . . . . . . . . . . . . . 56 7.6. Sending Binding Replies . . . . . . . . . . . . . . . . . 58
7.7. Receiving Binding Acks . . . . . . . . . . . . . . . . . 58 7.7. Receiving Binding Acks . . . . . . . . . . . . . . . . . 60
7.8. BNDUPD/BNDREPLY Data Flow . . . . . . . . . . . . . . . . 59 7.8. BNDUPD/BNDREPLY Data Flow . . . . . . . . . . . . . . . . 61
8. Endpoint States . . . . . . . . . . . . . . . . . . . . . . . 60 8. Endpoint States . . . . . . . . . . . . . . . . . . . . . . . 62
8.1. State Machine Operation . . . . . . . . . . . . . . . . . 60 8.1. State Machine Operation . . . . . . . . . . . . . . . . . 62
8.2. State Machine Initialization . . . . . . . . . . . . . . 64 8.2. State Machine Initialization . . . . . . . . . . . . . . 66
8.3. STARTUP State . . . . . . . . . . . . . . . . . . . . . . 64 8.3. STARTUP State . . . . . . . . . . . . . . . . . . . . . . 66
8.3.1. Operation in STARTUP State . . . . . . . . . . . . . 65 8.3.1. Operation in STARTUP State . . . . . . . . . . . . . 67
8.3.2. Transition Out of STARTUP State . . . . . . . . . . . 65 8.3.2. Transition Out of STARTUP State . . . . . . . . . . . 67
8.4. PARTNER-DOWN State . . . . . . . . . . . . . . . . . . . 67 8.4. PARTNER-DOWN State . . . . . . . . . . . . . . . . . . . 69
8.4.1. Operation in PARTNER-DOWN State . . . . . . . . . . . 67 8.4.1. Operation in PARTNER-DOWN State . . . . . . . . . . . 69
8.4.2. Transition Out of PARTNER-DOWN State . . . . . . . . 68 8.4.2. Transition Out of PARTNER-DOWN State . . . . . . . . 70
8.5. RECOVER State . . . . . . . . . . . . . . . . . . . . . . 68 8.5. RECOVER State . . . . . . . . . . . . . . . . . . . . . . 70
8.5.1. Operation in RECOVER State . . . . . . . . . . . . . 69 8.5.1. Operation in RECOVER State . . . . . . . . . . . . . 71
8.5.2. Transition Out of RECOVER State . . . . . . . . . . . 69 8.5.2. Transition Out of RECOVER State . . . . . . . . . . . 71
8.6. RECOVER-WAIT State . . . . . . . . . . . . . . . . . . . 70 8.6. RECOVER-WAIT State . . . . . . . . . . . . . . . . . . . 72
8.6.1. Operation in RECOVER-WAIT State . . . . . . . . . . . 71 8.6.1. Operation in RECOVER-WAIT State . . . . . . . . . . . 73
8.6.2. Transition Out of RECOVER-WAIT State . . . . . . . . 71 8.6.2. Transition Out of RECOVER-WAIT State . . . . . . . . 73
8.7. RECOVER-DONE State . . . . . . . . . . . . . . . . . . . 71 8.7. RECOVER-DONE State . . . . . . . . . . . . . . . . . . . 73
8.7.1. Operation in RECOVER-DONE State . . . . . . . . . . . 71 8.7.1. Operation in RECOVER-DONE State . . . . . . . . . . . 73
8.7.2. Transition Out of RECOVER-DONE State . . . . . . . . 72 8.7.2. Transition Out of RECOVER-DONE State . . . . . . . . 74
8.8. NORMAL State . . . . . . . . . . . . . . . . . . . . . . 72 8.8. NORMAL State . . . . . . . . . . . . . . . . . . . . . . 74
8.8.1. Operation in NORMAL State . . . . . . . . . . . . . . 72 8.8.1. Operation in NORMAL State . . . . . . . . . . . . . . 74
8.8.2. Transition Out of NORMAL State . . . . . . . . . . . 73 8.8.2. Transition Out of NORMAL State . . . . . . . . . . . 75
8.9. COMMUNICATIONS-INTERRUPTED State . . . . . . . . . . . . 74 8.9. COMMUNICATIONS-INTERRUPTED State . . . . . . . . . . . . 76
8.9.1. Operation in COMMUNICATIONS-INTERRUPTED State . . . . 74 8.9.1. Operation in COMMUNICATIONS-INTERRUPTED State . . . . 76
8.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State . 75 8.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State . 77
8.10. POTENTIAL-CONFLICT State . . . . . . . . . . . . . . . . 76 8.10. POTENTIAL-CONFLICT State . . . . . . . . . . . . . . . . 78
8.10.1. Operation in POTENTIAL-CONFLICT State . . . . . . . 77 8.10.1. Operation in POTENTIAL-CONFLICT State . . . . . . . 79
8.10.2. Transition Out of POTENTIAL-CONFLICT State . . . . . 77 8.10.2. Transition Out of POTENTIAL-CONFLICT State . . . . . 79
8.11. RESOLUTION-INTERRUPTED State . . . . . . . . . . . . . . 78 8.11. RESOLUTION-INTERRUPTED State . . . . . . . . . . . . . . 80
8.11.1. Operation in RESOLUTION-INTERRUPTED State . . . . . 79 8.11.1. Operation in RESOLUTION-INTERRUPTED State . . . . . 81
8.11.2. Transition Out of RESOLUTION-INTERRUPTED State . . . 79 8.11.2. Transition Out of RESOLUTION-INTERRUPTED State . . . 81
8.12. CONFLICT-DONE State . . . . . . . . . . . . . . . . . . . 79 8.12. CONFLICT-DONE State . . . . . . . . . . . . . . . . . . . 81
8.12.1. Operation in CONFLICT-DONE State . . . . . . . . . . 80 8.12.1. Operation in CONFLICT-DONE State . . . . . . . . . . 82
8.12.2. Transition Out of CONFLICT-DONE State . . . . . . . 80 8.12.2. Transition Out of CONFLICT-DONE State . . . . . . . 82
9. DNS Update Considerations . . . . . . . . . . . . . . . . . . 80 9. DNS Update Considerations . . . . . . . . . . . . . . . . . . 82
9.1. Relationship between failover and DNS update . . . . . . 81 9.1. Relationship between failover and DNS update . . . . . . 83
9.2. Exchanging DNS Update Information . . . . . . . . . . . . 82 9.2. Exchanging DNS Update Information . . . . . . . . . . . . 84
9.3. Adding RRs to the DNS . . . . . . . . . . . . . . . . . . 84 9.3. Adding RRs to the DNS . . . . . . . . . . . . . . . . . . 86
9.4. Deleting RRs from the DNS . . . . . . . . . . . . . . . . 84 9.4. Deleting RRs from the DNS . . . . . . . . . . . . . . . . 86
9.5. Name Assignment with No Update of DNS . . . . . . . . . . 85 9.5. Name Assignment with No Update of DNS . . . . . . . . . . 87
10. Security Considerations . . . . . . . . . . . . . . . . . . . 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 87
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 88
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 88 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 90
13.1. Normative References . . . . . . . . . . . . . . . . . . 88 13.1. Normative References . . . . . . . . . . . . . . . . . . 90
13.2. Informative References . . . . . . . . . . . . . . . . . 90 13.2. Informative References . . . . . . . . . . . . . . . . . 92
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 92
1. Introduction 1. Introduction
The failover protocol provides a means for cooperating DHCP servers The failover protocol provides a means for cooperating DHCP servers
to work together to provide a DHCP service with availability that is to work together to provide a DHCP service with availability that is
increased beyond that which could be provided by a single DHCP server increased beyond that which could be provided by a single DHCP server
operating alone. It is designed to protect DHCP clients against operating alone. It is designed to protect DHCP clients against
server unreachability, including server failure and network server unreachability, including server failure and network
partition. It is possible to deploy exactly two servers that are partition. It is possible to deploy exactly two servers that are
able to continue providing a lease for an IPv6 address [RFC3315] or able to continue providing a lease for an IPv6 address [RFC3315] or
skipping to change at page 16, line 12 skipping to change at page 17, line 5
"lead" the client in its understanding of the client's lifetime so as "lead" the client in its understanding of the client's lifetime so as
to be able to always offer the client the desired lifetime. to be able to always offer the client the desired lifetime.
Once the initial actual client lifetime of the MCLT is past, the Once the initial actual client lifetime of the MCLT is past, the
protocol operates effectively like the DHCP protocol does today in protocol operates effectively like the DHCP protocol does today in
its behavior concerning lifetimes. However, the guarantee that the its behavior concerning lifetimes. However, the guarantee that the
actual client lifetime will never exceed the remaining acknowledged actual client lifetime will never exceed the remaining acknowledged
partner server partner lifetime by more than the MCLT allows full partner server partner lifetime by more than the MCLT allows full
recovery from a variety of DHCP server failures. recovery from a variety of DHCP server failures.
Fundamental relationship:
lease time = floor(desired lifetime, ack-partner-lifetime + MCLT)
Initial conditions: MCLT = 1h, desired lifetime = 3d
DHCPv6 Primary Secondary
time Client Server Server
| >-SOLICIT------> | |
| acknowledged partner lifetime = 0 |
| lease time = floor( 3d, 0 + 1h ) = 1h |
| <-----ADVERTISE-< | |
| lease-time= 1h | |
| >-REQUEST------> | |
t | <---------REPLY-< | |
| lease-time= 1h | |
| | >-BNDUPD------> |
| | partner-lifetime = 1/2h + 3d
| | <----BNDREPLY-< |
| | partner-lifetime = 1/2h + 3d
1/2h passes ... ... ...
t+1/2h | >-RENEW--------> | |
| acknowledged partner lifetime = 3d |
| lease time = floor( 3d, 3d + 1h ) = 3d |
| <---------REPLY-< | |
| lease-time=3d | |
| | >-BNDUPD-------> |
| | partner-lifetime = 1.5d + 3d
| | <----BNDREPLY-< |
| | partner-lifetime = 1.5d + 3d
acknowledged partner lifetime = 1.5d + 3d
1.5d passes ... ... ...
| | |
t+1.5d + 1/2h | >-RENEW--------> | |
| acknowledged partner lifetime = 3d |
| lease time = floor( 3d, 3d + 1h ) = 3d |
| <---------REPLY-< | |
| lease-time=3d | |
| | >-BNDUPD-------> |
| | partner-lifetime = 1.5d + 3d
| | <----BNDREPLY-< |
| | partner-lifetime = 1.5d + 3d
| acknowledged partner lifetime = 1.5d + 3d|
Figure 1: MCLT Example
5. Message and Option Definitions 5. Message and Option Definitions
5.1. Message Framing for TCP 5.1. Message Framing for TCP
Failover communication is conducted over a TCP connection established Failover communication is conducted over a TCP connection established
between the partners. The protocol uses the framing format specified between the partners. The protocol uses the framing format specified
in Section 5.1 of DHCPv6 Bulk Leasequery [RFC5460], but uses in Section 5.1 of DHCPv6 Bulk Leasequery [RFC5460], but uses
different message types with a different message format, described in different message types with a different message format, described in
Section 5.2. The TCP connection between failover servers is made to Section 5.2. The TCP connection between failover servers is made to
a specific port, the dhcp-failover port, port 647. All information a specific port, the dhcp-failover port, port 647. All information
skipping to change at page 22, line 11 skipping to change at page 24, line 11
option-code OPTION_F_CONNECT_FLAGS (TBD14). option-code OPTION_F_CONNECT_FLAGS (TBD14).
option-len 2. option-len 2.
flags flag bits, see below: flags flag bits, see below:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |F| | MBZ |F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The bits (numbered from the least-significant bit in network The bits (numbered from the most-significant bit in network
byte-order) are used as follows: byte-order) are used as follows:
0-14: MBZ 0-14: MBZ
Must be zero Must be zero
15 (F): FIXED_PD_LENGTH 15 (F): FIXED_PD_LENGTH
Set to 1 to indicate that all prefixes delegated from a Set to 1 to indicate that all prefixes delegated from a
given delegable prefix have the same prefix length (size). given delegable prefix have the same prefix length (size).
If this is not set, the prefixes delegated from one If this is not set, the prefixes delegated from one
delegable prefix may have different sizes. delegable prefix may have different sizes.
skipping to change at page 25, line 11 skipping to change at page 27, line 11
option-code OPTION_F_DNS_FLAGS (TBD18). option-code OPTION_F_DNS_FLAGS (TBD18).
option-len 2. option-len 2.
flags flag bits, see below: flags flag bits, see below:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |U|S|R|F| | MBZ |U|S|R|F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The bits (numbered from the least-significant bit in network The bits (numbered from the most-significant bit in network
byte-order) are used as follows: byte-order) are used as follows:
0-11: MBZ 0-11: MBZ
Must be zero Must be zero
12 (U): USING_REQUESTED_FQDN 12 (U): USING_REQUESTED_FQDN
Set to 1 to indicate that name used came from the Set to 1 to indicate that name used came from the
FQDN that was received from the client. FQDN that was received from the client.
13 (S): SYNTHESIZED_NAME 13 (S): SYNTHESIZED_NAME
Set to 1 to indicate that the name was synthesized Set to 1 to indicate that the name was synthesized
based on some algorithm. based on some algorithm.
skipping to change at page 33, line 10 skipping to change at page 35, line 10
option-code OPTION_F_SERVER_FLAGS (TBD30). option-code OPTION_F_SERVER_FLAGS (TBD30).
option-len 1. option-len 1.
server-flags The server flags, see below: server-flags The server flags, see below:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| MBZ |A|S|C| | MBZ |A|S|C|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The bits (numbered from the least-significant bit in network The bits (numbered from the most-significant bit in network
byte-order) are used as follows: byte-order) are used as follows:
0-4 : MBZ
Must be zero
5 (A): ACK_STARTUP 5 (A): ACK_STARTUP
Set to 1 to indicate that the OPTION_F_SERVER_FLAGS most Set to 1 to indicate that the OPTION_F_SERVER_FLAGS most
recently received contained the STARTUP bit set. recently received contained the STARTUP bit set.
6 (S): STARTUP, 6 (S): STARTUP,
MUST be set to 1 whenever the server is in STARTUP state. MUST be set to 1 whenever the server is in STARTUP state.
7 (C): COMMUNICATED 7 (C): COMMUNICATED
Set to 1 to indicate that the sending server has Set to 1 to indicate that the sending server has
communicated with its partner. communicated with its partner.
0-3 : MBZ
Must be zero
5.5.19. OPTION_F_SERVER_STATE 5.5.19. OPTION_F_SERVER_STATE
The OPTION_F_SERVER_STATE option specifies the endpoint state of the The OPTION_F_SERVER_STATE option specifies the endpoint state of the
server sending the option. server sending the option.
This is an unsigned byte. This is an unsigned byte.
The code for this option is TBD31. The code for this option is TBD31.
skipping to change at page 46, line 10 skipping to change at page 48, line 10
Which binding-status values are associated with a timeout is Which binding-status values are associated with a timeout is
implementation dependent. Some binding-status values such as ACTIVE implementation dependent. Some binding-status values such as ACTIVE
will have a timeout value in all implementations, while others such will have a timeout value in all implementations, while others such
as ABANDONDED will have a timeout value in some implementations and as ABANDONDED will have a timeout value in some implementations and
not in others. In some implementations a binding-status value may be not in others. In some implementations a binding-status value may be
associated with a timeout in some circumstances and not in other associated with a timeout in some circumstances and not in other
circumstances. The receipt of a BNDUPD with a particular binding- circumstances. The receipt of a BNDUPD with a particular binding-
status value and an OPTION_F_STATE_EXPIRATION_TIME indicates that status value and an OPTION_F_STATE_EXPIRATION_TIME indicates that
this particular binding-status value is associated with a timeout. this particular binding-status value is associated with a timeout.
The lease state machine is presented in Figure 1. Most states are The lease state machine is presented in Figure 2. Most states are
stationary, i.e. the lease stays in a given state until external stationary, i.e. the lease stays in a given state until external
event triggers transition to another state. The only transitive event triggers transition to another state. The only transitive
state is PENDING-FREE. Once it is reached, the state machine state is PENDING-FREE. Once it is reached, the state machine
immediately transitions to either FREE or FREE-BACKUP state. immediately transitions to either FREE or FREE-BACKUP state.
+---------+ +---------+
/------------->| ACTIVE |<--------------\ /------------->| ACTIVE |<--------------\
| +---------+ | | +---------+ |
| | | | | | | | | |
| /--(8)--/ (3) \--(9)-\ | | /--(8)--/ (3) \--(9)-\ |
skipping to change at page 46, line 50 skipping to change at page 48, line 50
| | | | | | | |
| /-(5)--/ \-(6)-\ | | /-(5)--/ \-(6)-\ |
| | | | | | | |
| V V | | V V |
| +-------+ +-----------+ | | +-------+ +-----------+ |
\----| FREE |<--(7)-->|FREE-BACKUP|-----/ \----| FREE |<--(7)-->|FREE-BACKUP|-----/
+-------+ +-----------+ +-------+ +-----------+
PENDING-FREE transition PENDING-FREE transition
Figure 1: Lease State Machine Figure 2: Lease State Machine
Transitions between states are results of the following events: Transitions between states are results of the following events:
1. Primary server allocates a lease. 1. Primary server allocates a lease.
2. Secondary server allocates a lease. 2. Secondary server allocates a lease.
3. Client sends RELEASE and the lease is released. 3. Client sends RELEASE and the lease is released.
4. Partner acknowledges state change. This transition MAY also 4. Partner acknowledges state change. This transition MAY also
skipping to change at page 47, line 45 skipping to change at page 49, line 45
10. An administrative action is taken to recover an abandoned 10. An administrative action is taken to recover an abandoned
lease back to usable state. This transition MAY occur due to an lease back to usable state. This transition MAY occur due to an
implementation specific handling on ABANDONED lease. One possible implementation specific handling on ABANDONED lease. One possible
example of such use is a Neighbor Discovery or ICMPv6 Echo check example of such use is a Neighbor Discovery or ICMPv6 Echo check
if the address is still in use. if the address is still in use.
The lease that is no longer in use (due to expiration or release), The lease that is no longer in use (due to expiration or release),
becomes PENDING-FREE. Depending on what allocation algorithm is becomes PENDING-FREE. Depending on what allocation algorithm is
used, the lease that is no longer is use, returns to the primary used, the lease that is no longer is use, returns to the primary
(FREE) or secondary pool (FREE-BACKUP). The conditions for specific (FREE) or secondary pool (FREE-BACKUP). The conditions for specific
transitions are depicted in Figure 2. transitions are depicted in Figure 3.
+----------------+---------+-----------+ +----------------+---------+-----------+
| \ Lease owner| | | | \ Lease owner| | |
| \----------\ | Primary | Secondary | | \----------\ | Primary | Secondary |
|Algorithm \ | | | |Algorithm \ | | |
+----------------+---------+-----------+ +----------------+---------+-----------+
| Proportional | FREE |FREE-BACKUP| | Proportional | FREE |FREE-BACKUP|
| Independent | FREE | FREE | | Independent | FREE | FREE |
+----------------+---------+-----------+ +----------------+---------+-----------+
Figure 2: PENDING-FREE State Transitions Figure 3: PENDING-FREE State Transitions
7.3. Times Required for Exchanging Binding Updates 7.3. Times Required for Exchanging Binding Updates
Each server must keep track of the following specific times beyond Each server must keep track of the following specific times beyond
those required by the base DHCP protocol [RFC3315]. those required by the base DHCP protocol [RFC3315].
expiration-time expiration-time
The greatest lifetime that this server has ever acked to its The greatest lifetime that this server has ever acked to its
failover partner in a BNDREPLY. failover partner in a BNDREPLY.
skipping to change at page 54, line 8 skipping to change at page 56, line 8
client-last-transaction-time, if one appears, and the start-time-of- client-last-transaction-time, if one appears, and the start-time-of-
state if one does not. state if one does not.
The basic approach is to compare these times, and if the one from the The basic approach is to compare these times, and if the one from the
BNDUPD message is clearly later, then accept the information in the BNDUPD message is clearly later, then accept the information in the
OPTION_CLIENT_DATA option or OPTION_IAPREFIX option. If the one from OPTION_CLIENT_DATA option or OPTION_IAPREFIX option. If the one from
the server's binding database is clearly later, then reject the the server's binding database is clearly later, then reject the
information in the BNDUPD message. The challenge comes when they are information in the BNDUPD message. The challenge comes when they are
essentially the same (i.e., +/- 5 seconds). In this case they are essentially the same (i.e., +/- 5 seconds). In this case they are
considered identical, despite the minor differences. The table below considered identical, despite the minor differences. The table below
(Figure 3) contains the rules for dealing with all of these (Figure 4) contains the rules for dealing with all of these
situations. situations.
binding-status in received OPTION_CLIENT_DATA binding-status in received OPTION_CLIENT_DATA
or OPTION_IAPREFIX or OPTION_IAPREFIX
binding-status in binding-status in
receiving server's FREE RESET receiving server's FREE RESET
lease state DB ACTIVE EXPIRED RELEASED FREE-BACKUP ABANDONED lease state DB ACTIVE EXPIRED RELEASED FREE-BACKUP ABANDONED
ACTIVE accept(3) time(1) accept time(1) accept ACTIVE accept(3) time(1) accept time(1) accept
EXPIRED accept accept accept accept accept EXPIRED accept accept accept accept accept
RELEASED accept accept accept accept accept RELEASED accept accept accept accept accept
FREE/FREE-BACKUP accept accept accept accept accept FREE/FREE-BACKUP accept accept accept accept accept
RESET time(2) accept accept accept accept RESET time(2) accept accept accept accept
ABANDONED accept accept accept accept accept ABANDONED accept accept accept accept accept
Figure 3: Conflict Resolution Figure 4: Conflict Resolution
accept: If the time value in the OPTION_CLIENT_DATA option or accept: If the time value in the OPTION_CLIENT_DATA option or
OPTION_IAPREFIX option is later than the time value in the server's OPTION_IAPREFIX option is later than the time value in the server's
binding database, accept it, else reject it. binding database, accept it, else reject it.
time(1): If the current time is later than the receiving server's time(1): If the current time is later than the receiving server's
state-expiration-time, accept it, else reject it. state-expiration-time, accept it, else reject it.
time(2): If the OPTION_CLT_TIME value (if it appears) in the time(2): If the OPTION_CLT_TIME value (if it appears) in the
OPTION_CLIENT_DATA is later than the start-time-of-state in the OPTION_CLIENT_DATA is later than the start-time-of-state in the
skipping to change at page 60, line 40 skipping to change at page 62, line 40
Receiving Server <- BNDUPD message <- Sending Server Receiving Server <- BNDUPD message <- Sending Server
[ always update ] [ always update ]
acked-partner-lifetime PARTNER_LIFETIME_SENT duplicate of received acked-partner-lifetime PARTNER_LIFETIME_SENT duplicate of received
PARTNER_LIFETIME PARTNER_LIFETIME
(nothing to update) STATE_EXPIRATION_TIME state-expiration-time (nothing to update) STATE_EXPIRATION_TIME state-expiration-time
------------------------------------------------------------- -------------------------------------------------------------
Figure 4: BNDUPD and BNDREPLY Time Handling Figure 5: BNDUPD and BNDREPLY Time Handling
8. Endpoint States 8. Endpoint States
8.1. State Machine Operation 8.1. State Machine Operation
Each server (or, more accurately, failover endpoint) can take on a Each server (or, more accurately, failover endpoint) can take on a
variety of failover states. These states play a crucial role in variety of failover states. These states play a crucial role in
determining the actions that a server will perform when processing a determining the actions that a server will perform when processing a
request from a DHCP client as well as dealing with changing external request from a DHCP client as well as dealing with changing external
conditions (e.g., loss of connection to a failover partner). conditions (e.g., loss of connection to a failover partner).
skipping to change at page 63, line 52 skipping to change at page 65, line 52
| State: State: Start Auto | or | State: State: Start Auto | or
| RECOVER-DONE NORMAL Partner Down Comm. OK Auto | RECOVER-DONE NORMAL Partner Down Comm. OK Auto
| | COMM. INT. Timer Other State: Partner | | COMM. INT. Timer Other State: Partner
| Comm. OK. | V All Others Down | Comm. OK. | V All Others Down
| Other State: | +---------+--------+ | expiration | Other State: | +---------+--------+ | expiration
| RECOVER +--+ COMMUNICATIONS - +----+ | | RECOVER +--+ COMMUNICATIONS - +----+ |
| +-------------+ INTERRUPTED | | | +-------------+ INTERRUPTED | |
RECOVER | (responsive) +------------------------->+ RECOVER | (responsive) +------------------------->+
RECOVER-WAIT--------->+------------------+ RECOVER-WAIT--------->+------------------+
Figure 5: Failover Endpoint State Machine Figure 6: Failover Endpoint State Machine
8.2. State Machine Initialization 8.2. State Machine Initialization
The state machine is characterized by storage (in stable storage) of The state machine is characterized by storage (in stable storage) of
at least the following information: at least the following information:
o Current failover state. o Current failover state.
o Previous failover state. o Previous failover state.
skipping to change at page 64, line 50 skipping to change at page 66, line 50
8.3. STARTUP State 8.3. STARTUP State
The STARTUP state affords an opportunity for a server to probe its The STARTUP state affords an opportunity for a server to probe its
partner server, before starting to service DHCP clients. When in the partner server, before starting to service DHCP clients. When in the
STARTUP state, a server attempts to learn its partner's state and STARTUP state, a server attempts to learn its partner's state and
determine (using that information if it is available) what state it determine (using that information if it is available) what state it
should enter. should enter.
The STARTUP state is not shown with any specific state transitions in The STARTUP state is not shown with any specific state transitions in
the state machine diagram (Figure 5) because the processing during the state machine diagram (Figure 6) because the processing during
the STARTUP state can cause the server to transition to any of the the STARTUP state can cause the server to transition to any of the
other states, so that specific state transition arcs would only other states, so that specific state transition arcs would only
obscure other information. obscure other information.
8.3.1. Operation in STARTUP State 8.3.1. Operation in STARTUP State
The server MUST NOT be responsive to DHCP clients in STARTUP state. The server MUST NOT be responsive to DHCP clients in STARTUP state.
Whenever a STATE message is sent to the partner while in STARTUP Whenever a STATE message is sent to the partner while in STARTUP
state the STARTUP flag MUST be set in the message and the previously state the STARTUP flag MUST be set in the message and the previously
skipping to change at page 70, line 40 skipping to change at page 72, line 40
RECOVER-DONE | RECOVER-DONE |
| | | |
| >--STATE-(RECOVER-DONE)------> | | >--STATE-(RECOVER-DONE)------> |
| NORMAL | NORMAL
| <-------------(NORMAL)-STATE--< | | <-------------(NORMAL)-STATE--< |
NORMAL | NORMAL |
| >---- State-(NORMAL)---------------> | | >---- State-(NORMAL)---------------> |
| | | |
| | | |
Figure 6: Transition out of RECOVER state Figure 7: Transition out of RECOVER state
If at any time while a server is in RECOVER state communication If at any time while a server is in RECOVER state communication
fails, the server will stay in RECOVER state. When communications fails, the server will stay in RECOVER state. When communications
are restored, it will restart the process of transitioning out of are restored, it will restart the process of transitioning out of
RECOVER state. RECOVER state.
8.6. RECOVER-WAIT State 8.6. RECOVER-WAIT State
This state indicates that the server has sent an UPDREQ or UPDREQALL This state indicates that the server has sent an UPDREQ or UPDREQALL
and has received the UPDDONE message indicating that it has received and has received the UPDDONE message indicating that it has received
skipping to change at page 76, line 41 skipping to change at page 78, line 41
| <--------------------POOLREQ--< | | <--------------------POOLREQ--< |
| >--POOLRESP------------------> | | >--POOLRESP------------------> |
| | | |
| >--BNDUPD-(#1)---------------> | | >--BNDUPD-(#1)---------------> |
| <-------------------BNDREPLY--< | | <-------------------BNDREPLY--< |
| | | |
| >--BNDUPD-(#2)---------------> | | >--BNDUPD-(#2)---------------> |
| <-------------------BNDREPLY--< | | <-------------------BNDREPLY--< |
| | | |
Figure 7: Transition from NORMAL to COMMUNICATIONS-INTERRUPTED and Figure 8: Transition from NORMAL to COMMUNICATIONS-INTERRUPTED and
back back
8.10. POTENTIAL-CONFLICT State 8.10. POTENTIAL-CONFLICT State
This state indicates that the two servers are attempting to This state indicates that the two servers are attempting to
reintegrate with each other, but at least one of them was running in reintegrate with each other, but at least one of them was running in
a state that did not guarantee automatic reintegration would be a state that did not guarantee automatic reintegration would be
possible. In POTENTIAL-CONFLICT state the servers may determine that possible. In POTENTIAL-CONFLICT state the servers may determine that
the same lease has been offered and accepted by two different the same lease has been offered and accepted by two different
clients. clients.
skipping to change at page 78, line 41 skipping to change at page 80, line 41
| >--UPDDONE-------------------> | | >--UPDDONE-------------------> |
| NORMAL | NORMAL
| <------------STATE--(NORMAL)--< | | <------------STATE--(NORMAL)--< |
NORMAL | NORMAL |
| >--STATE--(NORMAL)-----------> | | >--STATE--(NORMAL)-----------> |
| | | |
| <--------------------POOLREQ--< | | <--------------------POOLREQ--< |
| >------POOLRESP--------------> | | >------POOLRESP--------------> |
| | | |
Figure 8: Transition out of POTENTIAL-CONFLICT Figure 9: Transition out of POTENTIAL-CONFLICT
8.11. RESOLUTION-INTERRUPTED State 8.11. RESOLUTION-INTERRUPTED State
This state indicates that the two servers were attempting to This state indicates that the two servers were attempting to
reintegrate with each other in POTENTIAL-CONFLICT state, but reintegrate with each other in POTENTIAL-CONFLICT state, but
communication failed prior to completion of re-integration. communication failed prior to completion of re-integration.
The RESOLUTION-INTERRUPTED state exists because servers are not The RESOLUTION-INTERRUPTED state exists because servers are not
responsive in POTENTIAL-CONFLICT state, and if one server drops out responsive in POTENTIAL-CONFLICT state, and if one server drops out
of service while both servers are in POTENTIAL-CONFLICT state, the of service while both servers are in POTENTIAL-CONFLICT state, the
skipping to change at page 88, line 27 skipping to change at page 90, line 27
ServerShuttingDown (TBD38) ServerShuttingDown (TBD38)
DNSUpdateNotSupported (TBD39) DNSUpdateNotSupported (TBD39)
ExcessiveTimeSkew (TBD40) ExcessiveTimeSkew (TBD40)
12. Acknowledgements 12. Acknowledgements
This document extensively uses concepts, definitions and other parts This document extensively uses concepts, definitions and other parts
of an effort to document failover for DHCPv4. Authors would like to of an effort to document failover for DHCPv4. Authors would like to
thank Shawn Routher, Greg Rabil, Bernie Volz and Marcin Siodelski for thank Shawn Routhier, Greg Rabil, Bernie Volz and Marcin Siodelski
their significant involvement and contributions. In particular, for their significant involvement and contributions. In particular,
Bernie Volz and Shawn Routher provided detailed and substantive Bernie Volz and Shawn Routhier provided detailed and substantive
technical reviews of the draft. Authors would like to thank technical reviews of the draft. Authors would like to thank
VithalPrasad Gaitonde, Krzysztof Gierlowski, Krzysztof Nowicki and VithalPrasad Gaitonde, Krzysztof Gierlowski, Krzysztof Nowicki and
Michal Hoeft for their insightful comments. Michal Hoeft for their insightful comments.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
 End of changes. 25 change blocks. 
135 lines changed or deleted 181 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/