<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-matsuhira-pia-01" ipr="trust200902">
  <front>
    <title abbrev="PIA">Provider Independent Addresses Aggregation</title>

    <author fullname="Naoki Matsuhira" initials="N" surname="Matsuhira">
      <organization>neptela</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>Japan</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>matsuhira.ietf@gmail.com</email>

        <uri/>
      </address>
    </author>

    <date day="14" month="April" year="2025"/>

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

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>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.</t>
    </section>

    <section title="Problem Statement">
      <t>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.</t>

      <t>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.</t>

      <t>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.</t>

      <t>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.</t>
    </section>

    <section title="Current status of PA and PI">
      <t>In this section, the current situation of PA and PI is described.</t>

      <section title="PA">
        <t>There are three RFCs for PA. First, "An IPv6 Provider-Based Unicast
        Address Format" (<xref target="RFC2073">RFC2073</xref>), then "An IPv6
        Aggregatable Global Unicast Address Format" (<xref
        target="RFC2374">RFC2374</xref>), and now "IPv6 Global Unicast Address
        Format" (<xref target="RFC3587">RFC3587</xref>).</t>
      </section>

      <section title="PI">
        <t>There are no RFCs for PI.</t>
      </section>
    </section>

    <section title="Multihoming and Addresses">
      <t>In multihoming, if the connection links are the same ISP, the PA
      address can be used.</t>

      <t>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.</t>
    </section>

    <section title="Aggregation of PI addresses">
      <t>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.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t/>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t/>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?>

      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2073.xml"?>

      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2374.xml"?>

      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3587.xml"?>
    </references>
  </back>
</rfc>
