Internet-Draft OHT February 2024
Matsuhira Expires 29 August 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-matsuhira-oht-01
Published:
Intended Status:
Informational
Expires:
Author:
N. Matsuhira
Neptela

Outer Header Translator

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 29 August 2024.

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.

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.

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

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.

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

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-15, , <https://datatracker.ietf.org/doc/html/draft-matsuhira-m46a-15>.
[RFC2003]
Perkins, C., "IP Encapsulation within IP", RFC 2003, DOI 10.17487/RFC2003, , <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, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC4291]
Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, , <https://www.rfc-editor.org/info/rfc4291>.
[RFC791]
Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc2766>.
[RFC2775]
Carpenter, B., "Internet Transparency", RFC 2775, DOI 10.17487/RFC2775, , <https://www.rfc-editor.org/info/rfc2775>.

Author's Address

Naoki Matsuhira
Neptela
Japan