Network Working Group P. L. Ursini Internet-Draft Quad State Internet Intended status: Informational 24 November 2024 Expires: 28 May 2025 E6Translate: Bridging IPv4-Only Hosts to IPv6 Internet draft-ursini-e6translate-00 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. Note 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. Ursini Expires 28 May 2025 [Page 1] Internet-Draft E6Translate: Bridging IPv4-Only Hosts to November 2024 Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 3. E6Translate Protocol Design . . . . . . . . . . . . . . . . . 3 3.1. DNS Masking and Mapping . . . . . . . . . . . . . . . . . 3 3.2. Connection Tracking and Timeouts . . . . . . . . . . . . 3 3.3. Router-Level Translation . . . . . . . . . . . . . . . . 3 3.4. IPv6-to-IPv4 Reverse Mapping and Port Forwarding . . . . 4 4. Protocol Workflow . . . . . . . . . . . . . . . . . . . . . . 4 5. Practical Benefits for Network Administrators . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 5 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 10. Informative References . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 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. Ursini Expires 28 May 2025 [Page 2] Internet-Draft E6Translate: Bridging IPv4-Only Hosts to November 2024 2. Problem Statement The transition to IPv6 is hampered by: * Legacy IPv4 Devices: Many existing devices do not support IPv6 natively, creating connectivity challenges in IPv6-only environments. * Complex Transition Mechanisms: Current solutions like NAT64 require significant configuration, making them impractical for small-scale deployments. * IPv6 Connectivity Gaps: IPv4-only devices cannot access IPv6-only resources, limiting interoperability. 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. * Dynamic Address Allocation: Temporary mappings are dynamically created and stored in a connection tracking table. * Seamless Resolution: IPv4-only hosts remain unaware of the mapping, receiving valid IPv4 responses. 3.2. Connection Tracking and Timeouts The E6T router manages a connection tracking table: * Mapping Expiration: Entries expire after a timeout to conserve resources. * Session Persistence: Active sessions retain their mappings for the duration of communication. Connections are tracked in a similar fashion to IPv4 NAT. 3.3. Router-Level Translation E6T routers perform bidirectional translation: * IPv4-to-IPv6: Outbound IPv4 packets are translated to IPv6. Ursini Expires 28 May 2025 [Page 3] Internet-Draft E6Translate: Bridging IPv4-Only Hosts to November 2024 * IPv6-to-IPv4: Inbound IPv6 packets are translated back to IPv4. 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: * Example Mapping: * IPv4 Address: 192.0.2.0 * IPv6 Address: 2001:db8::c0a8:0164 Port forwarding routes traffic from IPv6 clients to IPv4 devices. 4. Protocol Workflow * DNS Query: An IPv4-only host queries an E6T-aware DNS server for an IPv6 resource. * Address Allocation: The DNS server allocates a temporary Class E IPv4 address. * Outbound Traffic: The host sends packets to the temporary IPv4 address, which the E6T router translates to IPv6. * Reverse Mapping: External IPv6 clients access IPv4 devices via port forwarding. 5. Practical Benefits for Network Administrators * Simplified Transition: Minimal configuration requirements reduce administrative overhead. * Legacy Device Support: Enables IPv6 connectivity without upgrading hardware. * Scalability: Efficient resource allocation prevents address exhaustion. 6. Security Considerations * Spoofing Mitigation: Validate all incoming and outgoing packets to prevent mapping misuse. * State Exhaustion: Rate-limiting mechanisms prevent denial-of- service attacks. Ursini Expires 28 May 2025 [Page 4] Internet-Draft E6Translate: Bridging IPv4-Only Hosts to November 2024 * Connection Tracking Security: Ensure proper isolation between mapping sessions. 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", February 1996, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", December 1998, . [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", October 2005, . [RFC5735] Lear, E., "Special Use IPv4 Addresses", January 2010, . [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", October 2010, . [RFC7346] DeLong, O. and L. Howard, "IPv6 Multihoming without Network Prefix Translation", August 2014, . 10. Informative References [RFC6182] Ford, A., Raiciu, C., and M. Handley, "Architectural Guidelines for Multipath TCP Development", March 2011, . Ursini Expires 28 May 2025 [Page 5] Internet-Draft E6Translate: Bridging IPv4-Only Hosts to November 2024 [RFC2993] Durham, I. and B. Carpenter, "Architectural Implications of NAT", November 2000, . [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", December 2018, . Author's Address Preston Louis Ursini Quad State Internet 1212 Helen Street Paducah, KY 42001 United States Phone: +1 833-701-7823 Email: preston@quadstateinternet.net Ursini Expires 28 May 2025 [Page 6]