Network Working Group N. Matsuhira
Internet-Draft neptela
Intended status: Informational 20 October 2024
Expires: 23 April 2025
Provider Independent Addresses Aggregation
draft-matsuhira-pia-00
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.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
Matsuhira Expires 23 April 2025 [Page 1]
Internet-Draft PIA October 2024
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2
3. Current status of PA and PI . . . . . . . . . . . . . . . . . 3
3.1. PA . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. PI . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Multihoming and Addresses . . . . . . . . . . . . . . . . . . 3
5. Aggregation of PI addresses . . . . . . . . . . . . . . . . . 3
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
9. Normative References . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4
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.
Matsuhira Expires 23 April 2025 [Page 2]
Internet-Draft PIA October 2024
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.
Matsuhira Expires 23 April 2025 [Page 3]
Internet-Draft PIA October 2024
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, January 1997,
<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, March 1997,
<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, July 1998,
<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,
August 2003, <https://www.rfc-editor.org/info/rfc3587>.
Author's Address
Naoki Matsuhira
neptela
Japan
Email: matsuhira.ietf@gmail.com
Matsuhira Expires 23 April 2025 [Page 4]