idnits 2.17.1 draft-patterson-intarea-ipoe-health-05.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 (October 01, 2018) is 2033 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 569 -- Looks like a reference, but probably isn't: '2' on line 571 == Unused Reference: 'RFC0826' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'RFC6192' is defined on line 547, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 4 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: April 4, 2019 T-Systems 6 October 01, 2018 8 IP over Ethernet (IPoE) Session Health Checking 9 draft-patterson-intarea-ipoe-health-05 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 an alternative health check 22 mechanism. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 4, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Alternative Mitigations . . . . . . . . . . . . . . . . . . . 4 62 3. IPoE Health Checks . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.2. Startup . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.3. BFD Echo . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.4. IPoE Health Check Probe . . . . . . . . . . . . . . . . . 5 67 4. IPoE Health Check DHCP Options . . . . . . . . . . . . . . . 6 68 4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 5. Recovery Behaviour . . . . . . . . . . . . . . . . . . . . . 7 71 5.1. LAN Considerations . . . . . . . . . . . . . . . . . . . 9 72 6. Multihomed Clients . . . . . . . . . . . . . . . . . . . . . 9 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 76 10. Appendix A. Changes from -00 . . . . . . . . . . . . . . . . 10 77 11. Appendix B. Changes from -01 . . . . . . . . . . . . . . . . 10 78 12. Appendix C. Changes from -02 . . . . . . . . . . . . . . . . 10 79 13. Appendix D. Changes from -03 . . . . . . . . . . . . . . . . 11 80 14. Appendix E. Changes from -04 . . . . . . . . . . . . . . . . 11 81 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 15.1. Normative References . . . . . . . . . . . . . . . . . . 11 83 15.2. Informative References . . . . . . . . . . . . . . . . . 12 84 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 PPP [RFC1661] makes use of regular LCP echos and replies to 90 continually test the data link layer, if the peer fails to respond to 91 a predetermined number of LCP echos, the PPP session is terminated 92 and will return to the Link Dead phase, ready for reestablishing. 93 IPoE currently lacks this functionality. 95 Physical link state change on an IPoE client can trigger the renewing 96 of a DHCP lease, however any indirect upstream network changes are 97 not visible to the IPoE client. 98 An outage or planned maintenance work on, for example, a Broadband 99 Network Gateways (BNG) or intermediate DHCP Relay, can leave an IPoE 100 client with a stale DHCP lease for up to the Valid Lifetime. 102 IPoE Session Health Check allows for an IPoE client to proactively or 103 passively monitor the state of upstream connectivity, and defines 104 several actions that may be taken to help the client recover. 106 [TR-146], Section 6.2 describes this problem, while [TR-124] 107 identifies some requirements to solve the problem. 109 Several vendors have implemented subscriber connectivity checking on 110 their BNG, using ARP and Neighbor Discovery as per Sections 6.2.4 and 111 6.2.5 of [TR-146]. This allows the BNG to detect loss of 112 connectivity and to update local session state and DHCP lease 113 bindings. Without reciprocal checking, this puts the CE at further 114 risk of being in a stale state. 116 1.1. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in BCP 121 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 1.2. Terminology 126 This document makes use of the following terms: 128 o BNG: Broadband Network Gateway. Often also running a DHCP server 129 or relay. 131 o CE: Customer Equipment. aka. Customer Premise Equipment (CPE), 132 Residential Gateway (RG). 134 o IPoE: IP over Ethernet. 136 o IPoE Client: A network device, often a CE, running a DHCPv4 and/or 137 DHCPv6 client. 139 o IPoE Health Check: The name of the process described in this 140 document. 142 2. Alternative Mitigations 144 o Short DHCP lease times reduce the time a client may be left in a 145 stale state, but scale poorly, putting extra load on the DHCP 146 server. 148 o Broadband Forum's [TR-146] and [TR-124] discuss this problem and 149 recommend the use of BFD echo [RFC5880]. This document 150 acknowledges TR-146 and recommends the use of BFD echo for health 151 checks, but like the Broadband Forum, acknowledges that it is not 152 widely available within consumer CEs. 153 The renew action specified in TR-146 is often insufficient for a 154 network to authenticate an IPoE Client, leaving the client in a 155 stale state for up to the lease expiry, and no better off than 156 without the check. 157 This document introduces an alternative action to help expedite 158 client recovery. 160 o For planned maintenance, network engineers could include DHCPv4 161 Force Renew [RFC3203] or DHCPv6 Reconfigure [RFC3315]-bis in their 162 maintenance plans, however neither of these have been widely 163 adopted by CE or BNG vendors due to authentication complexity. 165 3. IPoE Health Checks 167 3.1. Parameters 169 IPoE Health Check uses the following parameters: 171 o Interval (Integer): The frequency in seconds, which health checks 172 are sent by the IPoE client. Default value: 120 seconds. 174 o Retry Interval (Integer): The frequency in seconds, which health 175 checks are sent by the IPoE client, after a failure. Default 176 value: 10 seconds. 178 o Limit (Integer): The number of failed consecutive checks before an 179 action is taken. Default value: 3. 181 o Release (Boolean): Instructs the client to send a DHCP RELEASE and 182 to not attempt a renewal of the current lease. Default value: 0. 184 An IPoE client MAY be statically configured for IPoE health checks. 185 Non-default static parameters SHOULD override any signalled via a 186 dynamic means (e.g, DHCP or TR-69). 188 An IPoE client MAY use default parameters in lieu of manually 189 configured, or dynamically signalled parameters (DHCP for example). 191 Statically configured or dynamically signalled parameters SHOULD 192 override any default parameters. 194 3.2. Startup 196 An IPoE client supporting IPoE Health Check MUST begin sending health 197 checks at the Retry Interval (Section 3.1) specified, upon successful 198 binding of a lease that contains a valid IPoE Health Check DHCP 199 Option (Section 4), or for which it has been statically configured. 201 After Limit IPoE health checks succeeds consecutively, the IPoE 202 client MUST begin sending health checks at the regular Interval. 204 If Limit IPoE health checks fail consecutively, IPoE Health Check 205 should be considered unusable and the IPoE client MUST cease the 206 sending of health checks, ignoring the recovery behaviour 207 (Section 5). 209 3.3. BFD Echo 211 If the IPoE Client supports BFD [RFC5880], it SHOULD use BFD Echo as 212 the health check mechanism. 214 If the IPoE Client does not support BFD, or if it is unable to 215 establish a BFD session with the upstream router, it MUST use IPoE 216 Health Check Probe Section 3.4 as the health check mechanism. 218 3.4. IPoE Health Check Probe 220 Similar in format to a BFD Echo packet, the IPoE Health Check probe 221 is a simple UDP/IP packet with a destination IP address from the 222 lease being checked, and a destination MAC address of the upstream 223 router. However, unlike BFD Echo, an IPoE Health Check probe does 224 not require a BFD session to be established between peers; allowing 225 for less state and configuration on a BNG and a simpler CPE 226 implementation. 228 The destination IP MUST be an address locally bound on the IPoE 229 client and MUST be from the lease triggering the IPoE Health Check. 231 The source IP SHOULD be the same as the destination address, but MAY 232 be another address bound to the same interface the health check probe 233 is being sent out. E.g. The link-local or a DHCPv6 NA assigned 234 address. 236 The source MAC address MUST belong to the IPoE Client interface of 237 the lease being checked. 238 The destination MAC address MUST be address of the upstream router. 240 Using an IP packet as the health check probe not only validates the 241 layer 2 forwarding path, but also validates the DHCP lease state. 243 4. IPoE Health Check DHCP Options 245 This document defines a new option for both DHCPv4 and DHCPv6 servers 246 to signal suggested health check parameters to clients. 247 IPoE clients SHOULD use these values when no statically configured 248 parameters have been defined. 250 The option data fields are common between DHCPv6 and DHCPv4. 252 4.1. DHCPv6 254 For DHCPv6, this option (Figure 1) MUST be within a specific Identity 255 Association as an IPoE client MAY have multiple IAs with different 256 health check parameters. 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | option-code | option-len | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | limit |R| reserved | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | interval | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | retry-interval | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 1: DHCPv6 IPoE Check Option Format 272 The description of the fields is as follows: 274 option-code: OPTION_IPOE_HEALTH (TBA1). 275 option-len: 12. 276 limit: Consecutive failed checks, before an action is taken. 277 R: Release flag. Instructs the client to send a DHCP RELEASE 278 when a failure is detected, and to skip the renew step. 279 interval: Indicates how often a health check should be sent when 280 no failure is encountered. Expressed in units of seconds. 281 retry-interval: Indicates how often a health check should be sent 282 after a previous failure. Expressed in units of seconds. 284 4.2. DHCPv4 286 The DHCPv4 client can retrieve IPoE Health Check information by 287 including OPTION_IPOE_HEALTH in a Parameter Request List option 288 [RFC2132]. 290 Figure 2 shows the DHCPv4 IPoE Health Check option. 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | option-code | option-len | limit |R| | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | interval | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | retry-interval | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Figure 2: DHCPv4 IPoE Health Check Option Format 304 The description of the fields is as follows: 306 option-code: OPTION_IPOE_HEALTH (TBA2). 307 option-len: 10. 308 limit: Consecutive failed checks, before an action is taken. 309 R: Release flag. Instructs the client to send a DHCP RELEASE 310 when a failure is detected, and to skip the renew step. 311 interval: Indicates how often a health check should be sent when 312 no failure is encountered. Expressed in units of seconds. 313 retry-interval: Indicates how often a health check should be sent 314 after a previous failure. Expressed in units of seconds. 316 5. Recovery Behaviour 318 IPoE Health Check defines the behaviour that an IPoE Client should 319 take once the timeout threshold has been reached. This behaviour 320 makes use of existing procedures outlined in [RFC2131], Section 4.4.5 321 for DHCPv4, and [RFC3315]-bis, Sections 18.2.4, 18.2.5 for DHCPv6. 323 When triggering a DISCOVER or SOLICIT, an IPoE client may also choose 324 to use Rapid Commit [RFC4039], [RFC3315], Section 22.14 to help 325 expedite the recovery process. 327 After Limit (Section 3.1) consecutive check failures, T1 and T2 MUST 328 both be set to zero. 330 If the Release Flag (Section 3.1) is unset, the IPoE client SHOULD 331 immediately attempt to renew the current lease from the original 332 server. If connectivity to the original DHCP server has recovered, 333 and the server can satisfy the request, the lease may be renewed and 334 timers updated. 335 If the renew is unsuccessful, the IPoE client MUST move to the 336 discovery or solicit phase. 338 If the Release Flag is unset, the IPoE client MUST keep the address 339 or prefix in the preferred state until the preferred lifetime 340 expires, and MUST keep the address or prefix until the valid lifetime 341 expires. 343 If the Release Flag is set the IPoE Client MUST NOT send a DHCP 344 RENEW, it MUST send a RELEASE as per [RFC2131], Section 3.1 for 345 DHCPv4 and [RFC3315]-bis, Section 18.2.7. 347 If the IPoE client is already in the renew or rebind state when this 348 behaviour is triggered, the client MUST cease renew or rebind 349 attempts and wait for any outstanding messages to time out before 350 sending a RELEASE. 351 If an outstanding renew or rebind attempt is successful, the IPoE 352 client MUST update T1, T2 and lease lifetimes appropriately, and MUST 353 NOT continue with this behaviour. 355 Once the RELEASE process has completed, the IPoE Client should move 356 to the discovery or solicit phase. 358 The IPoE client MUST include the current address or prefix in the IA 359 Address or IA_PD options within the DHCPv6 SOLICIT, or in the 360 Requested IP Address Option of a DHCPv4 DISCOVER [RFC2131], 361 Section 4.4.2. 363 The DHCPv6 SOLICIT DUID and IAID values MUST be the same as used in 364 the current lease. 366 If the DHCP server assigns the current address or prefix, the IPoE 367 client MUST update the current lease timers, and any differing 368 parameters. 370 If the DHCP server assigns an alternate address or prefix, the IPoE 371 client MUST deprecate the current lease and follow the actions 372 outlined in requirement L-13 [RFC7084], Section 4.3 374 5.1. LAN Considerations 376 If all DHCPv6 leases have expired, either naturally or proactively 377 with IPoE health checks, an IPoE client acting as a router, SHOULD 378 withdraw itself as a default router on the LAN, following requirement 379 G-5 of [RFC7084], Section 4.1. 381 6. Multihomed Clients 383 An IPoE client may have multiple leases from the same, or different 384 DHCP servers. These leases may have different IPoE health check 385 parameters, and health checks MUST be treated distinctly, tracking 386 the particular lease that they belong to. 388 Local network administrators may choose to override DHCP-signalled 389 parameters in order to facilitate appropriate IPoE Health Check 390 operation in a multihomed environment. 392 7. Security Considerations 394 IPoE Health Check frequency would typically be controlled by the 395 network using DHCP options, but overly aggressive, statically 396 configured IPoE Health Checks, could have an adverse impact. For 397 example, this may induce an overload on the IP access nodes. 398 However, BFD Echo and the IPoE Health Check probe defined in this 399 document, both use an IP packet destined for the IPoE client, the 400 remote peer forwards the packet back to the IPoE client without any 401 local processing. 403 The inclusion of the current lease address or prefix when sending a 404 DISCOVER or SOLICIT, introduces a privacy risk, possibly leaking 405 lease information if the IPoE client has been moved to a different 406 network, e.g., from one fixed line provider to another. 408 8. IANA Considerations 410 IANA is requested to assign a new DHCPv6 Option Code in the registry 411 maintained in http://www.iana.org/assignments/dhcpv6-parameters [1]: 413 Option Name Value 414 -------------------- ----- 415 OPTION_IPOE_HEALTH TBA1 417 Also, IANA is requested to assign the following new DHCPv4 Option 418 Code in the registry maintained in http://www.iana.org/assignments/ 419 bootp-dhcp-parameters [2]: 421 Option Name Tag Data Length Meaning 422 -------------------- --- ----------- -------------------------------- 423 OPTION_IPOE_HEALTH TBA2 14 Provides a set of IPoE check 424 configuration information. 426 9. Acknowledgements 428 The authors would like thank Ian Farrer, Dusan Mudric, Mohamed 429 Boucadair, Jean-Yves Cloarec, Bernie Volz, Barbara Stark, Dave 430 Freedman, and Job Snijders for their review and comments on this and 431 previous versions of this document. 433 10. Appendix A. Changes from -00 435 This section should be removed by the RFC Editor. 437 o Added reference to TR-146. 439 o Added BFD Echo section, and wording to prefer it as the health 440 check mechanism over ARP/ND, if available. 442 11. Appendix B. Changes from -01 444 This section should be removed by the RFC Editor. 446 o Emphasised preference for use of BFD echo as the health check 447 mechanism. 449 o Removed lifetime expiration from Behaviour 2 and clarified usage. 451 o Updated Behaviour 3 with instructions for whilst mid-renew/rebind. 453 o Reworded multihoming section. 455 o Added Acknowledgements. 457 12. Appendix C. Changes from -02 459 This section should be removed by the RFC Editor. 461 o Added DHCP option flag to force ARP/ND for health checks. 463 o Populated IANA Considerations. 465 o Added Retry Interval distinct timer for between failed checks. 467 o Added default parameter values. 469 13. Appendix D. Changes from -03 471 This section should be removed by the RFC Editor. 473 o Reduced default Limit value. 475 o Formatting and minor cosmetic changes. 477 14. Appendix E. Changes from -04 479 This section should be removed by the RFC Editor. 481 This revision is a major rewrite. Changes include: 483 o Consolidated the multiple behaviours down to one. 485 o Added a Release flag instead of a distinct behaviour. 487 o Added custom IPoE Health Check Probe definition. 489 o Removed ARP/ND and Passive checks. 491 o Removed alternative target address parameter. 493 o Removed IANA registry request for Behaviour values. 495 15. References 497 15.1. Normative References 499 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 500 Converting Network Protocol Addresses to 48.bit Ethernet 501 Address for Transmission on Ethernet Hardware", STD 37, 502 RFC 826, DOI 10.17487/RFC0826, November 1982, 503 . 505 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 506 RFC 2131, DOI 10.17487/RFC2131, March 1997, 507 . 509 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 510 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 511 . 513 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 514 C., and M. Carney, "Dynamic Host Configuration Protocol 515 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 516 2003, . 518 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 519 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 520 DOI 10.17487/RFC4861, September 2007, 521 . 523 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 524 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 525 . 527 15.2. Informative References 529 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 530 STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 531 . 533 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 534 Requirement Levels", BCP 14, RFC 2119, 535 DOI 10.17487/RFC2119, March 1997, 536 . 538 [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP 539 reconfigure extension", RFC 3203, DOI 10.17487/RFC3203, 540 December 2001, . 542 [RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for 543 the Dynamic Host Configuration Protocol version 4 544 (DHCPv4)", RFC 4039, DOI 10.17487/RFC4039, March 2005, 545 . 547 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 548 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 549 March 2011, . 551 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 552 Requirements for IPv6 Customer Edge Routers", RFC 7084, 553 DOI 10.17487/RFC7084, November 2013, 554 . 556 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 557 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 558 May 2017, . 560 [TR-124] "Functional Requirements for Broadband Residential Gateway 561 Devices", 2006, . 564 [TR-146] "Subscriber Sessions", 2013, . 567 15.3. URIs 569 [1] http://www.iana.org/assignments/dhcpv6-parameters 571 [2] http://www.iana.org/assignments/bootp-dhcp-parameters 573 Authors' Addresses 575 Richard Patterson 576 Sky UK 578 Email: richard.patterson@sky.uk 580 Mikael Abrahamsson 581 T-Systems 583 Email: mikael.abrahamsson@t-systems.se