Internet-Draft IPv6 CE Routers LAN Prefix Delegation July 2023
Winters Expires 11 January 2024 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-winters-v6ops-cpe-lan-pd-03
Updates:
7084 (if approved)
Published:
Intended Status:
Informational
Expires:
Author:
T. Winters
QA Cafe

IPv6 CE Routers LAN Prefix Delegation

Abstract

This document defines requirements for IPv6 CE Routers to support DHCPv6 Prefix Delegation for redistributing any unused prefix(es) that were delegated to the IPv6 CE Router. This document updates RFC 7084.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 11 January 2024.

Table of Contents

1. Introduction

This document defines DHCPv6 Prefix Delegation in IPv6 CE Routers ([RFC7084]) in order to properly utilize the IPv6 prefixes assigned by service providers. Many ISP will assign a prefix larger then /64 to the CE Router, as recommended in [RFC6177]. If an IPv6 CE Router doesn't support IA_PD on the LAN it will not be able to assign any prefixes beyond itself, limiting the usefulness of assigning prefixes larger than /64. Supporting IA_PD on the LAN interfaces will allow for those unused prefixes to be distributed into a network.

Two models, hierachical prefix and flat, have been proposed in the past for prefix sub-delegation. Hierachical prefix delegation requires more complexity for the IPv6 CE Router. When no routing protocol is present to discover the network topology it's possible to have unbalanced prefix delegation tree which leads to running out of prefixes. This document uses the flat model which allows for DHCPv6 clients to ask for multiple prefixes of size 64 to avoid the complexity and favor a simplier solution.

This document does not cover dealing with multi-provisioned networks with more than one provider. Due to complexity of a solution that will requires routing, provisioning, and policy this is out of scope of this document.

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This document also makes use of internal conceptual variables to describe protocol behavior and external variables that an implementation must allow system administrators to change. The specific variable names, how their values change, and how their settings influence protocol behavior are provided to demonstrate protocol behavior. An implementation is not required to have them in the exact form described here, as long as its external behavior is consistent with that described in this document.

3. Terminology

The following terminology is defined for this document.

4. Architecture

                     +-----------+
                     |  Service  |
                     |  Provider |
                     |   Router  |
                     +-----+-----+
                           |
                           |
                           |  Customer
                           |  Internet Connection
                           |
                     +-----v-----+
                     |   IPv6    |
                     |    CE     |
                     |  Router   |
                     +-----+-----+
                           |
                    +----+-+-------+
                    |              |
                    |              |
                +---+----+   +-----+------+
                |  IPv6  |   |            |
                |  Host  |   |  Router    |
                |        |   |            |
                +--------+   +------------+

5. Requirements

The IPv6 CE Router distributes configuration information obtained during WAN interface provisioning to IPv6 hosts and routers. Previously, a router based on [RFC7084] would only provide IPv6 hosts with individual addresses; this update allows for addressing and routing of IPv6 prefixes to both hosts and routers.

LAN Prefix Delegation (PD) Requirements

LPD-1: The IPv6 CE Router MUST support a DHCPv6 server capable of IPv6 prefix assignment according to [RFC8415] (Identity Association for Prefix Delegation (IA_PD) option).

LPD-2: The IPv6 CE Router MUST assign a prefix from the delegated prefix to each of its LAN links. If not enough addresses are available the IPv6 CE Router SHOULD log a system management error.

LPD-3: The prefix assigned to a link MUST NOT change in the absence of topology or configuration changes.

LPD-4: After LAN link prefix assignment the IPv6 CE Router MUST make the remaining IPv6 prefixes available to other routers via Prefix Delegation.

LPD-5: Available prefixes must be provisioned IA_PD IA prefixes MUST have a prefix-length of 64.

LPD-6: The IPv6 CE Router MUST install a route to the assigned IA_PD with a next-hop of the IPv6 node that was assigned the prefix. The IPv6 CE Router MUST remove the route when IA_PD lease expires.

LPD-7: By default, the IPv6 CE Router firewall MUST allow forwarding of packets with an outer IPv6 header containing a source address belonging to Delegated Prefixes, along with reciprocal packets from the same flow, following the recommendations of [RFC6092]

LPD-8: If an IPv6 CE Router receives a single IA_PD IA Prefix with a prefix-length of 64. IPv6 prefixes of size 64 it MUST act as delegating relay according to [RFC8987] specifically requirements G-2 to G-7, G-9, and S-2. DHCPv6 messages without IA-PD option MUST NOT be relayed.

LPD-9: A CE Router MUST only be a delegating relay with DHCPv6 messages with IA_PD options present.

LPD-10: A CE Router assigning prefixes MUST NOT assign IA_NA in the same DHCPv6 exchange.

6. Security Considerations

This document does not add any new security considerations beyond those mentioned in Section 4 of [RFC8213] and Section 22 of [RFC8415].

7. IANA Considerations

This document makes no request of IANA.

8. Acknowledgements

Thanks to the following people for their guidance and feedback: Marion Dillon, Erik Auerswald, Esko Dijk, Tim Carlin, Richard Patterson, Ted Lemon, Michael Richardson, Martin Hunek.

9. References

9.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC6092]
Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, , <https://www.rfc-editor.org/info/rfc6092>.
[RFC6177]
Narten, T., Huston, G., and L. Roberts, "IPv6 Address Assignment to End Sites", BCP 157, RFC 6177, DOI 10.17487/RFC6177, , <https://www.rfc-editor.org/info/rfc6177>.
[RFC7084]
Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, , <https://www.rfc-editor.org/info/rfc7084>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <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, , <https://www.rfc-editor.org/info/rfc8213>.
[RFC8415]
Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, , <https://www.rfc-editor.org/info/rfc8415>.
[RFC8987]
Farrer, I., Kottapalli, N., Hunek, M., and R. Patterson, "DHCPv6 Prefix Delegating Relay Requirements", RFC 8987, DOI 10.17487/RFC8987, , <https://www.rfc-editor.org/info/rfc8987>.

9.2. Informative References

[RFC7695]
Pfister, P., Paterson, B., and J. Arkko, "Distributed Prefix Assignment Algorithm", RFC 7695, DOI 10.17487/RFC7695, , <https://www.rfc-editor.org/info/rfc7695>.

Author's Address

Timothy Winters
QA Cafe
100 Main Street, Suite #212
Dover, NH 03820
United States of America