<?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-oht-02" ipr="trust200902">
  <front>
    <title abbrev="OHT">Outer Header Translator</title>

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

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

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

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

    <date day="28" month="August" year="2024"/>

    <abstract>
      <t>Network address translation technology has a convenient aspect,
      however, it has the side effect of breaking end-to-end transparency.
      This document proposes a technology that achieves both network address
      translation and end-to-end transparency. This technology may provide
      solutions for mobility, migration, multihoming, policy routing, etc.</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><xref target="RFC1631">NAT</xref> was devised as a short-term
      solution to the exhaustion of IPv4 addresses, and is placed at the
      boundary between a private network (Intranet) built using <xref
      target="RFC1597">private addresses</xref> and the Internet.
      Communication closed to the intranet is made possible by using private
      addresses. A global address is required only for hosts communicating
      with the Internet, and this is achieved by NAT performing address
      translation.This technology supported the expansion of the Intranets and
      the Internet.</t>

      <t>After that, technology was developed that allows multiple hosts to
      share a single global IPv4 address. This technology is called NAPT
      (Network Address Port Translation). This technology was primarily used
      in SOHO (small office/home office) networks and supported the expansion
      of SOHO networks and the Internet.</t>

      <t>On the other hand, 8+8/<xref
      target="I-D.ietf-ipngwg-gseaddr">GSE</xref> was proposed in the early
      stages of the IPv6 discussion. This proposal involves translating the
      prefix part of the IPv6 address. Therefore, it has the side effects of
      NAT. As a result, there was a lot of discussion. Note that this has
      nothing to do with IPv4 address exhaustion.</t>

      <t>Furthermore, as for the transition technology from IPv4 to IPv6,
      technologies that involve address translation such as <xref
      target="RFC2766">NAT-PT</xref> were considered, but this is also a
      technology similar to NAT and has a lot of discussion.</t>

      <t>Internet Transparency is summarized in <xref
      target="RFC2775">RFC2775</xref>.</t>
    </section>

    <section title="Concept of Architecture">
      <t>End-to-end transparency can be maintained by encapsulating packets
      generated by the host and subjecting only the encapsulated outer IP
      header to address translation. That is, internal packets must not be
      translation.</t>

      <t><xref target="Fig-encap"/> shows encapsulation. IP Encapsulation
      within IP is described in <xref target="RFC2003">RFC2003</xref>.</t>

      <t><figure anchor="Fig-encap">
          <artwork><![CDATA[
                                       +-------------------------+
                                       |                         |
                                       |     Outer IP Header     |
                                       |                         |
     +-------------------------+       +-------------------------+
     |                         |       |                         |
     |        IP Header        |       |        IP Header        |
     |                         |       |                         |
     +-------------------------+ ====> +-------------------------+
     |                         |       |                         |
     |                         |       |                         |
     |        IP Payload       |       |        IP Payload       |
     |                         |       |                         |
     |                         |       |                         |
     +-------------------------+       +-------------------------+
]]></artwork>
        </figure></t>

      <t>Typically, the destination IP address in the outer header is the
      address of the tunnel endpoint. However, in this concept, the outer
      header is a copy of the inner header. If the outer header is not
      translated, the outer header remains the same as the internal header.
      After encapsulation, the outer header of the packet is subject to
      translate.</t>
    </section>

    <section title="Terminoligy">
      <t>This section defines terminologies.</t>

      <t><list style="hanging">
          <t hangText="Outer Header Translator"><vspace blankLines="1"/>Refers
          to the device or processing module that performs this
          processing.</t>

          <t hangText="Outer Header Translation"><vspace blankLines="1"/>Show
          the method.</t>

          <t hangText="Outer Header Translation Table"><vspace
          blankLines="1"/>Outer Header Translation Table</t>

          <t hangText="Outer Header Translation Relay"><vspace
          blankLines="1"/>Indicates communication via one or more Outer Header
          Translators</t>

          <t hangText="Outer Header Translation Domain"><vspace
          blankLines="1"/>Indicates a domain using OHT.</t>
        </list></t>
    </section>

    <section title="Network Configuration">
      <t>This section describes network configuration with OHT.</t>

      <t><xref target="Fig-net-config"/> shows sample network configuration
      with OHT.</t>

      <t><figure anchor="Fig-net-config">
          <artwork><![CDATA[
              ~~~~~~~~~~                  ~~~~~~~~~
+-------+    /   IP    /    +-------+    /   IP    /    +-------+
|  OHT  |----/ Network /----|  OHT  |----/ Network /----|  OHT  |
+----+--+    /         /    +-------+    /         /    +--+----+
     |       ~~~~~~~~~~~                 ~~~~~~~~~~        |
---+-+----                                             ----+-+---
   |                                                         |
+--+---*                                                 +---+--* 
| HOST |                                                 | HOST |
+------*                                                 +------*

]]></artwork>
        </figure>Typically, OHT is implemented in a router. Encapsulation and
      decoupling are also implemented in routers. However, other
      implementations are possible. For example, encapsulation and
      decapsulation may be implemented in the host.</t>
    </section>

    <section title="OHT Processing">
      <section title="Support IP protocol versions ">
        <t><xref target="Fig-ip-proto"/> shows possible IP protocol versions,
        i.e. <xref target="RFC791">IPv4</xref> and <xref target="RFC8200">IPv6
        </xref>combinations.</t>

        <t><figure anchor="Fig-ip-proto">
            <artwork><![CDATA[
  +---------------------------+----------------------------+
  |  Outer IP Header Version  | Inner IP Protocol Version  |
  +---------------------------+----------------------------+
  |                           |     IPv6                   |
  |           IPv6            +----------------------------+
  |                           |     IPv4                   |
  +---------------------------+----------------------------+
  |                           |     IPv6                   |
  |           IPv4            +----------------------------+
  |                           |     IPv4                   |
  +---------------------------+----------------------------+
 ]]></artwork>
          </figure></t>

        <t>There are four combinations, and dealing with all of them would be
        complicated. Therefore, it would be good if the Outer IP Header could
        be limited to IPv6 only.</t>
      </section>

      <section title="Encapsulation / Decapsulation">
        <t>In this concept, the outer header is a copy of the inner
        header.</t>

        <t>In this concept, the outer header is essentially a copy of the
        inner header. According to this, the possible combinations of IP
        protocol versions are IPv6 over IPv6 and IPv4 over IPv4. If it is
        assumed that it will be applied to an IPv6 only backbone,
        accommodation of IPv4 will be possible with IPv6 over IPv6 over IPv4.
        In this case, the IPv6 Addresses with Embedded IPv4 Addresses can be
        used as the IPv6 address in the internal IPv6 header.</t>

        <t>If support for IPv4 private addresses, <xref
        target="I-D.matsuhira-m46a">M46A</xref> might be useful.</t>
      </section>

      <section title="OHT Table">
        <t><xref target="Fig-OHTtab"/> shows the structure of OHT table.</t>

        <t><figure anchor="Fig-OHTtab">
            <artwork><![CDATA[
+------+------+------+------+------+------+------+------++------+------+
| Inner| Inner| Inner| Inner| Inner| Inner| Inner| Outer|| Next | Next |
| Src  | Src  | dst  | dst  | Next | src  | dst  | Src  || Outer| Outer|
| IP   | IP   | IP   | IP   | Hdr  | port | port | IP   || Src  | Dst  |
| addr | mask | addr | mask |      |      |      | addr || IP   | IP   |
|      |      |      |      |      |      |      |      || addr | addr |
+------+------+------+------+------+------+------+------++------+------+
|      |      |      |      |      |      |      |      ||      |      |
+------+------+------+------+------+------+------+------++------+------+
|      |      |      |      |      |      |      |      ||      |      |
+------+------+------+------+------+------+------+------++------+------+
|   :  |   :  |   :  |   :  |   :  |   :  |   :  |   :  ||   :  |   :  |
|   :  |   :  |   :  |   :  |   :  |   :  |   :  |   :  ||   :  |   :  |
+------+------+------+------+------+------+------+------++------+------+

]]></artwork>
          </figure></t>

        <t>The table may contain Traffic Class and Flow Label.</t>
      </section>

      <section title="Address Type">
        <t><xref target="Fig-addrtype"/> shows possible <xref
        target="RFC4291">address type</xref> combinations for outer header
        destination addresses and inner header destination addresses are
        shown.</t>

        <t><figure anchor="Fig-addrtype">
            <artwork><![CDATA[
+------------------------------------------------------------+
|  outer header              +---------+---------+-----------+
|                            | unicast | anycast | multicast |
|                            | address | address | Address   |
|                            | Global  |         |           |
+-+-----------+--------------+---------+---------+-----------+
|i| unicast   | Global       |    o    |    o    |    ?      |
|n| address   +--------------+---------+---------+-----------+
|n|           | Embedded IPv4|    o    |    o    |    ?      |
|e|           +--------------+---------+---------+-----------+
|r|           | Link-Local   |    x    |    x    |    x      |
| |           +--------------+---------+---------+-----------+
|h|           | Unique Local |    o    |    o    |    ?      |
|d+-----------+--------------+---------+---------+-----------+
|r| anycast address          |    o    |    o    |    ?      |
| +--------------------------+---------+---------+-----------+
| | multicast address        |    o    |    o    |    o      |
+-+--------------------------+---------+---------+-----------+

]]></artwork>
          </figure></t>
      </section>
    </section>

    <section title="Possible Solutions">
      <t>OHT provides solutions for mobility, migration, multi-homing, policy
      routing, service function chaining, etc. More details will be provided
      in the future versions.</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>IPsec for internal packets works because internal packets are
      forwarded unchanged.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>It may be listed in the future.</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.2003.xml"?>

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

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

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

      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.matsuhira-m46a.xml"?>

      <?rfc ?>
    </references>

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

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

      <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ipngwg-gseaddr.xml"?>

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

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

      <?rfc ?>
    </references>
  </back>
</rfc>
