Internet-Draft PIA October 2024
Matsuhira Expires 23 April 2025 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-matsuhira-pia-00
Published:
Intended Status:
Informational
Expires:
Author:
N. Matsuhira
neptela

Provider Independent Addresses Aggregation

Abstract

This document proposes a discussion on whether PI address aggregation. More research, reviews, and discussions will be add in the future.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

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 23 April 2025.

Table of Contents

1. Introduction

This document proposes a discussion on whether PI address aggregation is necessary, and if so, what methods can be considered. It also summarizes the current status of PA addresses and PI addresses. More research, reviews, and discussions will be added in the future.

2. Problem Statement

Route aggregation technology was developed as a measure to deal with the routing table explosion in IPv4. Route aggregation is a prerequisite for IPv6.This is called PA (Provider Addresses). Meanwhile, PI (Provider Independent addresses) were considered for multihoming, but they have the characteristic that they cannot be aggregated. It is assumed that most currently in use are PA.

Looking back at the spread of IPv4, initially, the equivalent of PI addresses was used. In those days, organizations obtained addresses from a registry, rather than from the provider they were connecting to. It has expanded through a bottom-up process. From the perspective of operators of so-called intranets that have been built on this premise, obtaining addresses from a provider under IPv6 may be a good idea because it simplifies the process, but they may be concerned about being dependent on the provider. Or, if some intranet already has a multihoming configuration, operators may be wondering which PA address to use with IPv6.

Looking back at this history, it seems natural to use PI addresses for intranets. However, if PI addresses are increasingly allocated to corporate and campus networks, the problem of routing table explosion will likely become a reality, since they cannot be aggregated.

If one of the issues in the deploy of IPv6 to intranets is the difficulty of using PI addresses, this should be resolved. In that case, it would be desirable to obtain a perspective on the aggregation of PI addresses. In other words, author propose a discussion on whether aggregation of PI addresses is necessary, and if so, what methods can be considered.

3. Current status of PA and PI

In this section, the current situation of PA and PI is described.

3.1. PA

There are three RFCs for PA. First, "An IPv6 Provider-Based Unicast Address Format" (RFC2073 [RFC2073]), then "An IPv6 Aggregatable Global Unicast Address Format" (RFC2374 [RFC2374]), and now "IPv6 Global Unicast Address Format" (RFC3587 [RFC3587]).

3.2. PI

There are no RFCs for PI.

4. Multihoming and Addresses

In multihoming, if the connection links are the same ISP, the PA address can be used.

In multihoming, if the connection links are different ISPs, the PI address can be used. Note that IPv6 allows multiple IP addresses to be assigned to an interface, so it is also possible to assign provider base addresses from different ISPs. However, the issue is how to handle source address selection.

5. Aggregation of PI addresses

If PI addresses are assigned by the RIRs, one option would be to aggregate them at the RIR level. However, it seems likely that such aggregation could occur somewhere between the RIR level and the ISP level.

6. IANA Considerations

This document makes no request of IANA.

Note to RFC Editor: this section may be removed on publication as an RFC.

7. Security Considerations

8. Acknowledgements

9. Normative References

[RFC2073]
Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., and J. Postel, "An IPv6 Provider-Based Unicast Address Format", RFC 2073, DOI 10.17487/RFC2073, , <https://www.rfc-editor.org/info/rfc2073>.
[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>.
[RFC2374]
Hinden, R., O'Dell, M., and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, DOI 10.17487/RFC2374, , <https://www.rfc-editor.org/info/rfc2374>.
[RFC3587]
Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, , <https://www.rfc-editor.org/info/rfc3587>.

Author's Address

Naoki Matsuhira
neptela
Japan