Internet Engineering Task Force R. Despres Internet-Draft October 12, 2011 Intended status: Informational Expires: April 14, 2012 Unifying Double Translation and Encapsulation for 4rd (4rd-U) draft-despres-softwire-4rd-u-00 Abstract This document proposes a new packet format for IPv4 packets to traverse IPv6 networks. Its purpose is to get, for Residual Deployment of public IPv4 across IPv6 networks (4rd), the best of Encapsulation and Double-translation solutions. For this, it ensures end-to-end transparency of IPv6 networks to IPv4 packets, and makes it possible to configure existing IPv6 Operation & Management tools so that they operate also on IPv4 packets. 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 http://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 April 14, 2012. Copyright Notice Copyright (c) 2011 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 (http://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 Simplified BSD License text as described in Section 4.e of Despres Expires April 14, 2012 [Page 1] Internet-Draft Unified Translation-Encapsulation for 4rd October 2011 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 2. Proposed Unified Solution 4rd-U . . . . . . . . . . . . . . . . 4 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Normative References . . . . . . . . . . . . . . . . . . . 7 4.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Despres Expires April 14, 2012 [Page 2] Internet-Draft Unified Translation-Encapsulation for 4rd October 2011 1. Problem Statement Stateless solutions for Residual Deployment of public IPv4 addresses, shared and non-shared, across IPv6-only routing networks are have been found desirable by a number of operators (ref [I-D.ietf-softwire-stateless-4v6-motivation]). For this, two different IPv6 packet formats have been proposed by a number of contributors to convey IPv4 packets: one based on Encapsulation (e.g. in [I-D.murakami-softwire-4rd]), and one based on Double translation (e.g. in [I-D.xli-behave-divi-pd]). Both have advantages of their own that this document proposes to combine in a unified approach (4rd-U). An important advantage of Encapsulation is that it fully preserves network transparency to IPv4 packets, while Double translation, because it is based on the IP/ICMP translation algorithm of [RFC6145] that works for single translations between IPv6 and IPv4, introduces limitations to network transparency : o IPv4 options at the IP layer are not translated. o The "don't fragment" bit of IPv4 (DF bit) is not translated. The first limitation, loss of IPv4 options, can be accepted for the following reasons: (1) IPv4 options are very rarely used; (2) they don't influence which applications are supported; (3) Error messages are available to inform sources that options they tried to use are not supported (an ICMP message of [RFC0792] means "something is wrong with the type code of the first option".) The second limitation, lack of preservation of the DF-bit by IPv4- IPv6 translators, is more problematic: Its origin is that IPv4 and IPv6 treat packet fragmentations differently. In IPv4, sources hosts may fragment packets, and can also indicate, for each packet, whether they permit packet fragmentation in the network or not. If DF = 1 packets that are too big for the next link to be traversed MUST be discarded. If DF = 0, these packets MUST be fragmented and forwarded. But, in IPv6, packets don't have DF bits. They may be fragmented by source hosts, but MUST NOT be fragmented during network traversal. Despres Expires April 14, 2012 [Page 3] Internet-Draft Unified Translation-Encapsulation for 4rd October 2011 If an IPv4 packet having DF = 0 is too long to traverse an IPv6- only domain as a single translated packet, the IPv4-to-IPv6 translator at domain entrance MUST forward it. It then has to send it as several packets using the IPv6 Fragmentation extension. At domain exit, the IPv6-to-IPv4 translator cannot determine whether the original DF bit was 0 or 1: the original IPv4 packet MAY have been sent with DF = 1, and fragmented enough by its source to need no further fragmentation at domain entrance, or it MAY have been sent with DF = 0 and fragmented somewhere (by the source host and/or at domain entrance). The original DF bit is therefore lost during domain traversal. Consequences of not complying end-to end with the IPv4- fragmentation specification may be limited, but there is no way to guarantee that they will be negligible. If choice exists, solutions that avoid this risk should therefore be preferred. On the other hand, Double translation has a significant advantage over Encapsulation: a number of existing Operation & Maintenance tools that work for IPv6 can be configured to work also for IPv4, including if concerned with transport-layer ports. The problem is then to find a new mechanism, if it exists, that keeps the best of both proposed approaches: (1) end-to-end transparency to IPv4; (2) applicability of IPv6 Operation & Maintenance tools of the IPv6-only domain to IPv4 packets, including if concerned with ports. 2. Proposed Unified Solution 4rd-U The (simple) idea of 4rd-U is to map IPv4 headers into IPv6 headers in which Fragmentation extensions are always present, and to code the IPv4 DF bit in Identification fields of these extensions. Other than that, IPv4 payloads are taken as IPv6 payloads without any look at their contents. Network transparency to the DF bit is thus be ensured, and ports of IPv4 packets are found by Operation & Maintenance tools as though they would be ports of real IPv6 packets. Figure 1 illustrates how 4rd-U packet formats compare with those of Double Translation based on RFC 6145 [RFC6145], and those of Encapsulation. Note that how IPv6 addresses are derived from IPv4 addresses, and conversely, is a complementary subject, discussed separately. In case of shared IPv4 addresses, this derivation does involve transport-layer ports, and some ICMP processing, but this is is independent from the IPv6 packet format used to convey IPv4 packets. Despres Expires April 14, 2012 [Page 4] Internet-Draft Unified Translation-Encapsulation for 4rd October 2011 Translation +----------------+ (RFC 6145) +----------------+ | IPv4 Header | ==> | IPv6 Header | +----------------+ +----------------+ |Transport Header| |Fragment Header | +----------------+ | (if needed) | | Transport Data | +----------------+ +----------------+ |Transport Header| |(adjusted cksm | | if needed) | +----------------+ | Transport Data | +----------------+ +----------------+ Encapsulation +----------------+ | IPv4 Header | ==> | IPv6 Header | +----------------+ +----------------+ | IP Data | |Fragment Header | +----------------+ | (if needed) | +----------------+ | IPv4 Header | +----------------+ | IP Data | +----------------+ +----------------+ 4rd-U +----------------+ | IPv4 Header | ==> | IPv6 Header | +----------------+ +----------------+ | IP Data | |Fragment Header | +----------------+ +----------------+ | IP Data | +----------------+ Compared packet formats of Translation - Encapsulation - 4rd-U Figure 1 The 4rd-U packet format is illustrated in Figure 2, with D standing for DF. The IPv6 flow Label should by default be set to 0. All other fields can be determined by simple rules known by persons familiar with IPv4 and IPv6 packet formats. Despres Expires April 14, 2012 [Page 5] Internet-Draft Unified Translation-Encapsulation for 4rd October 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vers=4 |HeadL=5|Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Identification |0|D|M| IPv4 Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Payload | | | || \/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vers=6 | TrafClass | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length |Next Header=44 | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Reserved | IPv6 Fragment Offset | 0 |M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D| 0 | IPv4 Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Payload | | | 4rd-U Packet-Format Figure 2 Despres Expires April 14, 2012 [Page 6] Internet-Draft Unified Translation-Encapsulation for 4rd October 2011 3. Conclusion This proposal is submitted to the Softwire WG as an informational contribution. The expectation is that it might be useful to reduce the set of specifications to be standardized. No intellectual property right known by the author applies to it. 4. References 4.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 4.2. Informative References [I-D.ietf-softwire-stateless-4v6-motivation] Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., Borges, I., and G. Chen, "Motivations for Stateless IPv4 over IPv6 Migration Solutions", draft-ietf-softwire-stateless-4v6-motivation-00 (work in progress), September 2011. [I-D.murakami-softwire-4rd] Murakami, T., Troan, O., and S. Matsushima, "IPv4 Residual Deployment on IPv6 infrastructure - protocol specification", draft-murakami-softwire-4rd-01 (work in progress), September 2011. [I-D.xli-behave-divi-pd] Li, X., Bao, C., Dec, W., Asati, R., Xie, C., and Q. Sun, "dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix Delegation", draft-xli-behave-divi-pd-01 (work in progress), September 2011. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. Despres Expires April 14, 2012 [Page 7] Internet-Draft Unified Translation-Encapsulation for 4rd October 2011 Author's Address Remi Despres 3 rue du President Wilson Levallois, France Email: despres.remi@laposte.net Despres Expires April 14, 2012 [Page 8]