idnits 2.17.1 draft-patterson-intarea-ipoe-health-02.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 (June 19, 2018) is 2137 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: December 21, 2018 T-Systems 6 June 19, 2018 8 IPoE Client Health Checking 9 draft-patterson-intarea-ipoe-health-02 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's not specified when an IP over 16 Ethernet client should consider its WAN connectivity down, unless 17 there is a physical layer link down event. 19 This document describes a way for IP over Ethernet clients to achieve 20 connectivity validation, similar to that of PPP over Ethernet, by 21 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 December 21, 2018. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Alternative Mitigations . . . . . . . . . . . . . . . . . . . 3 61 3. IPoE Health Checks . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. BFD Echo . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.3. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 5 65 3.4. ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.5. Alternative Target . . . . . . . . . . . . . . . . . . . 5 67 3.6. Passive Checks . . . . . . . . . . . . . . . . . . . . . 5 68 4. Action Behaviours . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Behaviour 0: Renew (Default) . . . . . . . . . . . . . . 6 70 4.2. Behaviour 1: Rebind . . . . . . . . . . . . . . . . . . . 6 71 4.3. Behaviour 2: Solicit . . . . . . . . . . . . . . . . . . 7 72 4.4. Behaviour 3: Expire & Release . . . . . . . . . . . . . . 7 73 4.5. LAN Considerations . . . . . . . . . . . . . . . . . . . 8 74 5. DHCP Option . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 5.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 5.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 6. Multihomed Clients . . . . . . . . . . . . . . . . . . . . . 10 78 6.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 10 79 6.2. ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 83 10. Appendix A. Changes from -00 . . . . . . . . . . . . . . . . 11 84 11. Appendix B. Changes from -01 . . . . . . . . . . . . . . . . 11 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 87 12.2. Informative References . . . . . . . . . . . . . . . . . 12 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 PPP [RFC1661] makes use of regular LCP echos and replies to 93 continually test the data link layer, if the peer fails to respond to 94 a predetermined number of LCP echos, the PPP session is terminated 95 and will return to the Link Dead phase, ready for reestablishing. 96 IPoE currently lacks this functionality. 98 Physical link state change on an IPoE client can trigger the renewing 99 of a DHCP lease, however any indirect upstream network changes are 100 not visible to the IPoE client. 101 An outage or planned maintenance work on a BNG or intermediate DHCP 102 Relay, can leave an IPoE client with a stale DHCP lease for up to the 103 Valid Lifetime. 105 IPoE Health Check allows for an IPoE client to proactively or 106 passively monitor the state of upstream connectivity, and defines 107 several actions that may be taken to help the client recover. 109 1.1. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 1.2. Terminology 119 o BNG: Broadband Network Gateway. Often also running a DHCP server 120 or relay. 122 o CE: Customer Equipment. aka. Customer Premise Equipment (CPE), 123 Residential Gateway (RG). 125 o IPoE: IP over Ethernet. 127 o IPoE Client: A network device, often a CE, running a DHCPv4 and/or 128 DHCPv6 client. 130 o IPoE Health Check: The name of the process described in this 131 document. 133 2. Alternative Mitigations 135 o Short DHCP lease times reduce the time a client may be left in a 136 stale state, but scale poorly, putting extra load on the DHCP 137 server. 139 o Broadband Forum's [TR-146], Section 6.2.2 discusses this problem 140 and suggests the use of BFD echo [RFC5880]. This document 141 acknowledges TR-146 and recommends the use of BFD echo for health 142 checks, but notes that it is not widely available within consumer 143 CEs. This document also introduces alternative actions, as the 144 renew approach taken in TR-146 is susceptible to the issues 145 described in Behaviour 0 (Section 4.1). 147 o For planned work, network engineers could include DHCPv4 Force 148 Renew [RFC3203] or DHCPv6 Reconfigure [RFC3315]-bis in their 149 maintenance plans, however neither of these have been widely 150 adopted by CE or BNG vendors due to authentication complexity. 152 3. IPoE Health Checks 154 An IPoE client supporting IPoE Health Check SHOULD begin sending 155 health checks at the Interval specified, upon successful binding of a 156 lease that contains a valid IPoE Health Check DHCP Option. 158 An IPoE client MAY be locally configured for IPoE health checks. 159 Non-default local parameters SHOULD override any signalled via DHCP. 161 An IPoE client MAY use default parameters in lieu of manually 162 configured, or DHCP signalled parameters. Manually configured or 163 DHCP signalled parameters SHOULD override any default parameters. 165 3.1. Parameters 167 IPoE Health Check specifies the following parameters: 169 o Interval (Integer): The frequency in seconds, which health checks 170 are sent by the IPoE client. 172 o Limit (Integer): The number of consecutive checks that can fail 173 before an action is taken. 175 o Behaviour (Integer): Specifies what additional actions are to be 176 taken when triggered. 178 o Passive (Boolean): Forces passive health checks instead of active. 180 o Alternative Target Address (IP): Overrides the default gateway as 181 the target of health checks. 183 3.2. BFD Echo 185 An IPoE client SHOULD use BFD Echo [RFC5880] as the health check 186 mechanism. 188 If BFD echos are used, the destination IP address MUST be locally 189 bound on the IPoE client and SHOULD be from the lease triggering the 190 IPoE Health Check. 192 The use of BFD Echo as the health check mechanism provides the added 193 benefit of validating the DHCP lease state, proving layer 3 as well 194 as layer 2 connectivity. 196 3.3. Neighbor Discovery 198 If an IPoE client with active DHCPv6 leases is unable to send BFD 199 echos, it MUST send Neighbor Solicits [RFC4861], Section 4.3 for the 200 target address. If no Alternative Target Address is set, the target 201 address SHOULD be the default gateway as obtained from the Operating 202 System. 203 Neighbor Solicits SHOULD be sent at the frequency set by the Interval 204 parameter (Section 3.1). 206 3.4. ARP 208 If an IPoE client with active DHCPv4 leases is unable to send BFD 209 echos, it MUST send ARP requests [RFC0826] for the target address. 210 If no Alternative Target Address is set, the target address SHOULD be 211 the client's default gateway, as received within the DHCPv4 Option 3 212 Router option of the lease. 213 ARP requests SHOULD be sent at the frequency set by the Interval 214 parameter (Section 3.1). 216 3.5. Alternative Target 218 An alternative IP address MAY be included within the IPoE health 219 check DHCP option, or locally configured. If an alternative target 220 address is specified, it MUST be used as the target for health checks 221 instead of the default gateway. 223 If an alternative target address provided is outside of a locally 224 attached route, health checks SHOULD implicitly fail until a matching 225 local route is installed. If a matching locally attached route is 226 subsequently installed, health checks SHOULD continue as normal. 228 3.6. Passive Checks 230 If an IPoE client is unable to proactively send health checks itself, 231 it SHOULD passively check the operating system's ARP and Neighbor 232 cache tables. 234 In IPoE Health Check passive mode, alternate target addresses outside 235 of locally attached routes MUST NOT be supported. 237 Passive IPoE health checks SHOULD use the health check parameters 238 signalled by DHCP or configured locally. The IPoE client SHOULD 239 passively check the ARP or Neighbor cache tables for the target 240 address, every Interval (Section 3.1) seconds. If the neighbor entry 241 is in state INCOMPLETE for Limit (Section 3.1) checks, the specified 242 IPoE Health Check Action MUST be taken. 244 Passive-only mode can be forced either by local configuration, or by 245 a DHCP server setting the Passive flag in the DHCP Option. If 246 passive-only mode has been set, the IPoE client MUST only use passive 247 checking for that particular lease health check. 249 4. Action Behaviours 251 IPoE Health Check defines four configurable behaviours once the 252 timeout threshold has been reached. All three behaviours make use of 253 existing procedures outlined in [RFC2131], Section 4.4.5 for DHCPv4, 254 and [RFC3315]-bis, Sections 18.2.4, 18.2.5 for DHCPv6. 256 IPoE Health Check behaviour MAY be signalled per lease by DHCP, or 257 locally configured. Locally configured, non-default, behaviour 258 settings SHOULD take precedence over those signalled by DHCP. 260 4.1. Behaviour 0: Renew (Default) 262 After Limit (Section 3.1) consecutive failures, the IPoE client MUST 263 set T1 of the specified lease, to zero. This will trigger a RENEW to 264 the original DHCP server, as per [RFC3315]-bis and [RFC2131]. 266 If connectivity to the original DHCP server has recovered, and the 267 server can satisfy the request, the lease may be renewed and timers 268 updated. 269 If the original DHCP server cannot satisfy the request, it may reject 270 the request, to which the DHCP client should begin discovery or 271 solicit phase anew. 273 Neither of the above two responses are guaranteed, and as such, an 274 administrator may elect to use one of the below additional behaviours 275 to help expedite the IPoE client's recovery process. 277 Unless specified otherwise, additional actions MUST also be taken if 278 the DHCP Option Behaviour bits are non-zero. Some behaviours may 279 offer alternative actions instead of compound ones, they will state 280 this specifically. 282 4.2. Behaviour 1: Rebind 284 If the Behaviour field is set to 1, T2 MUST also be set to zero, 285 along with T1. This tells the IPoE client to immediately move to the 286 rebind phase, attempting to renew the lease from any available 287 server. 289 This method can be useful in a resilient layer 2 access topology, 290 with multiple active DHCP servers. 292 4.3. Behaviour 2: Solicit 294 If the Behaviour field is set to 2, T1 and T2 MUST both be set to 295 zero as per previous behaviours. 297 The IPoE client MUST skip the renew and rebind phases, moving 298 straight to the discovery or solicit phase. 300 The IPoE client MUST NOT send a DHCP RELEASE. 302 The IPoE client MUST keep the address or prefix in the preferred 303 state until the preferred lifetime expires, and MUST keep the address 304 or prefix until the valid lifetime expires. 306 The IPoE client SHOULD include the lease address or prefix in the 307 DISCOVER or SOLICIT. 309 The DUID and IAID MUST be the same as used in the current lease. 311 This method can be useful when using DHCP servers that silently 312 discard unknown renew attempts instead of sending back a DHCPv4 NAK 313 or DHCPv6 Reply. 315 4.4. Behaviour 3: Expire & Release 317 If the Behaviour field is set to 3, T1, T2, and Valid Lifetime MUST 318 all be set to 0, and the IPoE Client MUST send a DHCP RELEASE message 319 as per [RFC2131], Section 3.1 for DHCPv4 and [RFC3315]-bis, 320 Section 18.2.7 322 Once the RELEASE process has completed, the client returns to the 323 discovery or solicit phase. 325 If the IPoE client is already in the renew or rebind state when 326 Behaviour 3 is triggered, the client MUST cease renew or rebind 327 attempts and wait for any outstanding messages to time out before 328 sending a RELEASE. If an outstanding renew or rebind attempt is 329 successful, the IPoE client MUST update T1, T2 and lease lifetimes 330 appropriately, and MUST NOT continue with Behaviour 3. 332 This method can be useful to clean out state within the network. For 333 example, a DHCP relay may be left with stale lease information after 334 an outage or maintenance on a DHCP server. 336 4.5. LAN Considerations 338 If all DHCPv6 leases have expired, either naturally or proactively 339 with IPoE health checks, it is expected than an IPoE client acting as 340 a router, would withdraw itself as a default router on the LAN, 341 following requirement G-5 of [RFC7084], Section 4.1. 343 5. DHCP Option 345 IPoE Health Check defines a new option for both DHCPv4 and DHCPv6 346 servers to signal suggested health check parameters to clients. 347 IPoE clients SHOULD use these values when no locally configured 348 parameters have been defined. 350 The option data fields are common between DHCPv6 and DHCPv4, with the 351 exception of the alternate target address field, which is 32 bits in 352 the DHCPv4 option and 128 bits in the DHCPv6 option. 354 5.1. DHCPv6 356 For DHCPv6, this Option MUST be within a specific Identity 357 Association as an IPoE client MAY have multiple IAs with different 358 health check parameters. 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | option-code | option-len | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | limit |P| behaviour | reserved | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | interval | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | | 370 | alternate- | 371 | target-address | 372 | | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 Figure 1: DHCPv6 Option Format 377 option-code: OPTION_IPOE_HEALTH (TBD). 378 option-len: 24. 379 limit: Consecutive failed checks, before an action is taken. 380 P: Passive Flag. Force passive-only health checks. 381 behaviour: Behaviour field. 382 0: Trigger Renew. 383 1: Trigger Rebind. 384 2: Expire lease, start solicit phase. 385 3: Release. 386 4 - 127: Reserved. 387 interval: How often a health check should be sent. 388 Expressed in units of seconds. 389 alternate-target-address: Optional health check target address. 390 Always present, set to zero if no address provided. 392 Figure 2 394 5.2. DHCPv4 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | option-code | option-len | limit |P| behaviour | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | interval | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | alternate-target-address | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 Figure 3: DHCPv4 Option Format 408 option-code: OPTION_IPOE_HEALTH (TBD). 409 option-len: 10. 410 limit: Consecutive failed checks, before an action is taken. 411 P: Passive Flag. Force passive-only health checks. 412 behaviour: Behaviour field. 413 0: Trigger Renew. 414 1: Trigger Rebind. 415 2: Expire lease, start discovery phase. 416 3: Release. 417 4 - 127: Reserved. 418 interval: How often a health check should be sent. 419 Expressed in units of seconds. 420 alternate-target-address: Optional health check target address. 421 Always present, set to zero if no address provided. 423 Figure 4 425 6. Multihomed Clients 427 An IPoE client MAY have multiple leases from the same, or different 428 DHCP servers. These leases MAY have different IPoE health check 429 parameters, and health checks MUST be treated distinctly, tracking 430 the particular lease that they belong to. 432 Each distinct IPoE health check MUST use an appropriate target 433 address as per IPoE Health Check (Section 3). 435 If an IPoE client is configured with multiple IPoE Health Checks that 436 use the same target address, it SHOULD suppress additional checks, 437 preferring the parameters with the lowest timeout value. 438 I.e. Timeout = Interval * Limit 440 Local network administrators may choose to override DHCP-signalled 441 parameters in order to facilitate appropriate IPoE Health Check 442 operation in a multihomed environment. 444 6.1. Neighbor Discovery 446 As DHCPv6 does not convey default gateway or other routing 447 information, an IPoE client using the ND health check method SHOULD 448 obtain the target address by querying the operating system for 449 default routes.\ 451 If multiple default routes exist, ND-based IPoE health checks SHOULD 452 attempt to match the target address to the lease by the interface the 453 lease is bound to. 455 If only a single default route exists, and that default route is not 456 routed out the interface the lease was bound to, ND-based health 457 checks for that particular lease SHOULD be paused. 459 6.2. ARP 461 ARP-based IPoE health checks for DHCPv4 make use of the default 462 gateway address specified in the lease. As a route for each gateway 463 should exist regardless of current route preference, health checks 464 SHOULD be run for each lease that is configured for IPoE health 465 check. 467 7. Security Considerations 469 While ARP and Neighbor Discovery are more likely to be handled by 470 hardware linecards compared to DHCP messaging, they may be subject to 471 protections outlined in [RFC6192]. Routers SHOULD ensure that 472 sufficient quantities of this traffic are permitted to safely ingress 473 the control plane. 475 IPoE Health Check frequency would typically be controlled by the 476 Network using DHCP Options, but overly zealous, locally configured 477 IPoE clients, could have an adverse impact. 479 Unlike ARP and ND, BFD echo uses an IP packet destined for the IPoE 480 client, the peer forwards the packet back to the IPoE client without 481 any local processing. 483 Behaviour 2 (Section 4.3) introduces a privacy risk, possibly leaking 484 lease information if the IPoE client has been moved to a different 485 network, e.g., from one fixed line provider to another. The authors 486 believe this not to be a major concern. 488 8. IANA Considerations 490 IPoE Health Check requires the allocation of two new DHCP Options. 491 One for DHCPv4 and one for DHCPv6. The option for both will be 492 referred to as OPTION_IPOE_HEALTH. 494 9. Acknowledgements 496 The authors would like thank Ian Farrer, Dusan Mudric, Bernie Volz, 497 Dave Freedman, and Job Snijders for their review and comments on this 498 and previous versions of this document. 500 10. Appendix A. Changes from -00 502 This section should be removed by the RFC Editor. 504 o Added reference to TR-146. 506 o Added BFD Echo section, and wording to prefer it as the health 507 check mechanism over ARP/ND, if available. 509 11. Appendix B. Changes from -01 511 This section should be removed by the RFC Editor. 513 o Emphasised preference for use of BFD echo as the health check 514 mechanism. 516 o Removed lifetime expiration from Behaviour 2 and clarified usage. 518 o Updated Behaviour 3 with instructions for whilst mid-renew/rebind. 520 o Reworded multihoming section. 522 o Added Acknowledgements. 524 12. References 526 12.1. Normative References 528 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 529 Converting Network Protocol Addresses to 48.bit Ethernet 530 Address for Transmission on Ethernet Hardware", STD 37, 531 RFC 826, DOI 10.17487/RFC0826, November 1982, 532 . 534 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 535 RFC 2131, DOI 10.17487/RFC2131, March 1997, 536 . 538 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 539 C., and M. Carney, "Dynamic Host Configuration Protocol 540 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 541 2003, . 543 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 544 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 545 DOI 10.17487/RFC4861, September 2007, 546 . 548 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 549 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 550 . 552 12.2. Informative References 554 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 555 STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 556 . 558 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 559 Requirement Levels", BCP 14, RFC 2119, 560 DOI 10.17487/RFC2119, March 1997, 561 . 563 [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP 564 reconfigure extension", RFC 3203, DOI 10.17487/RFC3203, 565 December 2001, . 567 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 568 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 569 March 2011, . 571 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 572 Requirements for IPv6 Customer Edge Routers", RFC 7084, 573 DOI 10.17487/RFC7084, November 2013, 574 . 576 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 577 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 578 May 2017, . 580 [TR-146] "TR-146 Subscriber Sessions", 2013, 581 . 584 Authors' Addresses 586 Richard Patterson 587 Sky UK 589 Email: richard.patterson@sky.uk 591 Mikael Abrahamsson 592 T-Systems 594 Email: mikael.abrahamsson@t-systems.se