<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?>
<!DOCTYPE rfc [
  <!ENTITY nbsp "&#160;">
  <!ENTITY zwsp "&#8203;">
  <!ENTITY nbhy "&#8209;">
  <!ENTITY wj "&#8288;">
]>
<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="info"
  docName="draft-sanoj-ipip-00"
  ipr="trust200902"
  obsoletes=""
  updates=""
  submissionType="IETF"
  xml:lang="en"
  version="3">

  <front>
    <title abbrev="Abbreviated Title">InterPlanetary Internet Protocol (IPIP)</title>
    <seriesInfo name="Internet-Draft" value="draft-sanoj-ipip-00" />
    <author fullname="Sanoj Kumar" initials="S" role="editor" surname="Kumar">
      <address>
        <phone>+917639661040</phone>
        <email>hello@sanoj.io</email>
        <uri>https://sanoj.io/</uri>
      </address>
    </author>

    <date year="2023"/>
    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <keyword>ipip</keyword>
    <abstract>
      <t>With an exponential increase in the number of devices being connected to the internet, it
        is clear that the available address range of 2^128 in IPv6 Protocol
        would not be sufficient to identify and exchange information with all the devices in the
        universe. This document describes how Internet Protocol addressing standards can be further
        enhanced to accommodate a wider scale of network devices.</t>
    </abstract>
  </front>

  <middle>
    <section>
      <name>Introduction</name>
      <t>While the current rate of IPv6 Address allocation gives us plenty
        of time to handle the exhaustion problem, the Internet's History has shown that the address
        spaces are filled up exponentially. Scientific advances in Quantum Technology and
        Inter-space Exploration further increase the need for a larger addressing method. Therefore,
        the Internet Protocol address space must be increased as soon as possible.</t>
      <t>The exact length of the addressing space is assumed to be 256 bits in this document and
        requires further expert discussion between IETF, IANA, and various gods for assessing the
        exact count of planets and the number of particles in the universe. However, at the time of
        this document's publication, the estimated amount of planets in the Milky Way Galaxy was
        approximately 10^55 planets. Assuming the approximate count of sand particles on
        Planet Earth (10^22) as an average baseline for the number of network devices on every
        planet,
        it is evident that Interplanetary adoption of Internet Protocol requires a larger address
        space of at least 10^77.</t>
      <section anchor="requirements">
        <name>Requirements Language</name>
        <t>The keywords "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 <xref target="RFC2119" />
          <xref target="RFC8174" />
          when, and only when, they appear in all capitals.</t>
      </section>
    </section>

    <section anchor="addressing">
      <name>IPIP Addressing</name>
      <t>IPIP addresses are 256-bit identifiers for network interfaces and various particles capable
        of connecting to the Internet. It is <bcp14>RECOMMENDED</bcp14> that more than one IPIP
        address <bcp14>SHOULD NOT</bcp14> be assigned for any network interface or particle in the
        universe. An exception <bcp14>MAY</bcp14> be applied for this constraint if, and only if,
        there is a clear requirement for assigning multiple IPIP addresses to sub-atomic particles
        or if IANA is required to provide more address space for a more sentient species from other
        planets.</t>
    </section>

    <section anchor="representation">
      <name>Text Representation of IPIP Addresses</name>
      <t>There are two conventional forms for representing an IPIP address as text strings:</t>
      <ol type="(%d)">
        <li>The preferred form is x:x:x:x:x:x:x:x:x:x:x:x:x:x:x:x, where the 'x's are one to four
          hexadecimal digits of the eight 16-bit pieces of the address.<br /> For Example:<br />
          ABCD:EF01:2345:6789:ABCD:EF01:2345:6789:ABCD:EF01:2345:6789:ABCD:EF01:2345:6789</li>
        <li>An alternative form that is more convenient when dealing with multiple planets and
          species would be to compress zeros. The use of "::" indicates one or more groups of 16
          bits of zeros. The "::" can only appear once in an address. The "::" can also be used to
          compress leading or trailing zeros in an address.<br /> For Example, the following address<br />
          ABCD:EF01:0000:0000:ABCD:EF01:2345:6789:ABCD:EF01:2345:6789:ABCD:EF01:2345:6789<br /> may
          be represented as<br />
          ABCD:EF01::ABCD:EF01:2345:6789:ABCD:EF01:2345:6789:ABCD:EF01:2345:6789</li>
      </ol>
    </section>

    <section anchor="routing">
      <name>IPIP Routing</name>
      <t>There should be little to no impact on routing using 256-bit addresses considering the
        exponential processor and memory technology advancements. It is <bcp14>RECOMMENDED</bcp14>
        that network routes for planet-specific IPIP addresses are not broadcast to other planets
        outside of the origin planet to avoid network congestion in the Universal Internet. Any
        rogue network routes which don't follow this constraint are <bcp14>REQUIRED</bcp14> to have
        the Security Flag <xref target="RFC3514" /> set with a value of 0x1 to indicate malicious
        intent to other devices on the network.</t>
    </section>

    <section anchor="allocation">
      <name>Address Allocation</name>
      <t>The 256-bit addresses would be obsolete once more planets are discovered and hence it is <bcp14>
        RECOMMENDED</bcp14> that an IPIP address be allocated to a network interface/particle if,
        and only if, there is a clear requirement to communicate with other network
        interface/particle. </t>
      <t>Allocation of an IPIP Addresses would be at the sole discretion of IANA based on a Pseudo
        Random Number Generator (PRNG). To ensure that IPIP address space is conserved, it is <bcp14>
        RECOMMENDED</bcp14> that IANA performs a Coin-Toss check to ensure address integrity before
        allocating any address to the requesting entity. IPIP Address space can be further conserved
        by using Quantum Entanglement where a single IPIP address can be shared between one or more
        particles.</t>
    </section>

    <section anchor="IANA">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>

    <section anchor="Security">
      <name>Security Considerations</name>
      <t>This document should not affect the security of the Internet since all network devices
        using IPIP addresses is <bcp14>REQUIRED</bcp14> to be in conformance with <xref
          target="RFC3514"></xref> for added security.</t>
    </section>
  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3514.xml" />
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml" />
      </references>

      <references>
        <name>Informative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization />
            </author>
            <date year="1997" month="March" />
            <abstract>
              <t>In many standards track documents several words are used to signify the
                requirements in the specification. These words are often capitalized. This document
                defines these words as they should be interpreted in IETF documents. This document
                specifies an Internet Best Current Practices for the Internet Community, and
                requests discussion and suggestions for improvements.
              </t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14" />
          <seriesInfo name="RFC" value="2119" />
          <seriesInfo name="DOI" value="10.17487/RFC2119" />
        </reference>
      </references>
    </references>
  </back>
</rfc>