| < draft-ietf-dhc-dhcpv6-pd-relay-requirements-04.txt | draft-ietf-dhc-dhcpv6-pd-relay-requirements-05.txt > | |||
|---|---|---|---|---|
| DHC Work Group I. Farrer | DHC Work Group I. Farrer | |||
| Internet-Draft Deutsche Telekom AG | Internet-Draft Deutsche Telekom AG | |||
| Intended status: Standards Track Naveen. Kottapalli | Intended status: Standards Track N. Kottapalli | |||
| Expires: June 3, 2021 Benu Networks | Expires: 8 July 2021 Benu Networks | |||
| M. Hunek | M. Hunek | |||
| Technical University of Liberec | Technical University of Liberec | |||
| R. Patterson | R.P. Patterson | |||
| Sky UK Ltd | Sky UK Ltd | |||
| November 30, 2020 | January 2021 | |||
| DHCPv6 Prefix Delegating Relay Requirements | DHCPv6 Prefix Delegating Relay Requirements | |||
| draft-ietf-dhc-dhcpv6-pd-relay-requirements-04 | draft-ietf-dhc-dhcpv6-pd-relay-requirements-05 | |||
| Abstract | Abstract | |||
| This memo describes operational problems that are known to occur when | This document describes operational problems that are known to occur | |||
| using DHCPv6 relays with Prefix Delegation. These problems can | when using DHCPv6 relays with Prefix Delegation. These problems can | |||
| prevent successful delegation and result in routing failures. To | prevent successful delegation and result in routing failures. To | |||
| address these problems, this memo provides necessary functional | address these problems, this document provides necessary functional | |||
| requirements for operating DHCPv6 relays with Prefix Delegation. | requirements for operating DHCPv6 relays with Prefix Delegation. | |||
| It is recommended that any network operator that is using DHCPv6 | It is recommended that any network operator that is using DHCPv6 | |||
| prefix delegation with relays should ensure that these requirements | prefix delegation with relays should ensure that these requirements | |||
| are followed on their networks. | are followed on their networks. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| skipping to change at page 1, line 43 ¶ | skipping to change at page 1, line 43 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on June 3, 2021. | This Internet-Draft will expire on 5 July 2021. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2021 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | license-info) in effect on the date of publication of this document. | |||
| publication of this document. Please review these documents | Please review these documents carefully, as they describe your rights | |||
| carefully, as they describe your rights and restrictions with respect | and restrictions with respect to this document. Code Components | |||
| to this document. Code Components extracted from this document must | extracted from this document must include Simplified BSD License text | |||
| include Simplified BSD License text as described in Section 4.e of | as described in Section 4.e of the Trust Legal Provisions and are | |||
| the Trust Legal Provisions and are provided without warranty as | provided without warranty as described in the Simplified BSD License. | |||
| described in the Simplified BSD License. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 | 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 | |||
| 3. Problems Observed with Existing Delegating Relay | 3. Problems Observed with Existing Delegating Relay | |||
| Implementations . . . . . . . . . . . . . . . . . . . . . . . 5 | Implementations . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 3.1. DHCP Messages not being Forwarded by the Delegating | 3.1. DHCP Messages not being Forwarded by the Delegating | |||
| Relay . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | Relay . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 3.2. Delegating Relay Loss of State on Reboot . . . . . . . . 5 | 3.2. Delegating Relay Loss of State on Reboot . . . . . . . . 6 | |||
| 3.3. Multiple Delegated Prefixes for a Single Client . . . . . 6 | 3.3. Multiple Delegated Prefixes for a Single Client . . . . . 6 | |||
| 3.4. Dropping Messages from Devices with Duplicate MAC | 3.4. Dropping Messages from Devices with Duplicate MAC addresses | |||
| addresses and DUIDs . . . . . . . . . . . . . . . . . . . 6 | and DUIDs . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 3.5. Forwarding Loops between Client and Relay . . . . . . . . 6 | 3.5. Forwarding Loops between Client and Relay . . . . . . . . 7 | |||
| 4. Requirements for Delegating Relays . . . . . . . . . . . . . 7 | 4. Requirements for Delegating Relays . . . . . . . . . . . . . 7 | |||
| 4.1. General Requirements . . . . . . . . . . . . . . . . . . 7 | 4.1. General Requirements . . . . . . . . . . . . . . . . . . 7 | |||
| 4.2. Routing Requirements . . . . . . . . . . . . . . . . . . 8 | 4.2. Routing Requirements . . . . . . . . . . . . . . . . . . 8 | |||
| 4.3. Service Continuity Requirements . . . . . . . . . . . . . 9 | 4.3. Service Continuity Requirements . . . . . . . . . . . . . 9 | |||
| 4.4. Operational Requirements . . . . . . . . . . . . . . . . 9 | 4.4. Operational Requirements . . . . . . . . . . . . . . . . 10 | |||
| 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 | |||
| 8.2. Informative References . . . . . . . . . . . . . . . . . 11 | 8.2. Informative References . . . . . . . . . . . . . . . . . 12 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 1. Introduction | 1. Introduction | |||
| For Internet service providers that offer native IPv6 access with | For internet service providers that offer native IPv6 access with | |||
| prefix delegation to their customers, a common deployment | prefix delegation to their customers, a common deployment | |||
| architecture is to have a DHCPv6 relay agent function located in the | architecture is to have a DHCPv6 relay agent function located in the | |||
| ISP's Layer-3 customer edge device and separate, centralized DHCPv6 | ISP's Layer-3 customer edge device and separate, centralized DHCPv6 | |||
| server infrastructure. [RFC8415] describes the functionality of a | server infrastructure. [RFC8415] describes the functionality of a | |||
| DHCPv6 relay and Section 19.1.3 mentions this deployment scenario, | DHCPv6 relay and Section 19.1.3 mentions this deployment scenario, | |||
| but does not provide detail for all of the functional requirements | but does not provide details for all of the functional requirements | |||
| that the relay needs to fulfill to operate deterministically in this | that the relay needs to fulfill to operate deterministically in this | |||
| deployment scenario. | deployment scenario. | |||
| A DHCPv6 relay agent for prefix delegation is a function commonly | A DHCPv6 relay agent for prefix delegation is a function commonly | |||
| implemented in routing devices, but implementations vary in their | implemented in routing devices, but implementations vary in their | |||
| functionality and client/server inter-working. This can result in | functionality and client/server inter-working. This can result in | |||
| operational problems such as messages not being forwarded by the | operational problems such as messages not being forwarded by the | |||
| relay or un-reachability of the delegated prefixes. This document | relay or un-reachability of the delegated prefixes. This document | |||
| provides a set of requirements for devices implementing a relay | provides a set of requirements for devices implementing a relay | |||
| function for use with prefix delegation. | function for use with prefix delegation. | |||
| skipping to change at page 3, line 29 ¶ | skipping to change at page 3, line 39 ¶ | |||
| Multi-hop DHCPv6 relaying is not affected. The requirements in this | Multi-hop DHCPv6 relaying is not affected. The requirements in this | |||
| document are solely applicable to the DHCP relay agent co-located | document are solely applicable to the DHCP relay agent co-located | |||
| with the first-hop router that the DHCPv6 client requesting the | with the first-hop router that the DHCPv6 client requesting the | |||
| prefix is connected to, so no changes to any subsequent relays in the | prefix is connected to, so no changes to any subsequent relays in the | |||
| path are needed. | path are needed. | |||
| 2. Terminology | 2. Terminology | |||
| 2.1. General | 2.1. General | |||
| This document uses the terminology defined in [RFC8415], however when | This document uses the terminology defined in [RFC8415], however, | |||
| defining the functional elements for prefix delegation [RFC8415], | when defining the functional elements for prefix delegation | |||
| Section 4.2 defines the term 'delegating router' as: | [RFC8415], Section 4.2 defines the term 'delegating router' as: | |||
| "The router that acts as a DHCP server and responds to requests | "The router that acts as a DHCP server and responds to requests | |||
| for delegated prefixes." | for delegated prefixes." | |||
| This document is concerned with deployment scenarios in which the | This document is concerned with deployment scenarios in which the | |||
| DHCPv6 relay and DHCPv6 server functions are separated, so the term | DHCPv6 relay and DHCPv6 server functions are separated, so the term | |||
| 'delegating router' is not used. Instead, a new term is introduced | 'delegating router' is not used. Instead, a new term is introduced | |||
| to describe the relaying function: | to describe the relaying function: | |||
| Delegating relay A delegating relay acts as an intermediate device, | Delegating relay A delegating relay acts as an intermediate device, | |||
| forwarding DHCPv6 messages containing IA_PD/IAPREFIX | forwarding DHCPv6 messages containing IA_PD and | |||
| options between the client and server. The | IAPREFIX options between the client and server. The | |||
| delegating relay does not implement a DHCPv6 server | delegating relay does not implement a DHCPv6 server | |||
| function. The delegating relay is also responsible | function. The delegating relay is also responsible | |||
| for routing traffic for the delegated prefixes. | for routing traffic for the delegated prefixes. | |||
| Where the term 'relay' is used on its own within this document, it | Where the term 'relay' is used on its own within this document, it | |||
| should be understood to be a delegating relay, unless specifically | should be understood to be a delegating relay, unless specifically | |||
| stated otherwise. | stated otherwise. | |||
| In CableLabs DOCSIS environments, the Cable Modem Termination System | In CableLabs DOCSIS environments, the Cable Modem Termination System | |||
| (CMTS) would be considered a delegating relay with respect to | (CMTS) would be considered a delegating relay with respect to | |||
| skipping to change at page 6, line 26 ¶ | skipping to change at page 6, line 50 ¶ | |||
| In some delegating relay implementations, only a single delegated | In some delegating relay implementations, only a single delegated | |||
| prefix per-DUID is supported. In those cases only one IPv6 route for | prefix per-DUID is supported. In those cases only one IPv6 route for | |||
| one of the delegated prefixes is installed; meaning that other | one of the delegated prefixes is installed; meaning that other | |||
| prefixes delegated to a client are unreachable. | prefixes delegated to a client are unreachable. | |||
| 3.4. Dropping Messages from Devices with Duplicate MAC addresses and | 3.4. Dropping Messages from Devices with Duplicate MAC addresses and | |||
| DUIDs | DUIDs | |||
| It is an operational reality that client devices with duplicate MAC | It is an operational reality that client devices with duplicate MAC | |||
| addresses and/or DUIDs exist and have been deployed. In this | addresses and/or DUIDs exist and have been deployed. In some | |||
| situation, the operational costs of locating and swapping out such | networks, the operational costs of locating and swapping out such | |||
| devices are prohibitive. | devices are prohibitive. | |||
| Delegating relays have been observed to restrict forwarding client | Delegating relays have been observed to restrict forwarding client | |||
| messages originating from one client DUID to a single interface. In | messages originating from one client DUID to a single interface. In | |||
| this case if the same client DUID appears from a second client on | this case if the same client DUID appears from a second client on | |||
| another interface while there is already an active lease, messages | another interface while there is already an active lease, messages | |||
| originating from the second client are dropped causing the second | originating from the second client are dropped causing the second | |||
| client to be unable to obtain a prefix delegation. | client to be unable to obtain a prefix delegation. | |||
| It should be noted that in some access networks, the MAC address and/ | It should be noted that in some access networks, the MAC address and/ | |||
| or DUID are used as part of device identification and authentication. | or DUID are used as part of device identification and authentication. | |||
| In such networks, enforcing MAC address/DUID uniqueness is a | In such networks, enforcing MAC address/DUID uniqueness is a | |||
| necessary function and not considered a problem. | necessary function and not considered a problem. | |||
| 3.5. Forwarding Loops between Client and Relay | 3.5. Forwarding Loops between Client and Relay | |||
| If the client loses information about a prefix that it is delegated | If the client loses information about an active prefix lease it has | |||
| while the lease entry and associated route is still active in the | been delegated while the lease entry and associated route is still | |||
| delegating relay, then the relay will forward traffic to the client | active in the delegating relay, then the relay will forward traffic | |||
| which the client will return to the relay (which is the client's | to the client which the client will return to the relay (which is the | |||
| default gateway (learned via an RA)). The loop will continue until | client's default gateway (learned via an RA)). The loop will | |||
| either the client is successfully re-provisioned via DHCP, or the | continue until either the client is successfully re-provisioned via | |||
| lease ages out in the relay. | DHCP, or the lease ages out in the relay. | |||
| 4. Requirements for Delegating Relays | 4. Requirements for Delegating Relays | |||
| To resolve the problems described in Section 3 and pre-empt other | To resolve the problems described in Section 3 and pre-empt other | |||
| undesirable behavior, the following section of the document describes | undesirable behavior, the following section of the document describes | |||
| a set of functional requirements for the delegating relay. | a set of functional requirements for the delegating relay. | |||
| In addition, relay implementers are reminded that [RFC8415] makes it | In addition, relay implementers are reminded that [RFC8415] makes it | |||
| clear that relays MUST forward packets that either contain message | clear that relays MUST forward packets that either contain message | |||
| codes (Section 19 of [RFC8415]) it may not understand, or contain | codes (Section 19 of [RFC8415]) it may not understand, or contain | |||
| skipping to change at page 8, line 6 ¶ | skipping to change at page 8, line 29 ¶ | |||
| G-6: The relay MUST implement a mechanism to limit the maximum | G-6: The relay MUST implement a mechanism to limit the maximum | |||
| number of active prefix delegations on a single port for all | number of active prefix delegations on a single port for all | |||
| client identifiers and IA_PDs. This value MUST be | client identifiers and IA_PDs. This value MUST be | |||
| configurable. | configurable. | |||
| G-7: It is RECOMMENDED that delegating relays support at least 8 | G-7: It is RECOMMENDED that delegating relays support at least 8 | |||
| active delegated leases per client device and use this as the | active delegated leases per client device and use this as the | |||
| default limit. | default limit. | |||
| G-8: The delegating relay MUST update the lease lifetimes based on | G-8: The delegating relay MUST update the lease lifetimes based on | |||
| the Client Reply messages it forwards to the client and only | the client's reply messages it forwards to the client and | |||
| expire the delegated prefixes when the valid lifetime has | only expire the delegated prefixes when the valid lifetime | |||
| elapsed. | has elapsed. | |||
| G-9: On receipt of a Release message from the client, the | G-9: On receipt of a Release message from the client, the | |||
| delegating relay MUST expire the active leases for each of | delegating relay MUST expire the active leases for each of | |||
| the IA_PDs in the message. | the IA_PDs in the message. | |||
| 4.2. Routing Requirements | 4.2. Routing Requirements | |||
| R-1: The relay MUST maintain a local routing table that is | R-1: The relay MUST maintain a local routing table that is | |||
| dynamically updated with leases and the associated next-hops | dynamically updated with leases and the associated next-hops | |||
| as they are delegated to clients. When a delegated prefix is | as they are delegated to clients. When a delegated prefix is | |||
| skipping to change at page 8, line 35 ¶ | skipping to change at page 9, line 13 ¶ | |||
| R-3: The relay MUST provide a mechanism to dynamically update | R-3: The relay MUST provide a mechanism to dynamically update | |||
| ingress filters permitting ingress traffic sourced from | ingress filters permitting ingress traffic sourced from | |||
| client delegated leases and blocking packets from invalid | client delegated leases and blocking packets from invalid | |||
| source prefixes. This is to implement anti-spoofing as | source prefixes. This is to implement anti-spoofing as | |||
| described in [BCP38]. The delegating relay's ingress filter | described in [BCP38]. The delegating relay's ingress filter | |||
| entry MUST use the same prefix length for the delegated | entry MUST use the same prefix length for the delegated | |||
| prefix as given in the IA_PD. | prefix as given in the IA_PD. | |||
| R-4: The relay MAY provide a mechanism to dynamically advertise | R-4: The relay MAY provide a mechanism to dynamically advertise | |||
| delegated leases into a routing protocol as they are learned. | delegated leases into a routing protocol as they are learned. | |||
| When a delegated lease is released or expires, the delegated | If such a mechanism is implemented, when a delegated lease is | |||
| route MUST be withdrawn from the routing protocol. The | released or expires, the delegated route MUST be withdrawn | |||
| mechanism by which the routes are inserted and deleted is out | from the routing protocol. The mechanism by which the routes | |||
| of the scope of this document. | are inserted and deleted is out of the scope of this | |||
| document. | ||||
| R-5: To prevent routing loops, the relay SHOULD implement a | R-5: To prevent routing loops, the relay SHOULD implement a | |||
| configurable policy to drop potential looping packets | configurable policy to drop potential looping packets | |||
| received on any DHCP-PD client facing interfaces. | received on any DHCP-PD client facing interfaces. | |||
| The policy SHOULD be configurable on a per-client or per- | The policy SHOULD be configurable on a per-client or per- | |||
| destination basis. | destination basis. | |||
| Looping packets are those with a destination address in a | Looping packets are those with a destination address in a | |||
| prefix delegated to a client connected to that interface, as | prefix delegated to a client connected to that interface, as | |||
| skipping to change at page 10, line 19 ¶ | skipping to change at page 10, line 47 ¶ | |||
| The authors of this document would like to thank Bernie Volz, Ted | The authors of this document would like to thank Bernie Volz, Ted | |||
| Lemon, and Michael Richardson for their valuable comments. | Lemon, and Michael Richardson for their valuable comments. | |||
| 6. IANA Considerations | 6. IANA Considerations | |||
| This memo includes no request to IANA. | This memo includes no request to IANA. | |||
| 7. Security Considerations | 7. Security Considerations | |||
| This document does not add any new security considerations beyond | This document does not add any new security considerations beyond | |||
| those mentioned in Section 22 of [RFC8213]. | those mentioned in Section 4 of [RFC8213] and Section 22 of | |||
| [RFC8415]. | ||||
| If the delegating relay implements [BCP38] filtering, then the | If the delegating relay implements [BCP38] filtering, then the | |||
| filtering rules will need to be dynamically updated as delegated | filtering rules will need to be dynamically updated as delegated | |||
| prefixes are leased. | prefixes are leased. | |||
| [RFC8213] describes a method for securing traffic between the relay | [RFC8213] describes a method for securing traffic between the relay | |||
| agent and server by sending DHCP messages over an IPsec tunnel. In | agent and server by sending DHCP messages over an IPsec tunnel. It | |||
| this case the IPsec tunnel is functionally the server-facing | is RECOMMENDED that this is implemented by the delegating relay. | |||
| interface and DHCPv6 message snooping can be carried out as | ||||
| described. It is RECOMMENDED that this is implemented by the | Failure to implement requirement G-6 may have specific security | |||
| delegating relay. | implications, such as a resource depletion attack on the relay. | |||
| The operational requirements in Section Section 4.4 may introduce | ||||
| additional security considerations. It is RECOMMENDED that the | ||||
| operational security practices described in [RFC4778] are | ||||
| implemented. | ||||
| 8. References | 8. References | |||
| 8.1. Normative References | 8.1. Normative References | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet | ||||
| Control Message Protocol (ICMPv6) for the Internet | ||||
| Protocol Version 6 (IPv6) Specification", STD 89, | ||||
| RFC 4443, DOI 10.17487/RFC4443, March 2006, | ||||
| <https://www.rfc-editor.org/info/rfc4443>. | ||||
| [RFC4778] Kaeo, M., "Operational Security Current Practices in | ||||
| Internet Service Provider Environments", RFC 4778, | ||||
| DOI 10.17487/RFC4778, January 2007, | ||||
| <https://www.rfc-editor.org/info/rfc4778>. | ||||
| [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, | [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, | |||
| DOI 10.17487/RFC5460, February 2009, | DOI 10.17487/RFC5460, February 2009, | |||
| <https://www.rfc-editor.org/info/rfc5460>. | <https://www.rfc-editor.org/info/rfc5460>. | |||
| [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 | [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 | |||
| Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, | Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, | |||
| October 2015, <https://www.rfc-editor.org/info/rfc7653>. | October 2015, <https://www.rfc-editor.org/info/rfc7653>. | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| [RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged | ||||
| between Servers and Relay Agents", RFC 8213, | ||||
| DOI 10.17487/RFC8213, August 2017, | ||||
| <https://www.rfc-editor.org/info/rfc8213>. | ||||
| [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., | [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., | |||
| Richardson, M., Jiang, S., Lemon, T., and T. Winters, | Richardson, M., Jiang, S., Lemon, T., and T. Winters, | |||
| "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", | "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", | |||
| RFC 8415, DOI 10.17487/RFC8415, November 2018, | RFC 8415, DOI 10.17487/RFC8415, November 2018, | |||
| <https://www.rfc-editor.org/info/rfc8415>. | <https://www.rfc-editor.org/info/rfc8415>. | |||
| 8.2. Informative References | 8.2. Informative References | |||
| [BCP38] IETF, "Network Ingress Filtering: Defeating Denial of | [BCP38] IETF, "Network Ingress Filtering: Defeating Denial of | |||
| Service Attacks which employ IP Source Address Spoofing | Service Attacks which employ IP Source Address Spoofing | |||
| https://tools.ietf.org/html/bcp38", RFC 2827, BCP 38. | https://tools.ietf.org/html/bcp38", RFC 2827, BCP 38, | |||
| <https://www.rfc-editor.org/rfc/rfc2827>. | ||||
| [DOCSIS_3.1] | [DOCSIS_3.1] | |||
| CableLabs, "MAC and Upper Layer Protocols Interface | CableLabs, "MAC and Upper Layer Protocols Interface | |||
| Specification", DOCSIS 3.1, January, 2017", | Specification", DOCSIS 3.1, January, 2017", | |||
| <https://apps.cablelabs.com/specification/CM-SP-MULPIv3.>. | <https://apps.cablelabs.com/specification/CM-SP-MULPIv3.>. | |||
| [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet | ||||
| Control Message Protocol (ICMPv6) for the Internet | ||||
| Protocol Version 6 (IPv6) Specification", STD 89, | ||||
| RFC 4443, DOI 10.17487/RFC4443, March 2006, | ||||
| <https://www.rfc-editor.org/info/rfc4443>. | ||||
| [RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged | ||||
| between Servers and Relay Agents", RFC 8213, | ||||
| DOI 10.17487/RFC8213, August 2017, | ||||
| <https://www.rfc-editor.org/info/rfc8213>. | ||||
| [TR-092] Broadband Forum, "Broadband Remote Access Server (BRAS) | [TR-092] Broadband Forum, "Broadband Remote Access Server (BRAS) | |||
| Requirements Document, August, 2004", | Requirements Document, August, 2004", | |||
| <https://www.broadband-forum.org/download/TR-092.pdf>. | <https://www.broadband-forum.org/download/TR-092.pdf>. | |||
| Authors' Addresses | Authors' Addresses | |||
| Ian Farrer | Ian Farrer | |||
| Deutsche Telekom AG | Deutsche Telekom AG | |||
| Landgrabenweg 151 | Landgrabenweg 151 | |||
| Bonn, NRW 53227 | 53227 Bonn | |||
| DE | Germany | |||
| Email: ian.farrer@telekom.de | Email: ian.farrer@telekom.de | |||
| Naveen Kottapalli | Naveen Kottapalli | |||
| Benu Networks | Benu Networks | |||
| 300 Concord Road | 154 Middlesex Turnpike | |||
| Billerica, MA 01821 | Burlington, MA 01803 | |||
| US | United States of America | |||
| Email: naveen.sarma@gmail.com | Email: nkottapalli@benunets.com | |||
| Martin Hunek | Martin Hunek | |||
| Technical University of Liberec | Technical University of Liberec | |||
| Studentska 1402/2 | Studentska 1402/2 | |||
| Liberec, L 46017 | 46017 Liberec | |||
| CZ | Czechia | |||
| Email: martin.hunek@tul.cz | Email: martin.hunek@tul.cz | |||
| Richard Patterson | Richard Patterson | |||
| Sky UK Ltd | Sky UK Ltd | |||
| 1 Brick Lane | 1 Brick Lane | |||
| London E1 6PU | London | |||
| UK | E1 6PU | |||
| United Kingdom | ||||
| Email: richard.patterson@sky.uk | Email: richard.patterson@sky.uk | |||
| End of changes. 35 change blocks. | ||||
| 83 lines changed or deleted | 96 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||