Internet Engineering Task Force R. Despres Internet-Draft October 24, 2011 Intended status: Informational Expires: April 26, 2012 Unifying Double Translation and Encapsulation for 4rd (4rd-U) draft-despres-softwire-4rd-u-01 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 4rd 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 26, 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 26, 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. The 4rd-U Header Mapping . . . . . . . . . . . . . . . . . . . 6 3. 4rd-U Address Mapping - Checksum Neutrality . . . . . . . . . 8 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Despres Expires April 26, 2012 [Page 2] Internet-Draft Unified Translation-Encapsulation for 4rd October 2011 1. Problem Statement Stateless solutions for residual deployment of IPv4 across IPv6 networks, with shared and non-shared IPv4 addresses, have been found desirable by a number of operators (ref [I-D.ietf-softwire-stateless-4v6-motivation]). The most general configurations to be supported are shown in Figure 1, where CE stands for Customer-edge router, and BR for IPv6-network Border router. one or more identical BRs Customer per IPv4 one or more sites CEs 4rd Domain provider IPv4 providers | | | | | V V V V V +----------------------+ | IPv6 routing | +-------------------- -------------+ | | | | | +'-----'+ Derived +'-'+ | | IPv4 | |<= CE IPv6 +.-----.+ <= One or more add space +.-.+ prefix | ... | Domain | | +'-----'+ IPv4 prefixes -------------+ | | | | +.-----.+ | | | ... | | +-------------------- | | ... | | +-------------------- -------------+ | | | | | +'-----'+ Derived +'-'+ | | IPv4 | |<= CE IPv6 +.-----.+ <= One or more add space +.-.+ prefix | ... | Domain | | +'-----'+ IPv4 prefixes -------------+ | | | ^ | +.-----.+ | | | | \ | | +-------------------- \ +----------------------+ \ One or more statelessly advertised Mapping rules Figure 1: 4rd Domain Model Despres Expires April 26, 2012 [Page 3] Internet-Draft Unified Translation-Encapsulation for 4rd October 2011 For IPv6-domain traversal, different IPv6 packet formats have been proposed to convey IPv4 packets. Some are based on Double translation (e.g. in [I-D.xli-behave-divi] and [I-D.xli-behave-divi-pd] ); some are based on Encapsulation (e.g. in [I-D.murakami-softwire-4rd]). Both formats having advantages of their own, this document proposes to combine them in a unified approach (4rd-U). An important advantage of Encapsulation is that it fully preserves network transparency to IPv4 packets, while Double translation, based on the IP/ICMP translation algorithm of [RFC6145], introduces the following 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. o The IPv4 Type-of-service octet (TOS) cannot be preserved if the traversed IPv6 network has constraints on the IPv6 Traffic-class octet (TC). The first limitation, lack of IPv4-option support, 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 ([RFC0792] has an ICMP error massages meaning "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 MAY fragment packets and indicate, on a per packet basis, whether the network MAY itself fragment packets or not [RFC0791]: if a packet has its DF = 1 and is too big for the next link to be traversed without fragmentation, the network MUST discard this packet (the ICMP error message specified for this case in [RFC0792] is "fragmentation needed and DF set"); if a packet has its DF = 0 and is too big for the next link to be traversed without fragmentation, the network MUST fragment it, and forward its fragments. In IPv6, sources MAY fragment packets, but networks MUST NOT fragment them: if a packet is too big for the next link to be traversed without fragmentation, the network MUST discard it (with the returned ICMPv6 error message "Packet too big" [RFC4443]. Despres Expires April 26, 2012 [Page 4] Internet-Draft Unified Translation-Encapsulation for 4rd October 2011 Now, if an IPv4 packet having DF = 0 is too long to traverse an IPv6 network as a single packet (e.g. has 1400 octets and needs to traverse an IPv6 link whose limit is 1280 octets), the IPv4 packet MUST be fragmented and forwarded to comply with IPv4 rules, independently of the value of its DF bit. The problem of translation is then that IPv6 packets have no field to convey the DF-bit value. At IPv6 network exit, where the IPv6 packet has to be translated back to IPv4, one cannot determine whether: (a) the IPv4 packet had been fragmented by its source with with DF = 1 and with a size small enough to need no fragmentation to traverse the IPv6 network; or, (b), the IPv4 packet had been sent with DF = 0 and needed fragmentation to traverse the IPv6 network. The original DF bit is lost. Consequences of not complying end-to-end with the IPv4- fragmentation specification may be limited, but there is no way to guarantee they will remain negligible. If choice exists, solutions that avoid this risk SHOULD therefore be preferred. The third limitation, lack of guaranteed transparency to the IPv4 TOS, has consequences that are difficult to predict because of the diversity of existing supports of TOS and TC octets. In some IPv6 networks, the IPv4 TOS can without problem be mapped into the IPv6 TC at IPv6-network entrance, and mapped back to the IPv4 TOS at IPv6- network exit. But in some other IPv6 networks, the IPv6 TC to be used for domain traversal has to comply with local constraints. To avoid that these constraints interfere with the semantics of the IPv4 TOS, the original TOS at domain exit MUST in this case be restored. On the other hand, Double translation has a significant advantage over Encapsulation: a number of existing Operation & Maintenance functions that work for IPv6 can be configured to work also for IPv4, even if concerned with transport-layer ports (e.g. Access control lists), or with valid transport-layer checksums (e.g. for web redirection). The problem is then to find a new design, if it exists, that keeps the best of both proposed approaches: (a) end-to-end transparency to IPv4; (b) applicability of IPv6 Operation & Maintenance tools of IPv6-only domains to IPv4 packets. Such a design happening to be possible, it is proposed in Section 2. Despres Expires April 26, 2012 [Page 5] Internet-Draft Unified Translation-Encapsulation for 4rd October 2011 2. The 4rd-U Header Mapping The approach of 4rd-U to meet requirements of Section 1 consists in specifying a header mapping from IPv4 to IPv6 that: o is reversible (network transparency to IPv4), o has no impact on UDP and TCP checksums (checksum neutrality). Its IPv6 packet format, compared to those of Double Translation and those of Encapsulation is shown in Figure 2. IPv4 packet 4rd-U IPv6 packet +-----------------+ _ _ +-----------------+ | IPv4 Header | _| --> | | IPv6 Header | +-----------------+ | +-----------------+ | IP Data | |_ |IPv6 Frag. Header| +-----------------+ +-----------------+ | IP Data | +-----------------+ Double translation for UDP/TCP (ref. RFC 6145) +-----------------+ _ _ +-----------------+ | IPv4 Header | _| --> | | IPv6 Header | +-----------------+ _ | +-----------------+ |Transport Header | _| -. |_ |IPv6 Frag. Header| (if needed) +-----------------+ \ _ +-----------------+ | Transport Data | '-> |_ |Transport Header | (adjusted cksm +-----------------+ +-----------------+ if needed) | Transport Data | +-----------------+ Encapsulation (ref I-D.murakami-softwire-4rd) +-----------------+ _ _ +-----------------+ | IPv4 Header | _| --> | | IPv6 Header | +-----------------+ | +-----------------+ | IP Data | | |IPv6 Frag. Header| (if needed) +-----------------+ | +-----------------+ |_ | IPv4 Header | +-----------------+ | IP Data | +-----------------+ Compared Packet Formats of 4rd-U - Translation - Encapsulation Figure 2 Despres Expires April 26, 2012 [Page 6] 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 + | (Mapped from IPv4 address or address + port) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Destination Address + | (Mapped from IPv4 address or address + port) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Reserved | IPv6 Fragment Offset | 0 |M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D| 0 | IPv4 TOS | IPv4 Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Payload | | | 4rd-U Header Mapping Figure 3 Despres Expires April 26, 2012 [Page 7] Internet-Draft Unified Translation-Encapsulation for 4rd October 2011 The 4rd-U header mapping is detailed in Figure 3. In it, D stands for DF, and the Flow Label should by be set to 0. Values of all other fields can be determined by simple rules known by anyone familiar with IPv4 and IPv6 packet formats. This header mapping takes advantage of the following favorable technical facts: o IPv6 packets MAY contain Fragment headers o In IPv6 fragment headers, Identification fields used for reassembly have 64 bits, i.e. 32 bits more than in IPv4. (This is enough to transparently convey IPv4 fields that need to be restorable at IPv6-domain exit, namely the DF bit an the TOS octet as explained in Section 1). o IPv6 addresses used to convey IPv4 packets can be made checksum neutral (see Section 3). 3. 4rd-U Address Mapping - Checksum Neutrality For residual IPv4 deployments across IPv6 networks, a number of address-mappings between IPv4 addresses, or IPv4 addresses plus ports, and IPv6 addresses have been proposed. One of them has even been proposed as a unified address mapping for Double translation and Encapsulation solutions [unifAddMapp]. But it was devised before a further unification, with a unified packet format like that of 4rd-U, had been envisaged. It misses one important feature: the checksum neutrality discussed in Section 2. The proposal below, is devised to keep all significant properties of [unifAddMapp] and to add checksum neutrality. It sacrifices for this the length indicator that was included in IPv6 addresses but was necessary neither for routing 4rd packets in IPv6 networks, nor for 4rd functions at exit of IPv6 networks. (It could have been useful to facilitate maintenance, but in a way that appears quite secondary.) Figure 4 shows steps whereby an IPv6 destination address is derived from an IPv4 destination address and from the value of the field where transport protocols have their destination ports ("DST port field"). If the IP payload has less that 4 octets, missing octets of the DST port field are replaced by 0s to keep uniformity of treatment. Despres Expires April 26, 2012 [Page 8] Internet-Draft Unified Translation-Encapsulation for 4rd October 2011 32 16 +----------------------+---------------+ | DST IPv4 address |DST port field | +----------------------+--+------------+ : : : 12 : : : +------------+ : : | Max PSID | : : +------------+ : : / / : 44 :/ / +-----------------------------------+ | DST max 4rd prefix | +----------------+------------------+ : : : : 0 to 32 : : +----------------+ : |Rule IPv4 prefix| : +----------------+ : max 64 : max 44 : +------------------+------------------+ | Rule IPv6 prefix | DST max index | +------------------+------------------+ : max 104 : : : min 0 +-------------------------------------+-------------------+ | DST max IPv6 prefix | Padding = 0 | +-------------------------------------+-------------------+ : : : 104 : +---------------------------------------------------------+ | DST padded max IPv6 prefix | +----------------------------------+----------------------+ : 64 :\ 40 \ : +-+ Checksum +--------+ : |V| neutrality | CNP | : +-+ preserver +--------+ : :4: : 16 : +----------------------------------+-+----------------------+--------+ | DST IPv6 address | +--------------------------------------------------------------------+ 128 From DST IPv4 Address plus DST Port field to DST IPv6 address Figure 4 Despres Expires April 26, 2012 [Page 9] Internet-Draft Unified Translation-Encapsulation for 4rd October 2011 Successive steps are the following: 1. Build the DST max 4rd prefix by concatenating the DST IPv4 address and the last 12 bits of the DST port field. 2. Build the DST padded max IPv6 prefix by replacing, in this DST max 4rd prefix, bits that match the IPv4 prefix of a mapping rule by the IPv6 prefix of this mapping rule, and by padding the result with 0s if necessary to reach 104 bits. 3. Build the DST IPv6 address by concatenating: (a) the first 64 bits of the DST padded max IPv6 prefix; (b) The 4rd V octet, a mark that never appears in any other IPv6 address, and whose proposed value is 0x03 (it permits to use the same CE IPv6 prefix for 4rd packets and for other IPv6 packets); (c) the last 40 bits of the DST padded max IPv6 prefix; (d) A Checksum neutrality preserver CNP (in one's complement arithmetic, it is the sum of the two 16 bit fields of the IPv4 address minus the sum of 16 bit fields of (a).(b).(c)). Unless something has been missed, this address mapping has, in addition to its checksum neutrality, all properties needed for scenarios of previously documented Encapsulation and Double- translation solutions. In particular, with a mapping rule whose IPv4 prefix is 0/0, it can support scenarios where full IPv4 addresses are contained in IPv6 addresses, e.g. those of [I-D.xli-behave-divi]. It can also support scenarios where IPv6 routing plans are independent from any consideration on IPv4, like those permitted by [I-D.despres-softwire-4rd-addmapping]. For these, the way in which CEs derive their IPv4 prefixes, IPv4 addresses, or IPv4 addresses plus restricted port sets, from their IPv6 pre-assigned prefixes, needs no change to be consistent with the 4rd-U address mapping as specified above (see Figure 5). Despres Expires April 26, 2012 [Page 10] Internet-Draft Unified Translation-Encapsulation for 4rd October 2011 max 104 +---------------------------+ | CE IPv6 prefix | +---------------------------+ : : : max 64 max 44 : +------------------+--------+ | Rule IPv6 prefix |CE index| +------------------+--------+ : : max 32 : : +----------------+ : |Rule IPv4 prefix| : +----------------+ : : : : max 44 : +-------------------------+ | CE 4rd prefix | +-------------------------+ :\_________________ :\______________ : \ : \ : ___:____/ : : max 32 / : 32 1 to 12: +--------------+ +---------------+------+ |CE IPv4 prefix| OR |CE IPv4 address| PSID | +--------------+ +---------------+------+ : : 4 : : +--+ +---------+ |y | | x | +--+ +---------+ : : : 32 : +-------------------+ |Port in CE port set| +-------------------+ y > 0, x any value From IPv6 prefix to IPv4 prefix or IPv4 address + Port set Figure 5 Despres Expires April 26, 2012 [Page 11] Internet-Draft Unified Translation-Encapsulation for 4rd October 2011 4. Conclusion This proposal is submitted to the Softwire WG as a short term technical contribution, not as a document expected to become per se an RFC. The expectation is that its substance, duly evaluated by the WG, and amended as much as found necessary, can quickly be a basis of a unified standard, suitable for all desirable scenarios for stateless deployments of residual IPv4 across IPv6 networks. 5. Acknowledgements The original idea of unifying Encapsulation and Double translation has been influenced by thorough discussions, at the Softwire interim meeting in Beijing, on compared merits of these two approaches. In particular, contributions of Xing Li, Congxiao Bao, and Wojciech Dec, have to be acknowledged. Improvements made since the first version of this document have been influenced by remarks received, on the Softwire mailing list and privately, in particular from Satoru Matsushima, Mark Townsley, and Maoke Chen. 6. References 6.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 6.2. Informative References [I-D.despres-softwire-4rd-addmapping] Despres, R., Qin, J., Perreault, S., and X. Deng, "Stateless Address Mapping for IPv4 Residual Deployment (4rd)", draft-despres-softwire-4rd-addmapping-01 (work in progress), September 2011. [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", Despres Expires April 26, 2012 [Page 12] Internet-Draft Unified Translation-Encapsulation for 4rd October 2011 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] Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual- Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-03 (work in progress), July 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. [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. [unifAddMapp] "Proposed Unified Address Mapping for encapsulation and double-translation - http://www.ietf.org/mail-archive/web/ softwires/current/msg02994.html", October 2011. Author's Address Remi Despres 3 rue du President Wilson Levallois, France Email: despres.remi@laposte.net Despres Expires April 26, 2012 [Page 13]