idnits 2.17.1 draft-patterson-intarea-ipoe-health-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 02, 2018) is 2125 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 709 -- Looks like a reference, but probably isn't: '2' on line 711 == Missing Reference: 'ThisRFC' is mentioned on line 577, but not defined == Missing Reference: 'RFC8126' is mentioned on line 580, but not defined ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 intarea R. Patterson 3 Internet-Draft Sky UK 4 Intended status: Standards Track M. Abrahamsson 5 Expires: January 3, 2019 T-Systems 6 July 02, 2018 8 IP over Ethernet (IPoE) Session Health Checking 9 draft-patterson-intarea-ipoe-health-04 11 Abstract 13 PPP over Ethernet clients have the functionality to detect path 14 unavailability by using PPP Keepalives. IP over Ethernet does not 15 have this functionality, and it is not specified in the IETF when an 16 IP over Ethernet client should consider its WAN connectivity down, 17 unless there is a physical layer link down event. 19 This document describes a mechanism for IP over Ethernet clients to 20 achieve connectivity validation, similar to that of PPP over 21 Ethernet, by using BFD Echo, or ARP and Neighbor Discovery functions. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 3, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Alternative Mitigations . . . . . . . . . . . . . . . . . . . 4 61 3. IPoE Health Checks . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. BFD Echo . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.3. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 5 65 3.4. ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.5. Alternative Target . . . . . . . . . . . . . . . . . . . 6 67 3.6. Passive Checks . . . . . . . . . . . . . . . . . . . . . 6 68 4. IPoE Health Check DHCP Options . . . . . . . . . . . . . . . 7 69 4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5. Action Behaviours . . . . . . . . . . . . . . . . . . . . . . 9 72 5.1. Behaviour 0: Renew (Default) . . . . . . . . . . . . . . 9 73 5.2. Behaviour 1: Rebind . . . . . . . . . . . . . . . . . . . 10 74 5.3. Behaviour 2: Solicit . . . . . . . . . . . . . . . . . . 10 75 5.4. Behaviour 3: Expire & Release . . . . . . . . . . . . . . 11 76 5.5. LAN Considerations . . . . . . . . . . . . . . . . . . . 11 77 6. Multihomed Clients . . . . . . . . . . . . . . . . . . . . . 11 78 6.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 12 79 6.2. ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 83 10. Appendix A. Changes from -00 . . . . . . . . . . . . . . . . 13 84 11. Appendix B. Changes from -01 . . . . . . . . . . . . . . . . 14 85 12. Appendix C. Changes from -02 . . . . . . . . . . . . . . . . 14 86 13. Appendix D. Changes from -03 . . . . . . . . . . . . . . . . 14 87 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 89 14.2. Informative References . . . . . . . . . . . . . . . . . 15 90 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 PPP [RFC1661] makes use of regular LCP echos and replies to 96 continually test the data link layer, if the peer fails to respond to 97 a predetermined number of LCP echos, the PPP session is terminated 98 and will return to the Link Dead phase, ready for reestablishing. 99 IPoE currently lacks this functionality. 101 Physical link state change on an IPoE client can trigger the renewing 102 of a DHCP lease, however any indirect upstream network changes are 103 not visible to the IPoE client. 104 An outage or planned maintenance work on, for example, a Broadband 105 Network Gateways (BNG) or intermediate DHCP Relay, can leave an IPoE 106 client with a stale DHCP lease for up to the Valid Lifetime. 108 IPoE Session Health Check allows for an IPoE client to proactively or 109 passively monitor the state of upstream connectivity, and defines 110 several actions that may be taken to help the client recover. 112 [TR-146], Section 6.2 describes this problem, while [TR-124] 113 identifies some requirements to solve the problem. 115 Several vendors have implemented subscriber connectivity checking on 116 their BNG, using ARP and Neighbor Discovery as per Sections 6.2.4 and 117 6.2.5 of [TR-146]. This allows the BNG to detect loss of 118 connectivity and to update local session state and DHCP lease 119 bindings. Without reciprocal checking, this puts the CE at further 120 risk of being in a stale state. 122 1.1. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 1.2. Terminology 132 This document makes use of the following terms: 134 o BNG: Broadband Network Gateway. Often also running a DHCP server 135 or relay. 137 o CE: Customer Equipment. aka. Customer Premise Equipment (CPE), 138 Residential Gateway (RG). 140 o IPoE: IP over Ethernet. 142 o IPoE Client: A network device, often a CE, running a DHCPv4 and/or 143 DHCPv6 client. 145 o IPoE Health Check: The name of the process described in this 146 document. 148 2. Alternative Mitigations 150 o Short DHCP lease times reduce the time a client may be left in a 151 stale state, but scale poorly, putting extra load on the DHCP 152 server. 154 o Broadband Forum's [TR-146] and [TR-124] discuss this problem and 155 recommend the use of BFD echo [RFC5880]. This document 156 acknowledges TR-146 and recommends the use of BFD echo for health 157 checks, but like the Broadband Forum, acknowledges that it is not 158 widely available within consumer CEs. 159 This document also introduces alternative actions, as the renew 160 approach taken in TR-146 is susceptible to the issues described in 161 Behaviour 0 (Section 5.1). 163 o For planned maintenance, network engineers could include DHCPv4 164 Force Renew [RFC3203] or DHCPv6 Reconfigure [RFC3315]-bis in their 165 maintenance plans, however neither of these have been widely 166 adopted by CE or BNG vendors due to authentication complexity. 168 3. IPoE Health Checks 170 3.1. Parameters 172 IPoE Health Check uses the following parameters: 174 o Interval (Integer): The frequency in seconds, which health checks 175 are sent by the IPoE client. Default value: 120 seconds. 177 o Retry Interval (Integer): The frequency in seconds, which health 178 checks are sent by the IPoE client, after a failure. Default 179 value: 10 seconds. 181 o Limit (Integer): The number of failed consecutive checks before an 182 action is taken. Default value: 3. 184 o Behaviour (Integer): Specifies what actions are to be taken when 185 triggered. Default value: 0. 187 o Passive (Boolean): Forces passive health checks instead of active. 188 Default: False. 190 o Layer2 (Boolean): Forces layer 2 health checks instead of BFD 191 echo. Default: False. 193 o Alternative Target Address (IP address): Overrides the default 194 target of health checks. 196 An IPoE client supporting IPoE Health Check SHOULD begin sending 197 health checks at the Interval specified, upon successful binding of a 198 lease that contains a valid IPoE Health Check DHCP Option 199 (Section 4). 201 An IPoE client MAY be statically configured for IPoE health checks. 202 Non-default static parameters SHOULD override any signalled via a 203 dynamic means (e.g, DHCP or TR-69). 205 An IPoE client MAY use default parameters in lieu of manually 206 configured, or dynamically signalled parameters (DHCP for example). 207 Statically configured or dynamically signalled parameters SHOULD 208 override any default parameters. 210 3.2. BFD Echo 212 Unless instructed otherwise, an IPoE client SHOULD use BFD Echo 213 [RFC5880] as the health check mechanism. 214 The use of BFD Echo as the health check mechanism provides the added 215 benefit of validating the DHCP lease state, proving layer 3 as well 216 as layer 2 connectivity. 218 If BFD echo messages are used, the destination IP address MUST be 219 locally bound on the IPoE client and SHOULD be from the lease 220 triggering the IPoE Health Check. 222 3.3. Neighbor Discovery 224 If an IPoE client with active DHCPv6 leases is unable to send BFD 225 echo messages or IPoE client is explicitly configured, it MUST send 226 Neighbor Solicits (Section 4.3 of [RFC4861]) for the target address. 227 If no Alternative Target Address is set, the target address SHOULD be 228 the default gateway as obtained from the Operating System. 229 Neighbor Solicits SHOULD be sent at the frequency set by the Interval 230 parameter under normal conditions or Retry Interval when a failure is 231 encountered (Section 3.1). 233 3.4. ARP 235 If an IPoE client with active DHCPv4 leases is unable to send BFD 236 echo messages or IPoE client is explicitly configured, it MUST send 237 ARP requests [RFC0826] for the target address. If no Alternative 238 Target Address is set, the target address SHOULD be the client's 239 default gateway, as received within the DHCPv4 Option 3 Router option 240 of the lease [RFC2132]. 241 ARP requests SHOULD be sent at the frequency set by the Interval 242 parameter under normal conditions or Retry Interval when a failure is 243 encountered (Section 3.1). 245 3.5. Alternative Target 247 An alternative target IP address MAY be included in the IPoE health 248 check DHCP option, or statically configured. If an alternative 249 target address is specified, it MUST be used as the target for health 250 checks instead of the default gateway. 252 If an Alternative Target Address provided is outside of a locally 253 attached route, health checks SHOULD implicitly fail until a matching 254 local route is installed. If a matching locally attached route is 255 subsequently installed, health checks SHOULD continue as normal. 257 The Alternative Target IP Address MUST be a valid IP address. An 258 IPoE client MUST silently discard loopback and multicast addresses. 260 3.6. Passive Checks 262 If an IPoE client is unable to proactively send health checks itself, 263 it SHOULD passively check the operating system's ARP and Neighbor 264 cache tables. 266 In IPoE Health Check passive mode, alternate target addresses outside 267 of locally attached routes MUST NOT be supported. 269 Passive IPoE health checks SHOULD use the health check parameters 270 signalled by DHCP or configured statically (Section 3.1). The IPoE 271 client SHOULD passively check the ARP or Neighbor cache tables for 272 the target address, every Interval seconds. If the neighbor entry is 273 in state INCOMPLETE, subsequent checks SHOULD BE made every Retry 274 Interval seconds. When Limit checks have failed, the specified IPoE 275 Health Check Action MUST be taken. 277 Passive-only mode can be forced either by local configuration, or by 278 a DHCP server setting the Passive flag in the DHCP option. If 279 passive-only mode has been set, the IPoE client MUST only use passive 280 checking for that particular lease health check. 282 4. IPoE Health Check DHCP Options 284 This document defines a new option for both DHCPv4 and DHCPv6 servers 285 to signal suggested health check parameters to clients. 286 IPoE clients SHOULD use these values when no statically configured 287 parameters have been defined. 289 The option data fields are common between DHCPv6 and DHCPv4, with the 290 exception of the alternate target address field, which is 32 bits in 291 the DHCPv4 option and 128 bits in the DHCPv6 option. 293 4.1. DHCPv6 295 For DHCPv6, this option (Figure 1) MUST be within a specific Identity 296 Association as an IPoE client MAY have multiple IAs with different 297 health check parameters. 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | option-code | option-len | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | limit |P|L| behaviour | reserved | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | interval | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | retry-interval | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | | 311 | alternate- | 312 | target-address | 313 | | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Figure 1: DHCPv6 IPoE Check Option Format 318 The description of the fields is as follows: 320 option-code: OPTION_IPOE_HEALTH (TBA1). 321 option-len: 28. 322 limit: Consecutive failed checks, before an action is taken. 323 P: Passive Flag. Force passive-only health checks. 324 L: Layer 2 Flag. Force ARP/ND-only health checks. 325 behaviour: The following behaviours are defined: 326 0: Trigger Renew (Section 5.1). 327 1: Trigger Rebind (Section 5.2). 328 2: Expire lease, start solicit phase (Section 5.3). 329 3: Release (Section 5.4). 330 4 - 63: Unassigned. 331 New behaviour codes can be assigned in the future. 332 interval: Indicates how often a health check should be sent when 333 no failure is encountered. Expressed in units of seconds. 334 retry-interval: Indicates how often a health check should be sent 335 after a previous failure. Expressed in units of seconds. 336 alternate-target-address: Optional health check target address. 337 MUST always present; it MUST be set to zero if no 338 alternate IP address is to be used. This field MUST NOT 339 include loopback or multicast addresses. 341 4.2. DHCPv4 343 The DHCPv4 client can retrieve IPoE Health Check information by 344 including OPTION_IPOE_HEALTH in a Parameter Request List option 345 [RFC2132]. 347 Figure 2 shows the DHCPv4 IPoE Health Check option. 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | option-code | option-len | limit |P|L| behaviour | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | interval | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | retry-interval | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | alternate-target-address | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 Figure 2: DHCPv4 IPoE Health Check Option Format 363 The description of the fields is as follows: 365 option-code: OPTION_IPOE_HEALTH (TBA2). 366 option-len: 14. 367 limit: Consecutive failed checks, before an action is taken. 368 P: Passive Flag. Force passive-only health checks. 369 L: Layer 2 Flag. Force ARP/ND-only health checks. 370 behaviour: The following behaviours are defined: 371 0: Trigger Renew (Section 5.1). 372 1: Trigger Rebind (Section 5.2). 373 2: Expire lease, start solicit phase (Section 5.3). 374 3: Release (Section 5.4). 375 4 - 63: Unassigned. 376 New behaviour codes can be assigned in the future. 377 interval: Indicates how often a health check should be sent when 378 no failure is encountered. Expressed in units of seconds. 379 retry-interval: Indicates how often a health check should be sent 380 after a previous failure. Expressed in units of seconds. 381 alternate-target-address: Optional health check target address. 382 MUST always present; it MUST be set to zero if no 383 alternate IP address is to be used. This field MUST NOT 384 include loopback or multicast addresses. 386 5. Action Behaviours 388 IPoE Health Check defines four configurable behaviours once the 389 timeout threshold has been reached. All these behaviours make use of 390 existing procedures outlined in [RFC2131], Section 4.4.5 for DHCPv4, 391 and [RFC3315]-bis, Sections 18.2.4, 18.2.5 for DHCPv6. 393 The IPoE Health Check behaviour MAY be signalled per lease by DHCP, 394 or statically configured. Statically configured, non-default, 395 behaviour settings SHOULD take precedence over those signalled by 396 DHCP. 398 When triggering a DISCOVER or SOLICIT, an IPoE client may also choose 399 to use Rapid Commit [RFC4039], [RFC3315], Section 22.14 to help 400 expedite the recovery process. 402 5.1. Behaviour 0: Renew (Default) 404 After Limit (Section 3.1) consecutive check failures, the IPoE client 405 MUST set T1 of the specified lease, to zero. This will trigger a 406 RENEW to the original DHCP server, as per [RFC3315]-bis and 407 [RFC2131]. 409 If connectivity to the original DHCP server has recovered, and the 410 server can satisfy the request, the lease may be renewed and timers 411 updated. 413 If the original DHCP server cannot satisfy the request, it may reject 414 the request, to which the DHCP client should begin discovery or 415 solicit phase anew. 417 Neither of the above two responses are guaranteed, and as such, an 418 administrator may elect to use one of the below additional behaviours 419 to help expedite the IPoE client's recovery process. 421 Unless specified otherwise, additional actions MUST also be taken if 422 the IPoE Health Check DHCP option Behaviour bits are non-zero. Some 423 behaviours may offer alternative actions instead of compound ones, 424 they will state this specifically. 426 5.2. Behaviour 1: Rebind 428 If the Behaviour field is set to 1, T2 MUST also be set to zero, 429 along with T1. This tells the IPoE client to immediately move to the 430 rebind phase, attempting to renew the lease from any available 431 server. 433 This method can be useful in a resilient layer 2 access topology, 434 with multiple active DHCP servers. 436 5.3. Behaviour 2: Solicit 438 If the Behaviour field is set to 2, T1 and T2 MUST both be set to 439 zero as per previous behaviours. 441 The IPoE client MUST skip the renew and rebind phases, moving 442 straight to the discovery or solicit phase. 444 The IPoE client MUST NOT send a DHCP RELEASE. 446 The IPoE client MUST keep the address or prefix in the preferred 447 state until the preferred lifetime expires, and MUST keep the address 448 or prefix until the valid lifetime expires. 450 The IPoE client SHOULD include the lease address or prefix in the 451 DISCOVER or SOLICIT. 453 The DUID and IAID MUST be the same as used in the current lease. 455 This method can be useful when using DHCP servers that silently 456 discard unknown renew attempts instead of sending back a DHCPv4 NAK 457 or DHCPv6 Reply. 459 5.4. Behaviour 3: Expire & Release 461 If the Behaviour field is set to 3, T1, T2, and Valid Lifetime MUST 462 all be set to 0, and the IPoE Client MUST send a DHCP RELEASE message 463 as per [RFC2131], Section 3.1 for DHCPv4 and [RFC3315]-bis, 464 Section 18.2.7 466 Once the RELEASE process has completed, the client returns to the 467 discovery or solicit phase. 469 If the IPoE client is already in the renew or rebind state when 470 Behaviour 3 is triggered, the client MUST cease renew or rebind 471 attempts and wait for any outstanding messages to time out before 472 sending a RELEASE. If an outstanding renew or rebind attempt is 473 successful, the IPoE client MUST update T1, T2 and lease lifetimes 474 appropriately, and MUST NOT continue with Behaviour 3. 476 This method can be useful to clean out state within the network. For 477 example, a DHCP relay may be left with stale lease information after 478 an outage or maintenance on a DHCP server. 480 5.5. LAN Considerations 482 If all DHCPv6 leases have expired, either naturally or proactively 483 with IPoE health checks, it is expected than an IPoE client acting as 484 a router, would withdraw itself as a default router on the LAN, 485 following requirement G-5 of [RFC7084], Section 4.1. 487 6. Multihomed Clients 489 An IPoE client may have multiple leases from the same, or different 490 DHCP servers. These leases may have different IPoE health check 491 parameters, and health checks MUST be treated distinctly, tracking 492 the particular lease that they belong to. 494 Each distinct IPoE health check MUST use an appropriate target 495 address as per IPoE Health Check (Section 3). 497 If an IPoE client is configured with multiple IPoE Health Checks that 498 use the same target address, it SHOULD suppress additional checks, 499 preferring the parameters with the lowest timeout value. 500 I.e. Timeout = Interval + Retry Interval * (Limit - 1) 502 Local network administrators may choose to override DHCP-signalled 503 parameters in order to facilitate appropriate IPoE Health Check 504 operation in a multihomed environment. 506 6.1. Neighbor Discovery 508 As DHCPv6 does not convey default gateway or other routing 509 information, an IPoE client using the ND health check method SHOULD 510 obtain the target address by querying the operating system for 511 default routes. 513 If multiple default routes exist, ND-based IPoE health checks SHOULD 514 attempt to match the target address to the lease by the interface the 515 lease is bound to. 517 If only a single default route exists, and that default route is not 518 routed out the interface the lease was bound to, ND-based health 519 checks for that particular lease SHOULD be paused. 521 6.2. ARP 523 ARP-based IPoE health checks for DHCPv4 make use of the default 524 gateway address specified in the lease. As a route for each gateway 525 should exist regardless of current route preference, health checks 526 SHOULD be run for each lease that is configured for IPoE health 527 check. 529 7. Security Considerations 531 IPoE Health Check frequency would typically be controlled by the 532 network using DHCP options, but overly aggressive, statically 533 configured IPoE Health Checks, could have an adverse impact. For 534 example, this may induce an overload on the IP access nodes. 536 ARP and Neighbor Discovery may be subject to protections outlined in 537 [RFC6192]; Interval and Retry Interval values SHOULD NOT be set too 538 aggressively and upstream routers SHOULD ensure that sufficient 539 quantities of this traffic are permitted to safely ingress the 540 control plane. 542 Unlike ARP and ND, BFD echo uses an IP packet destined for the IPoE 543 client, the peer forwards the packet back to the IPoE client without 544 any local processing. 546 Behaviour 2 (Section 5.3) introduces a privacy risk, possibly leaking 547 lease information if the IPoE client has been moved to a different 548 network, e.g., from one fixed line provider to another. 550 8. IANA Considerations 552 IANA is requested to assign a new DHCPv6 Option Code in the registry 553 maintained in http://www.iana.org/assignments/dhcpv6-parameters [1]: 555 Option Name Value 556 -------------------- ----- 557 OPTION_IPOE_HEALTH TBA1 559 Also, IANA is requested to assign the following new DHCPv4 Option 560 Code in the registry maintained in http://www.iana.org/assignments/ 561 bootp-dhcp-parameters [2]: 563 Option Name Tag Data Length Meaning 564 -------------------- --- ----------- -------------------------------- 565 OPTION_IPOE_HEALTH TBA2 14 Provides a set of IPoE check 566 configuration information. 568 This document requests IANA to create a new registry called "IPoE 569 Check Behaviours" (under https://www.iana.org/assignments/dhcpv6- 570 parameters/dhcpv6-parameters.xhtml). 571 This registry is initially populated with the following values: 573 Value Description Reference 574 0 Trigger Renew [ThisRFC] 575 1 Trigger Rebind [ThisRFC] 576 2 Expire lease [ThisRFC] 577 3 Release [ThisRFC] 579 Values in the range 4-63 are assigned via the "IETF Review" policy 580 defined in [RFC8126]. 582 The same registry is used for both DHCPv4 and DHCPv6. 584 9. Acknowledgements 586 The authors would like thank Ian Farrer, Dusan Mudric, Mohamed 587 Boucadair, Jean-Yves Cloarec, Bernie Volz, Dave Freedman, and Job 588 Snijders for their review and comments on this and previous versions 589 of this document. 591 10. Appendix A. Changes from -00 593 This section should be removed by the RFC Editor. 595 o Added reference to TR-146. 597 o Added BFD Echo section, and wording to prefer it as the health 598 check mechanism over ARP/ND, if available. 600 11. Appendix B. Changes from -01 602 This section should be removed by the RFC Editor. 604 o Emphasised preference for use of BFD echo as the health check 605 mechanism. 607 o Removed lifetime expiration from Behaviour 2 and clarified usage. 609 o Updated Behaviour 3 with instructions for whilst mid-renew/rebind. 611 o Reworded multihoming section. 613 o Added Acknowledgements. 615 12. Appendix C. Changes from -02 617 This section should be removed by the RFC Editor. 619 o Added DHCP option flag to force ARP/ND for health checks. 621 o Populated IANA Considerations. 623 o Added Retry Interval distinct timer for between failed checks. 625 o Added default parameter values. 627 13. Appendix D. Changes from -03 629 This section should be removed by the RFC Editor. 631 o Reduced default Limit value. 633 o Formatting and minor cosmetic changes. 635 14. References 637 14.1. Normative References 639 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 640 Converting Network Protocol Addresses to 48.bit Ethernet 641 Address for Transmission on Ethernet Hardware", STD 37, 642 RFC 826, DOI 10.17487/RFC0826, November 1982, 643 . 645 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 646 RFC 2131, DOI 10.17487/RFC2131, March 1997, 647 . 649 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 650 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 651 . 653 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 654 C., and M. Carney, "Dynamic Host Configuration Protocol 655 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 656 2003, . 658 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 659 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 660 DOI 10.17487/RFC4861, September 2007, 661 . 663 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 664 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 665 . 667 14.2. Informative References 669 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 670 STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 671 . 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, 675 DOI 10.17487/RFC2119, March 1997, 676 . 678 [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP 679 reconfigure extension", RFC 3203, DOI 10.17487/RFC3203, 680 December 2001, . 682 [RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for 683 the Dynamic Host Configuration Protocol version 4 684 (DHCPv4)", RFC 4039, DOI 10.17487/RFC4039, March 2005, 685 . 687 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 688 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 689 March 2011, . 691 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 692 Requirements for IPv6 Customer Edge Routers", RFC 7084, 693 DOI 10.17487/RFC7084, November 2013, 694 . 696 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 697 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 698 May 2017, . 700 [TR-124] "Functional Requirements for Broadband Residential Gateway 701 Devices", 2006, . 704 [TR-146] "Subscriber Sessions", 2013, . 707 14.3. URIs 709 [1] http://www.iana.org/assignments/dhcpv6-parameters 711 [2] http://www.iana.org/assignments/bootp-dhcp-parameters 713 Authors' Addresses 715 Richard Patterson 716 Sky UK 718 Email: richard.patterson@sky.uk 720 Mikael Abrahamsson 721 T-Systems 723 Email: mikael.abrahamsson@t-systems.se