Softwires Working Group M. Chen Internet-Draft FreeBit Intended status: Informational April 10, 2012 Expires: October 12, 2012 A Commentary on 4rd-U Architecture and Semantics draft-chen-softwire-4rd-u-comment-00 Abstract 4rd-U is proposed as an effort of unifying encapsulation and double translation solutions for the softwire of IPv4 over IPv6 domain. This attempt introduces new behaviors in the Internet transition architecture as well as semantics other than that of well-known Internet protocols. This documents provides a commentary on the semantic changes and their impacts. 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 October 12, 2012. Copyright Notice Copyright (c) 2012 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 the Trust Legal Provisions and are provided without warranty as Chen Expires October 12, 2012 [Page 1] Internet-Draft 4rd-U Architectural Comments April 2012 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 4. 4rd-U Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. General motivations . . . . . . . . . . . . . . . . . . . 6 4.2. Technical problems to solve . . . . . . . . . . . . . . . 6 4.3. Technical means of the solution . . . . . . . . . . . . . 7 5. Semantic Changes of 4rd-U and Potential Impacts . . . . . . . 9 5.1. Semantics: existence of fragment header . . . . . . . . . 9 5.2. Semantics: IPv6 packet identification . . . . . . . . . . 9 5.3. Semantics: Hop Limit of IPv6 . . . . . . . . . . . . . . . 10 5.4. Semantics: IP/ICMP relationship . . . . . . . . . . . . . 11 6. On Tunnel as Architectural Building Block . . . . . . . . . . 13 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Chen Expires October 12, 2012 [Page 2] Internet-Draft 4rd-U Architectural Comments April 2012 1. Introduction The 4rd-U [I-D.despres-softwire-4rd-u] is proposed with the goal of unifying encapsulation and double translation into a single standard. That effort identifies its technical objective to realize the full transparency as in encapsultion and meanwhile the visibility of L4 protocol data unit (PDU) as in double translation. The designers of 4rd-U expect it plays the role of a replacement of the MAP suites, including MAP [I-D.mdt-softwire-mapping-address-and-port], MAP-E [I-D.mdt-softwire-map-encapsulation], MAP-T [I-D.mdt-softwire-map-translation] and the DHCP option for MAP [I-D.mdt-softwire-map-dhcp-option]. Throughout this document, the term "MAP", unless explicitly specified, refers to the suite of MAP documents, as an entire description of the MAP architecture. This commentary is purposed in sharing the observation on 4rd-U proposal. It covers part of the 4rd-U principles, focusing on its major semantics changes, especially those that possibly impact the architecture of the Internet and its transition. The commentary itself doesn't conclude if 4rd-U is or isn't a deployable architecture for transition. It provides information for those who would like to do such a judgement. The commentry can be referenced by 1) implementors/testers of 4rd-U to cover the architectural concerns when they set the test scenarios; 2) operators to evaluate if 4rd-U is a safe choice fitting their own networking environment and practice experiences; 3) the community of the Internet engineering to evaluate 4rd-U technology. This commentary sticks to the newest, currectly version -06, of the 4rd-U draft. Unless explicitly specified, the discussion doesn't cover the feasures once involved into the 4rd-U early versions but now already deprecated or obsolteted by other mechanisms. This commentary covers only topics that the author(s) have investigated. Co-authorship is welcome and input of further investigations is expected. Chen Expires October 12, 2012 [Page 3] Internet-Draft 4rd-U Architectural Comments April 2012 2. Conventions 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]. Chen Expires October 12, 2012 [Page 4] Internet-Draft 4rd-U Architectural Comments April 2012 3. Acknowledgements The author(s) thank Remi Despres for his efforts in continuously improving 4rd-U design and discussions through maillist and private communication. No matter if the 4rd-U will or will not become standard, such an effort would be significantly valuable for the collective understanding. A lot of contents of this commentary are illuminated by the maillist discussion in the softwire WG, including the view points contributed by Congxiao Bao, Wojciech Dec, Xing Li, Satoru Matsushima, Wentao Shang, Ole Troan and others. Chen Expires October 12, 2012 [Page 5] Internet-Draft 4rd-U Architectural Comments April 2012 4. 4rd-U Overview 4rd-U draft contains a lot of features overlapping the problems that MAP also having addressed. The following analysis on 4rd-U motivations, major technical objectives and exclusive solutions is based on the understanding of the commentary author(s) through reading 4rd-U drafts, comparing 4rd-U and MAP suites, and discussing with the 4rd-U designers. 4.1. General motivations Generally, 4rd-U is motivated with the purposes of (M1) unification of encapsulation and double translation for IPv4 residual deployment; (M2) simplification of L4 protocol treatment; (M3) simplification of address distinguishment in the environment where there are also native IPv6 communications. 4.2. Technical problems to solve Trying to solve the following problems makes 4rd-U different from MAP. (O1) DF=1/MF=1 transparency: [RFC6145], whose header processing of translation is applied in MAP-T, doesn't cover the case where IPv4 packet with both "Don't Fragment" (DF) and "More Fragment" (MF) flags set. MAP-T points out that this corner case is very minor and some literature (e.g., [IMC07]) argues such a case is considered abnormal regarding IPv4 protocol [RFC0791], followed by statistics on this abnormaly. 4rd-U argues it should be supported no matter how minor it is observed in practice. (O2) ToS transparency: DiffServ architecture ([RFC2475]) points out that, (regarding the IPSec tunnel consideration,) whether DSCP change in tunneling domain should be visible to the tunneled protocol or not, depends upon the role of "tunnel" in the architectural perspective. MAP-E follows [RFC2473] and keeps it as unchanged. MAP-T follows [RFC6145] and copies the IPv4 ToS into IPv6 TrafficClass and vice versa. 4rd-U argues ToS should be kept unchanged when the packet traverses the IPv6 domain, except the ECN bits. Chen Expires October 12, 2012 [Page 6] Internet-Draft 4rd-U Architectural Comments April 2012 (O3) IPv6 O&A tools fully functioning: when IPv4 packet is encapsulated, IPv4 protocol details is hidden and existing IPv6 O&A tools are unable to view these hidden details, and accordingly functions like filtering is not able to be performed. 4rd-U argues this "drawback" of MAP-E should and could be overcome without losing the full transparency of encapsulation. (O4) Deep L4 inspection: when IPv4 packet is encapsulated with IPv6, typically middle boxes in the IPv6 domain doesn't have the functionality of deep inspection on the Layer-4 protocol data unit (PDU) in the encapsulated packet. This makes MAP-E traffic is unable to be filtered with the existing IPv6 L4 filter rules . 4rd-U argues this "drawback" of MAP-E should and could be overcome without losing the full transparency of encapsulation. (O5) Checksum transparency: MAP-T, along with [RFC6145], adjust L4 protocol checksum at the translator. 4rd-U argues [RFC6145] optionally supporting DCCP checksum adjustment may cause wrong checksum for receiver of MAP-T if IPv4-to-IPv6 translator does the adjustment while the IPv6-to-IPv4 one doesn't. It also argues checksum validity should be ensured through address in order to simplify L4 processing. 4.3. Technical means of the solution In order to achieve the goal of (M1) and to solve the problems listed above, 4rd-U proposes a series of technical means. Essentially, a "reversible header mapping" is defined through these means, having IPv4 header fields (except options) reserved but the header is not embedded as a whole. This is to achieve the support for deep L4 inspection as translation can, meanwhile to keep the IPv4 header information unchanged the IPv6 domain. In details, these means include: (T1) Always-on fragment header: as a container preserving not only the fragmentation-related information but also some other fields. (T2) DF preserver: at the leftmost bit of IPv6 packet identification field of the fragment header, carrying the original IPv4 packet's DF bit. (T3) ToS preserver: at the bits 8~15 of IPv6 packet identification field of the fragment header, carrying the original value of IPv4 packet's ToS field. Chen Expires October 12, 2012 [Page 7] Internet-Draft 4rd-U Architectural Comments April 2012 (T4) TTL preservers: TTL first bit preserved at the leftmost bit of IPv6 HopLimit; TTL bits 1~7 preserved at bit 1~7 of IPv6 packet identification field of the fragment header. (T5) ICMPv4 being carried by IPv6: providing full transparency for ICMPv4 messages traversing the IPv6 domain; also as a required solution to deal with the problem that [RFC6145] has identified regarding the PTB message with MTU less than 1280 bytes (translated), and meanwhile keep the DF=1 transparent. (T6) ICMPv6 being translated: with the same logic that [RFC6145] defines for the ICMPv6 error messages generated by the middle boxes in the IPv6 domain. 4rd-U also defines techinal means for (M2) and (M3), respectively. Checksum neutrality preserver (CNP): in the end of IPv6 interface identifier, with the value ensuring the mapped IPv6 address having the same checksum with the original IPv4 address. V-octet: as a mark for 4rd-U address, (0x03 for bits 64~71) in IPv6 address generated by the 4rd-U CE or BR, as a means distinguishing 4rd-U traffic from native usage. The current version of this commentary focuses on the architecture issue and therefore motivation (M1), technical objectives (O1)~(O5), and technical means (T1) through (T6) are in scope. Chen Expires October 12, 2012 [Page 8] Internet-Draft 4rd-U Architectural Comments April 2012 5. Semantic Changes of 4rd-U and Potential Impacts The above technical means more or less change the well-known Internet protocol semantics. It is not the task of this commentary to judge if these changes are serious concerns or not. It is the task of it to identify what kind of semantic changes they are and to identify what potential impacts they have. Sometimes MAP-E or MAP-T semantics is also clarified when the clarification is considered helpful to share understanding. In the term of header processing semantics, MAP-E is based on [RFC2473] while MAP-T on [RFC6145]. 5.1. Semantics: existence of fragment header IPv6 semantics: Indicating the source has fragmented the datagram. RFC6145 semantics: Indicating the source allows further fragmentation, informing the IPv6-to-IPv4 translator clear the DF when making the IPv4 packet. 4rd-U semantics: Indicating nothing specific to fragmentation facts, but always being included. Impact: Always seeing fragment header is strange to middle boxes in the IPv6 domain. The system administrators of any middle box SHOULD be informed on the deployment of 4rd-U. 5.2. Semantics: IPv6 packet identification IPv6 semantics: 32-bit packet identification. RFC6145 semantics: 32-bit packet identification with, if translated from IPv4, having the original IPv4 packet identification in lower 16 bits while keeping the higher 16 bits zero. 4rd-U semantics: If translated from IPv4, having the original IPv4 packet identification in lower 16 bits while original DF in the highest bit, TTL in the bits 1~7, DSCP in bits 8~13, ECN in bits 14~15. Chen Expires October 12, 2012 [Page 9] Internet-Draft 4rd-U Architectural Comments April 2012 Impact: a. Single translation, which is supported by RFC6145, becomes incompatible in 4rd-U as the 32-bit full IPv6 identification cannot be distinguished (workaround: V-octet may help the distinguishment with need of verification.) b. Session identification in middlex boxes (firewalls) is confused because the same IPv4 datagrams might be fragmented into packets and their value of TTL and ECN may become different when entering the IPv6 domain, causing different identification in IPv6. Therefore the technical objective (O3) is not fully reached. 5.3. Semantics: Hop Limit of IPv6 IPv6 semantics: One decrement per hop. In practice (e.g., some hop-security mechanisms, like that is designed in RIPng ([RFC2080]), the generic TTL-security ([RFC5082]), which is used in both OSPFv3 and BGP4+ products), Hop Limit is initialized to 255 and receivers calculates the hop-distance from the source. RFC2473 semantics: Tunnel entry point initializes HopLimit to 255 in IPv6. Hop Limit reaching 0 indicates that tunnel exit point is unreachable due to, e.g., routing problems (count-to-infinity), treated as an link failure. Therefore the "hop limit exceeded" ICMPv6 error message generated in IPv6 domain is translated to "host unreachable". RFC6145 semantics: Tunnel entry point copies TTL to Hop Limit in IPv6. Hop Limit decrement in IPv6 domain is reflected to IPv4 TTL when packet is translated back to IPv4, treated as multi-hop paticipant in the end-to-end delivery path. Therefore the "hop limit exceeded" ICMPv6 error message generated in IPv6 domain is translated to "time to live exceeded in transit". 4rd-U semantics: The leftmost bit of IPv4 TTL is copied to the leftmost bit of Hop Limit field, while the bit 1~7 of Hop Limit is initialized to 127. 4rd-U translates ICMPv6 "hop limit exceeded" message, generated in the IPv6 domain, to "time to live exceeded" ICMPv4 message. Chen Expires October 12, 2012 [Page 10] Internet-Draft 4rd-U Architectural Comments April 2012 Impact: a. The behavior of 4rd-U translation of "hop limit exceeded" is contradictory to the behavior that IPv4 TTL is not changed through the IPv6 domain. b. The IPv6 domain maximum hop count must be limited below 127. (4rd-U draft considers it is not a problem in practice.) c. The criterion of IPv6 routing "count-to-infinity" is changed. Even if the diameter of the IPv6 domain is surely less than 127, considering the temporary route loop often happens in dynamic routing, limiting hop below 127 is actually setting an allowed diameter far less than this value. d. IPv6 normal usage of Hop Limit larger than 127 is confused. Impact involves the TTL-security mechanism for IPv6 routing, application-layer hop count constraints, etc. Host behind 4rd-U CE may generate attack packets breaking the IPv6 TTL-security mechanism, through spoofing CE's source address and applying any TTL value with leftmost bit set. Wheter other mechanism of 4rd-U (like V-octet) provides sufficient means of protection needs to be further investigated and verified. 5.4. Semantics: IP/ICMP relationship IPv4/v6 semantics: ICMP is considered a companion of IP rather than a L4 protocol. IPv4 [RFC0791] carries ICMPv4 [RFC0792] and served by ICMPv4; IPv6 [RFC2460] carries ICMPv6 [RFC4443] and served by ICMPv6. IPv4 address integrity is protected by IPv4 header checksum; IPv6 address integrity is protected by ICMPv6 checksum, which covers IPv6 pseudo-header. RFC2473 semantics: ICMPv4 is carried by IPv4 and the entire IPv4 PDU is encapsulated by IPv6. The tunneled protocol contains header checksum. As a tunnel link, the check on the tunneled protocol is never supposed to be performed in the middle of the link but only the tunnel end points. RFC6145 semantics: IPv4/ICMPv4 pair is translated to IPv6/ICMPv6 pair and vise versa. Double translation may lose semantics accuracy for some IPv4 error messages in acceptable level. Chen Expires October 12, 2012 [Page 11] Internet-Draft 4rd-U Architectural Comments April 2012 4rd-U semantics: IPv4/ICMPv4 pair is mapped to IPv6/ICMPv4 pair and vise versa; ICMPv6 generated in IPv6 domain (IPv6/ICMPv6 pair) is translated to IPv4/ICMPv4 pair, following the same way as RFC6145 does. Impact: a. IPv6 domain MUST set all filters in middle boxes to pass protocol 1 (ICMP) as IPv6 payload in order to support 4rd-U functionality. b. The IPv6 O&A tools that ensure ICMP error message being destined to original source cannot function regarding ICMPv4 as payload. This is not a mistake but doesn't satisfy the technical objective (O3). c. In the IPv6/ICMPv4 pair, both IPv6 header and ICMPv4 header doesn't contain checksum regarding addresses. Integrity protection is totally lost. Chen Expires October 12, 2012 [Page 12] Internet-Draft 4rd-U Architectural Comments April 2012 6. On Tunnel as Architectural Building Block Because 4rd-U calls it self a "tunneling" solution, it is necessary to review the concept of "tunnel" and identify what kind of 4rd-U tunnel is in the term of architectural building block in the Internet transition. In the background section of "A Scheme for an Internet Encapsulation Protocol, Version 1" ([RFC1241]), it is stated: A tunnel is essentially a Source Route that circumvents conventional routing mechanisms. It is further pointed out that the ways of making a tunnel includes source routing option, new IP option, and IP encapsulation. [RFC2475], mentioning different view of architectural building block about "tunnel", also reflects such an understanding. In this context, let's call it the tunnel of "general sense". General-sense tunnel can be a one-hop virtual link or a multi-hop participant in the delivery path. On the other hand, the community has widely accepted "tunnel", unless it is explicitly specified, as a conventional alias of the building block provided by the technology of encapsulation. Let's call that tunnel of "narrow sense". Narrow-sense tunnel, in architecture, behaves as a one-hop virtual link. With the understanding of "circumventing conventional routing mechanism", surely double translation is also a sort of tunneling in general sense, but behaves as the building block of multi-hop participant. 4rd-U is surely a sort of general-sense tunneling technology. However, when one claims 4rd-U having the advantages of tunnel in comparison to translation approaches, the wording is obviously talking about the narrow-sense tunneling. It needs further investigation to ensure if 4rd-U is qualified to be called as a tunnel in the narrow sense. Chen Expires October 12, 2012 [Page 13] Internet-Draft 4rd-U Architectural Comments April 2012 7. Summary The observation is, 4rd-U introduces 3 types of behaviors: Similar to encapsulation: - IPv4 fields DF, ToS, TTL are kept unchanged, traversing the IPv6 domain. - Middle boxes in the tunnel are unable to check if ICMPv4 message is sent to correct destination. Similar to double translation: - Without protocol layering, position of IPv4 fields are changed; - IPv4 options are removed; - Translation ICMPv6 messages generated in IPv6 domain to ICMPv4 messages with the same logic of RFC6145. Never seen in encapsulation nor in double translation: - IPv6 carries ICMPv4 directly; - TTL leftmost bit is copied to Hop Limit leftmost bit. When setting the testing scenarios, it is recommended that the above semantics changes and behaviors are fully considered. It is also expected that the designer, implementator and tester provides comprehensive evidence either to ensure those changes as well as new behaviors are not of problem in practice or to clarify the boundary conditions, with which as prerequisites 4rd-U can work safely and reach its design objectives. Chen Expires October 12, 2012 [Page 14] Internet-Draft 4rd-U Architectural Comments April 2012 8. IANA Considerations This specification does not require any IANA actions. Chen Expires October 12, 2012 [Page 15] Internet-Draft 4rd-U Architectural Comments April 2012 9. Security Considerations There are no new security considerations pertaining to this document. Chen Expires October 12, 2012 [Page 16] Internet-Draft 4rd-U Architectural Comments April 2012 10. References [I-D.despres-softwire-4rd-u] Despres, R., Penno, R., Lee, Y., Chen, G., and J. Qin, "IPv4 Residual Deployment via IPv6 - Unified Solution (4rd)", draft-despres-softwire-4rd-u-06 (work in progress), March 2012. [I-D.mdt-softwire-map-dhcp-option] Mrugalski, T., Boucadair, M., Deng, X., Troan, O., and C. Bao, "DHCPv6 Options for Mapping of Address and Port", draft-mdt-softwire-map-dhcp-option-02 (work in progress), January 2012. [I-D.mdt-softwire-map-encapsulation] Troan, O., Matsushima, S., and T. Murakami, "MAP Encapsulation (MAP-E) - specification", draft-mdt-softwire-map-encapsulation-00 (work in progress), January 2012. [I-D.mdt-softwire-map-translation] Bao, C., Li, X., Zhai, Y., Murakami, T., and W. Dec, "MAP Translation (MAP-T) - specification", draft-mdt-softwire-map-translation-01 (work in progress), March 2012. [I-D.mdt-softwire-mapping-address-and-port] Bao, C., Troan, O., Matsushima, S., Murakami, T., and X. Li, "Mapping of Address and Port (MAP)", draft-mdt-softwire-mapping-address-and-port-03 (work in progress), January 2012. [IMC07] John, W. and S. Tafvlin, "Analysis of Internet Backbone Traffic and Header Anomalies observed", Proc. of IMC 2007 , Aug 2007, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC1241] Woodburn, R. and D. Mills, "Scheme for an internet encapsulation protocol: Version 1", RFC 1241, July 1991. [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997. Chen Expires October 12, 2012 [Page 17] Internet-Draft 4rd-U Architectural Comments April 2012 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [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. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. Chen Expires October 12, 2012 [Page 18] Internet-Draft 4rd-U Architectural Comments April 2012 Author's Address Maoke Chen FreeBit Co., Ltd. 13F E-space Tower, Maruyama-cho 3-6 Shibuya-ku, Tokyo 150-0044 Japan Email: fibrib@gmail.com Chen Expires October 12, 2012 [Page 19]