Skip to main content

Outer Header Translator
draft-matsuhira-oht-02

Document Type Active Internet-Draft (individual)
Author Naoki Matsuhira
Last updated 2024-08-27
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-matsuhira-oht-02
Network Working Group                                       N. Matsuhira
Internet-Draft                                                   Neptela
Intended status: Informational                            28 August 2024
Expires: 1 March 2025

                        Outer Header Translator
                         draft-matsuhira-oht-02

Abstract

   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.

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 1 March 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Matsuhira                 Expires 1 March 2025                  [Page 1]
Internet-Draft                     OHT                       August 2024

   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
   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.  Concept of Architecture . . . . . . . . . . . . . . . . . . .   3
   3.  Terminoligy . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Network Configuration . . . . . . . . . . . . . . . . . . . .   4
   5.  OHT Processing  . . . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  Support IP protocol versions  . . . . . . . . . . . . . .   5
     5.2.  Encapsulation / Decapsulation . . . . . . . . . . . . . .   5
     5.3.  OHT Table . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.4.  Address Type  . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Possible Solutions  . . . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     10.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   NAT [RFC1631] 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 private addresses [RFC1597] 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.

   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.

Matsuhira                 Expires 1 March 2025                  [Page 2]
Internet-Draft                     OHT                       August 2024

   On the other hand, 8+8/GSE [I-D.ietf-ipngwg-gseaddr] 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.

   Furthermore, as for the transition technology from IPv4 to IPv6,
   technologies that involve address translation such as NAT-PT
   [RFC2766] were considered, but this is also a technology similar to
   NAT and has a lot of discussion.

   Internet Transparency is summarized in RFC2775 [RFC2775].

2.  Concept of Architecture

   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.

   Figure 1 shows encapsulation.  IP Encapsulation within IP is
   described in RFC2003 [RFC2003].

                                          +-------------------------+
                                          |                         |
                                          |     Outer IP Header     |
                                          |                         |
        +-------------------------+       +-------------------------+
        |                         |       |                         |
        |        IP Header        |       |        IP Header        |
        |                         |       |                         |
        +-------------------------+ ====> +-------------------------+
        |                         |       |                         |
        |                         |       |                         |
        |        IP Payload       |       |        IP Payload       |
        |                         |       |                         |
        |                         |       |                         |
        +-------------------------+       +-------------------------+

                                  Figure 1

   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.

Matsuhira                 Expires 1 March 2025                  [Page 3]
Internet-Draft                     OHT                       August 2024

3.  Terminoligy

   This section defines terminologies.

   Outer Header Translator
      Refers to the device or processing module that performs this
      processing.

   Outer Header Translation
      Show the method.

   Outer Header Translation Table
      Outer Header Translation Table

   Outer Header Translation Relay
      Indicates communication via one or more Outer Header Translators

   Outer Header Translation Domain
      Indicates a domain using OHT.

4.  Network Configuration

   This section describes network configuration with OHT.

   Figure 2 shows sample network configuration with OHT.

                 ~~~~~~~~~~                  ~~~~~~~~~
   +-------+    /   IP    /    +-------+    /   IP    /    +-------+
   |  OHT  |----/ Network /----|  OHT  |----/ Network /----|  OHT  |
   +----+--+    /         /    +-------+    /         /    +--+----+
        |       ~~~~~~~~~~~                 ~~~~~~~~~~        |
   ---+-+----                                             ----+-+---
      |                                                         |
   +--+---*                                                 +---+--*
   | HOST |                                                 | HOST |
   +------*                                                 +------*

                                  Figure 2

   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.

5.  OHT Processing

Matsuhira                 Expires 1 March 2025                  [Page 4]
Internet-Draft                     OHT                       August 2024

5.1.  Support IP protocol versions

   Figure 3 shows possible IP protocol versions, i.e. IPv4 [RFC791] and
   IPv6 [RFC8200]combinations.

     +---------------------------+----------------------------+
     |  Outer IP Header Version  | Inner IP Protocol Version  |
     +---------------------------+----------------------------+
     |                           |     IPv6                   |
     |           IPv6            +----------------------------+
     |                           |     IPv4                   |
     +---------------------------+----------------------------+
     |                           |     IPv6                   |
     |           IPv4            +----------------------------+
     |                           |     IPv4                   |
     +---------------------------+----------------------------+

                                  Figure 3

   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.

5.2.  Encapsulation / Decapsulation

   In this concept, the outer header is a copy of the inner header.

   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.

   If support for IPv4 private addresses, M46A [I-D.matsuhira-m46a]
   might be useful.

5.3.  OHT Table

   Figure 4 shows the structure of OHT table.

Matsuhira                 Expires 1 March 2025                  [Page 5]
Internet-Draft                     OHT                       August 2024

+------+------+------+------+------+------+------+------++------+------+
| 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 |
+------+------+------+------+------+------+------+------++------+------+
|      |      |      |      |      |      |      |      ||      |      |
+------+------+------+------+------+------+------+------++------+------+
|      |      |      |      |      |      |      |      ||      |      |
+------+------+------+------+------+------+------+------++------+------+
|   :  |   :  |   :  |   :  |   :  |   :  |   :  |   :  ||   :  |   :  |
|   :  |   :  |   :  |   :  |   :  |   :  |   :  |   :  ||   :  |   :  |
+------+------+------+------+------+------+------+------++------+------+

                               Figure 4

   The table may contain Traffic Class and Flow Label.

5.4.  Address Type

   Figure 5 shows possible address type [RFC4291] combinations for outer
   header destination addresses and inner header destination addresses
   are shown.

   +------------------------------------------------------------+
   |  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      |
   +-+--------------------------+---------+---------+-----------+

                                  Figure 5

Matsuhira                 Expires 1 March 2025                  [Page 6]
Internet-Draft                     OHT                       August 2024

6.  Possible Solutions

   OHT provides solutions for mobility, migration, multi-homing, policy
   routing, service function chaining, etc.  More details will be
   provided in the future versions.

7.  IANA Considerations

   This document makes no request of IANA.

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

8.  Security Considerations

   IPsec for internal packets works because internal packets are
   forwarded unchanged.

9.  Acknowledgements

   It may be listed in the future.

10.  References

10.1.  Normative References

   [I-D.matsuhira-m46a]
              Matsuhira, N., "Multiple IPv4 - IPv6 mapped IPv6 address
              (M46A)", Work in Progress, Internet-Draft, draft-
              matsuhira-m46a-16, 4 April 2024,
              <https://datatracker.ietf.org/doc/html/draft-matsuhira-
              m46a-16>.

   [RFC2003]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
              DOI 10.17487/RFC2003, October 1996,
              <https://www.rfc-editor.org/info/rfc2003>.

   [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>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

Matsuhira                 Expires 1 March 2025                  [Page 7]
Internet-Draft                     OHT                       August 2024

   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

10.2.  Informative References

   [I-D.ietf-ipngwg-gseaddr]
              O'Dell, M. D., "GSE - An Alternate Addressing Architecture
              for IPv6", Work in Progress, Internet-Draft, draft-ietf-
              ipngwg-gseaddr-00, 24 February 1997,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ipngwg-
              gseaddr-00>.

   [RFC1597]  Rekhter, Y., Moskowitz, B., Karrenberg, D., and G. de
              Groot, "Address Allocation for Private Internets",
              RFC 1597, DOI 10.17487/RFC1597, March 1994,
              <https://www.rfc-editor.org/info/rfc1597>.

   [RFC1631]  Egevang, K. and P. Francis, "The IP Network Address
              Translator (NAT)", RFC 1631, DOI 10.17487/RFC1631, May
              1994, <https://www.rfc-editor.org/info/rfc1631>.

   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
              Translation - Protocol Translation (NAT-PT)", RFC 2766,
              DOI 10.17487/RFC2766, February 2000,
              <https://www.rfc-editor.org/info/rfc2766>.

   [RFC2775]  Carpenter, B., "Internet Transparency", RFC 2775,
              DOI 10.17487/RFC2775, February 2000,
              <https://www.rfc-editor.org/info/rfc2775>.

Author's Address

   Naoki Matsuhira
   Neptela
   Japan
   Email: matsuhira.ietf@gmail.com

Matsuhira                 Expires 1 March 2025                  [Page 8]