Internet DRAFT - draft-patterson-intarea-ipoe-health
draft-patterson-intarea-ipoe-health
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,
<https://www.rfc-editor.org/info/rfc826>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<https://www.rfc-editor.org/info/rfc2132>.
[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, <https://www.rfc-editor.org/info/rfc3315>.
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,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
15.2. Informative References
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
<https://www.rfc-editor.org/info/rfc1661>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP
reconfigure extension", RFC 3203, DOI 10.17487/RFC3203,
December 2001, <https://www.rfc-editor.org/info/rfc3203>.
[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,
<https://www.rfc-editor.org/info/rfc4039>.
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
Router Control Plane", RFC 6192, DOI 10.17487/RFC6192,
March 2011, <https://www.rfc-editor.org/info/rfc6192>.
[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,
<https://www.rfc-editor.org/info/rfc7084>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[TR-124] "Functional Requirements for Broadband Residential Gateway
Devices", 2006, <https://www.broadband-
forum.org/technical/download/TR-124.pdf>.
[TR-146] "Subscriber Sessions", 2013, <https://www.broadband-
forum.org/technical/download/TR-146.pdf>.
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]
