Internet-Draft E6Translate: Bridging IPv4-Only Hosts to November 2024
Ursini Expires 28 May 2025 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-ursini-e6translate-00
Published:
Intended Status:
Informational
Expires:
Author:
P. L. Ursini
Quad State Internet

E6Translate: Bridging IPv4-Only Hosts to IPv6 Internet

Abstract

E6Translate (E6T) is a protocol designed to address the challenges of bidirectional communication between IPv4-only hosts and the IPv6 Internet. Leveraging the reserved Class E IPv4 address space (240.0.0.0/4) as temporary placeholders for IPv6 destinations, E6T provides a lightweight and scalable mechanism for IPv4-to-IPv6 mapping and vice versa. To enable reverse connectivity, E6T repurposes a /96 segment of a /64 IPv6 prefix for IPv4-equivalent mapping, facilitating port forwarding and external access to legacy devices. This document outlines the design, operation, and practical applications of E6T, along with considerations for security, deployment, and protocol standardization.

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

This Internet-Draft will expire on May 26, 2025.

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 28 May 2025.

Table of Contents

1. Introduction

The transition to IPv6 has been slow due to the persistence of legacy IPv4-only devices in many networks. While solutions like NAT64 and DNS64 exist, they often require significant configuration expertise and specialized infrastructure. Many small organizations and home networks lack the technical expertise to deploy these solutions effectively.

E6Translate (E6T) is a protocol aimed at bridging this gap. By using the reserved Class E IPv4 space (240.0.0.0/4) for temporary mapping and providing reverse connectivity via IPv6 port-forwarding, E6T simplifies cross-protocol communication. This solution is particularly well-suited for environments with mixed IPv4 and IPv6 traffic, allowing network administrators to maintain functionality without upgrading legacy devices.

2. Problem Statement

The transition to IPv6 is hampered by:

E6T addresses these challenges with a lightweight, bidirectional mapping mechanism.

3. E6Translate Protocol Design

3.1. DNS Masking and Mapping

E6T-aware DNS servers intercept DNS queries from IPv4-only hosts for IPv6 destinations and respond with temporary Class E IPv4 addresses mapped to the requested IPv6 resource.

3.2. Connection Tracking and Timeouts

The E6T router manages a connection tracking table:

3.3. Router-Level Translation

E6T routers perform bidirectional translation:

3.4. IPv6-to-IPv4 Reverse Mapping and Port Forwarding

Reverse mapping assigns each IPv4 address a corresponding IPv6 address within a reserved /96 IPv6 prefix:

Port forwarding routes traffic from IPv6 clients to IPv4 devices.

4. Protocol Workflow

5. Practical Benefits for Network Administrators

6. Security Considerations

7. IANA Considerations

This proposal recommends reassigning the reserved Class E IPv4 address space (240.0.0.0/4) for E6Translate mappings. Additionally, a standardized /96 IPv6 prefix allocation is required for reverse mapping.

8. Conclusion

E6Translate provides a scalable, lightweight solution for bridging IPv4-only devices to the IPv6 Internet. Its design minimizes complexity while offering practical benefits for network administrators managing mixed-protocol environments.

9. Normative References

[RFC1918]
Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", , <https://www.rfc-editor.org/info/rfc1918>.
[RFC2460]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", , <https://www.rfc-editor.org/info/rfc2460>.
[RFC4193]
Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", , <https://www.rfc-editor.org/info/rfc4193>.
[RFC5735]
Lear, E., "Special Use IPv4 Addresses", , <https://www.rfc-editor.org/info/rfc5735>.
[RFC6052]
Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", , <https://www.rfc-editor.org/info/rfc6052>.
[RFC7346]
DeLong, O. and L. Howard, "IPv6 Multihoming without Network Prefix Translation", , <https://www.rfc-editor.org/info/rfc7346>.

10. Informative References

[RFC6182]
Ford, A., Raiciu, C., and M. Handley, "Architectural Guidelines for Multipath TCP Development", , <https://www.rfc-editor.org/info/rfc6182>.
[RFC2993]
Durham, I. and B. Carpenter, "Architectural Implications of NAT", , <https://www.rfc-editor.org/info/rfc2993>.
[RFC8305]
Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", , <https://www.rfc-editor.org/info/rfc8305>.

Author's Address

Preston Louis Ursini
Quad State Internet
1212 Helen Street
Paducah, KY 42001
United States