intarea R. Patterson Internet-Draft Sky UK Intended status: Standards Track M. Abrahamsson Expires: April 4, 2019 T-Systems October 01, 2018 IP over Ethernet (IPoE) Session Health Checking draft-patterson-intarea-ipoe-health-05 Abstract PPP over Ethernet clients have the functionality to detect path unavailability by using PPP Keepalives. IP over Ethernet does not have this functionality, and it is not specified in the IETF when an IP over Ethernet client should consider its WAN connectivity down, unless there is a physical layer link down event. This document describes a mechanism for IP over Ethernet clients to achieve connectivity validation, similar to that of PPP over Ethernet, by using BFD Echo, or an alternative health check mechanism. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 4, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of Patterson & Abrahamsson Expires April 4, 2019 [Page 1] Internet-Draft IPoE-Health October 2018 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Alternative Mitigations . . . . . . . . . . . . . . . . . . . 4 3. IPoE Health Checks . . . . . . . . . . . . . . . . . . . . . 4 3.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Startup . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. BFD Echo . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. IPoE Health Check Probe . . . . . . . . . . . . . . . . . 5 4. IPoE Health Check DHCP Options . . . . . . . . . . . . . . . 6 4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Recovery Behaviour . . . . . . . . . . . . . . . . . . . . . 7 5.1. LAN Considerations . . . . . . . . . . . . . . . . . . . 9 6. Multihomed Clients . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. Appendix A. Changes from -00 . . . . . . . . . . . . . . . . 10 11. Appendix B. Changes from -01 . . . . . . . . . . . . . . . . 10 12. Appendix C. Changes from -02 . . . . . . . . . . . . . . . . 10 13. Appendix D. Changes from -03 . . . . . . . . . . . . . . . . 11 14. Appendix E. Changes from -04 . . . . . . . . . . . . . . . . 11 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 15.1. Normative References . . . . . . . . . . . . . . . . . . 11 15.2. Informative References . . . . . . . . . . . . . . . . . 12 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction PPP [RFC1661] makes use of regular LCP echos and replies to continually test the data link layer, if the peer fails to respond to a predetermined number of LCP echos, the PPP session is terminated and will return to the Link Dead phase, ready for reestablishing. IPoE currently lacks this functionality. Patterson & Abrahamsson Expires April 4, 2019 [Page 2] Internet-Draft IPoE-Health October 2018 Physical link state change on an IPoE client can trigger the renewing of a DHCP lease, however any indirect upstream network changes are not visible to the IPoE client. An outage or planned maintenance work on, for example, a Broadband Network Gateways (BNG) or intermediate DHCP Relay, can leave an IPoE client with a stale DHCP lease for up to the Valid Lifetime. IPoE Session Health Check allows for an IPoE client to proactively or passively monitor the state of upstream connectivity, and defines several actions that may be taken to help the client recover. [TR-146], Section 6.2 describes this problem, while [TR-124] identifies some requirements to solve the problem. Several vendors have implemented subscriber connectivity checking on their BNG, using ARP and Neighbor Discovery as per Sections 6.2.4 and 6.2.5 of [TR-146]. This allows the BNG to detect loss of connectivity and to update local session state and DHCP lease bindings. Without reciprocal checking, this puts the CE at further risk of being in a stale state. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology This document makes use of the following terms: o BNG: Broadband Network Gateway. Often also running a DHCP server or relay. o CE: Customer Equipment. aka. Customer Premise Equipment (CPE), Residential Gateway (RG). o IPoE: IP over Ethernet. o IPoE Client: A network device, often a CE, running a DHCPv4 and/or DHCPv6 client. o IPoE Health Check: The name of the process described in this document. Patterson & Abrahamsson Expires April 4, 2019 [Page 3] Internet-Draft IPoE-Health October 2018 2. Alternative Mitigations o Short DHCP lease times reduce the time a client may be left in a stale state, but scale poorly, putting extra load on the DHCP server. o Broadband Forum's [TR-146] and [TR-124] discuss this problem and recommend the use of BFD echo [RFC5880]. This document acknowledges TR-146 and recommends the use of BFD echo for health checks, but like the Broadband Forum, acknowledges that it is not widely available within consumer CEs. The renew action specified in TR-146 is often insufficient for a network to authenticate an IPoE Client, leaving the client in a stale state for up to the lease expiry, and no better off than without the check. This document introduces an alternative action to help expedite client recovery. o For planned maintenance, network engineers could include DHCPv4 Force Renew [RFC3203] or DHCPv6 Reconfigure [RFC3315]-bis in their maintenance plans, however neither of these have been widely adopted by CE or BNG vendors due to authentication complexity. 3. IPoE Health Checks 3.1. Parameters IPoE Health Check uses the following parameters: o Interval (Integer): The frequency in seconds, which health checks are sent by the IPoE client. Default value: 120 seconds. o Retry Interval (Integer): The frequency in seconds, which health checks are sent by the IPoE client, after a failure. Default value: 10 seconds. o Limit (Integer): The number of failed consecutive checks before an action is taken. Default value: 3. o Release (Boolean): Instructs the client to send a DHCP RELEASE and to not attempt a renewal of the current lease. Default value: 0. An IPoE client MAY be statically configured for IPoE health checks. Non-default static parameters SHOULD override any signalled via a dynamic means (e.g, DHCP or TR-69). An IPoE client MAY use default parameters in lieu of manually configured, or dynamically signalled parameters (DHCP for example). Patterson & Abrahamsson Expires April 4, 2019 [Page 4] Internet-Draft IPoE-Health October 2018 Statically configured or dynamically signalled parameters SHOULD override any default parameters. 3.2. Startup An IPoE client supporting IPoE Health Check MUST begin sending health checks at the Retry Interval (Section 3.1) specified, upon successful binding of a lease that contains a valid IPoE Health Check DHCP Option (Section 4), or for which it has been statically configured. After Limit IPoE health checks succeeds consecutively, the IPoE client MUST begin sending health checks at the regular Interval. If Limit IPoE health checks fail consecutively, IPoE Health Check should be considered unusable and the IPoE client MUST cease the sending of health checks, ignoring the recovery behaviour (Section 5). 3.3. BFD Echo If the IPoE Client supports BFD [RFC5880], it SHOULD use BFD Echo as the health check mechanism. If the IPoE Client does not support BFD, or if it is unable to establish a BFD session with the upstream router, it MUST use IPoE Health Check Probe Section 3.4 as the health check mechanism. 3.4. IPoE Health Check Probe Similar in format to a BFD Echo packet, the IPoE Health Check probe is a simple UDP/IP packet with a destination IP address from the lease being checked, and a destination MAC address of the upstream router. However, unlike BFD Echo, an IPoE Health Check probe does not require a BFD session to be established between peers; allowing for less state and configuration on a BNG and a simpler CPE implementation. The destination IP MUST be an address locally bound on the IPoE client and MUST be from the lease triggering the IPoE Health Check. The source IP SHOULD be the same as the destination address, but MAY be another address bound to the same interface the health check probe is being sent out. E.g. The link-local or a DHCPv6 NA assigned address. The source MAC address MUST belong to the IPoE Client interface of the lease being checked. The destination MAC address MUST be address of the upstream router. Patterson & Abrahamsson Expires April 4, 2019 [Page 5] Internet-Draft IPoE-Health October 2018 Using an IP packet as the health check probe not only validates the layer 2 forwarding path, but also validates the DHCP lease state. 4. IPoE Health Check DHCP Options This document defines a new option for both DHCPv4 and DHCPv6 servers to signal suggested health check parameters to clients. IPoE clients SHOULD use these values when no statically configured parameters have been defined. The option data fields are common between DHCPv6 and DHCPv4. 4.1. DHCPv6 For DHCPv6, this option (Figure 1) MUST be within a specific Identity Association as an IPoE client MAY have multiple IAs with different health check parameters. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | limit |R| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | retry-interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: DHCPv6 IPoE Check Option Format The description of the fields is as follows: option-code: OPTION_IPOE_HEALTH (TBA1). option-len: 12. limit: Consecutive failed checks, before an action is taken. R: Release flag. Instructs the client to send a DHCP RELEASE when a failure is detected, and to skip the renew step. interval: Indicates how often a health check should be sent when no failure is encountered. Expressed in units of seconds. retry-interval: Indicates how often a health check should be sent after a previous failure. Expressed in units of seconds. Patterson & Abrahamsson Expires April 4, 2019 [Page 6] Internet-Draft IPoE-Health October 2018 4.2. DHCPv4 The DHCPv4 client can retrieve IPoE Health Check information by including OPTION_IPOE_HEALTH in a Parameter Request List option [RFC2132]. Figure 2 shows the DHCPv4 IPoE Health Check option. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | limit |R| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | retry-interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: DHCPv4 IPoE Health Check Option Format The description of the fields is as follows: option-code: OPTION_IPOE_HEALTH (TBA2). option-len: 10. limit: Consecutive failed checks, before an action is taken. R: Release flag. Instructs the client to send a DHCP RELEASE when a failure is detected, and to skip the renew step. interval: Indicates how often a health check should be sent when no failure is encountered. Expressed in units of seconds. retry-interval: Indicates how often a health check should be sent after a previous failure. Expressed in units of seconds. 5. Recovery Behaviour IPoE Health Check defines the behaviour that an IPoE Client should take once the timeout threshold has been reached. This behaviour makes use of existing procedures outlined in [RFC2131], Section 4.4.5 for DHCPv4, and [RFC3315]-bis, Sections 18.2.4, 18.2.5 for DHCPv6. When triggering a DISCOVER or SOLICIT, an IPoE client may also choose to use Rapid Commit [RFC4039], [RFC3315], Section 22.14 to help expedite the recovery process. After Limit (Section 3.1) consecutive check failures, T1 and T2 MUST both be set to zero. Patterson & Abrahamsson Expires April 4, 2019 [Page 7] Internet-Draft IPoE-Health October 2018 If the Release Flag (Section 3.1) is unset, the IPoE client SHOULD immediately attempt to renew the current lease from the original server. If connectivity to the original DHCP server has recovered, and the server can satisfy the request, the lease may be renewed and timers updated. If the renew is unsuccessful, the IPoE client MUST move to the discovery or solicit phase. If the Release Flag is unset, the IPoE client MUST keep the address or prefix in the preferred state until the preferred lifetime expires, and MUST keep the address or prefix until the valid lifetime expires. If the Release Flag is set the IPoE Client MUST NOT send a DHCP RENEW, it MUST send a RELEASE as per [RFC2131], Section 3.1 for DHCPv4 and [RFC3315]-bis, Section 18.2.7. If the IPoE client is already in the renew or rebind state when this behaviour is triggered, the client MUST cease renew or rebind attempts and wait for any outstanding messages to time out before sending a RELEASE. If an outstanding renew or rebind attempt is successful, the IPoE client MUST update T1, T2 and lease lifetimes appropriately, and MUST NOT continue with this behaviour. Once the RELEASE process has completed, the IPoE Client should move to the discovery or solicit phase. The IPoE client MUST include the current address or prefix in the IA Address or IA_PD options within the DHCPv6 SOLICIT, or in the Requested IP Address Option of a DHCPv4 DISCOVER [RFC2131], Section 4.4.2. The DHCPv6 SOLICIT DUID and IAID values MUST be the same as used in the current lease. If the DHCP server assigns the current address or prefix, the IPoE client MUST update the current lease timers, and any differing parameters. If the DHCP server assigns an alternate address or prefix, the IPoE client MUST deprecate the current lease and follow the actions outlined in requirement L-13 [RFC7084], Section 4.3 Patterson & Abrahamsson Expires April 4, 2019 [Page 8] Internet-Draft IPoE-Health October 2018 5.1. LAN Considerations If all DHCPv6 leases have expired, either naturally or proactively with IPoE health checks, an IPoE client acting as a router, SHOULD withdraw itself as a default router on the LAN, following requirement G-5 of [RFC7084], Section 4.1. 6. Multihomed Clients An IPoE client may have multiple leases from the same, or different DHCP servers. These leases may have different IPoE health check parameters, and health checks MUST be treated distinctly, tracking the particular lease that they belong to. Local network administrators may choose to override DHCP-signalled parameters in order to facilitate appropriate IPoE Health Check operation in a multihomed environment. 7. Security Considerations IPoE Health Check frequency would typically be controlled by the network using DHCP options, but overly aggressive, statically configured IPoE Health Checks, could have an adverse impact. For example, this may induce an overload on the IP access nodes. However, BFD Echo and the IPoE Health Check probe defined in this document, both use an IP packet destined for the IPoE client, the remote peer forwards the packet back to the IPoE client without any local processing. The inclusion of the current lease address or prefix when sending a DISCOVER or SOLICIT, introduces a privacy risk, possibly leaking lease information if the IPoE client has been moved to a different network, e.g., from one fixed line provider to another. 8. IANA Considerations IANA is requested to assign a new DHCPv6 Option Code in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters [1]: Option Name Value -------------------- ----- OPTION_IPOE_HEALTH TBA1 Also, IANA is requested to assign the following new DHCPv4 Option Code in the registry maintained in http://www.iana.org/assignments/ bootp-dhcp-parameters [2]: Patterson & Abrahamsson Expires April 4, 2019 [Page 9] Internet-Draft IPoE-Health October 2018 Option Name Tag Data Length Meaning -------------------- --- ----------- -------------------------------- OPTION_IPOE_HEALTH TBA2 14 Provides a set of IPoE check configuration information. 9. Acknowledgements The authors would like thank Ian Farrer, Dusan Mudric, Mohamed Boucadair, Jean-Yves Cloarec, Bernie Volz, Barbara Stark, Dave Freedman, and Job Snijders for their review and comments on this and previous versions of this document. 10. Appendix A. Changes from -00 This section should be removed by the RFC Editor. o Added reference to TR-146. o Added BFD Echo section, and wording to prefer it as the health check mechanism over ARP/ND, if available. 11. Appendix B. Changes from -01 This section should be removed by the RFC Editor. o Emphasised preference for use of BFD echo as the health check mechanism. o Removed lifetime expiration from Behaviour 2 and clarified usage. o Updated Behaviour 3 with instructions for whilst mid-renew/rebind. o Reworded multihoming section. o Added Acknowledgements. 12. Appendix C. Changes from -02 This section should be removed by the RFC Editor. o Added DHCP option flag to force ARP/ND for health checks. o Populated IANA Considerations. o Added Retry Interval distinct timer for between failed checks. o Added default parameter values. Patterson & Abrahamsson Expires April 4, 2019 [Page 10] Internet-Draft IPoE-Health October 2018 13. Appendix D. Changes from -03 This section should be removed by the RFC Editor. o Reduced default Limit value. o Formatting and minor cosmetic changes. 14. Appendix E. Changes from -04 This section should be removed by the RFC Editor. This revision is a major rewrite. Changes include: o Consolidated the multiple behaviours down to one. o Added a Release flag instead of a distinct behaviour. o Added custom IPoE Health Check Probe definition. o Removed ARP/ND and Passive checks. o Removed alternative target address parameter. o Removed IANA registry request for Behaviour values. 15. References 15.1. Normative References [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, . [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, . [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, . [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, . Patterson & Abrahamsson Expires April 4, 2019 [Page 11] Internet-Draft IPoE-Health October 2018 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . 15.2. Informative References [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP reconfigure extension", RFC 3203, DOI 10.17487/RFC3203, December 2001, . [RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)", RFC 4039, DOI 10.17487/RFC4039, March 2005, . [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, March 2011, . [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [TR-124] "Functional Requirements for Broadband Residential Gateway Devices", 2006, . [TR-146] "Subscriber Sessions", 2013, . Patterson & Abrahamsson Expires April 4, 2019 [Page 12] Internet-Draft IPoE-Health October 2018 15.3. URIs [1] http://www.iana.org/assignments/dhcpv6-parameters [2] http://www.iana.org/assignments/bootp-dhcp-parameters Authors' Addresses Richard Patterson Sky UK Email: richard.patterson@sky.uk Mikael Abrahamsson T-Systems Email: mikael.abrahamsson@t-systems.se Patterson & Abrahamsson Expires April 4, 2019 [Page 13]