idnits 2.17.1 draft-chen-host-ipv6-ps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2009) is 5401 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-00 ** Obsolete normative reference: RFC 2767 (Obsoleted by RFC 6535) ** Obsolete normative reference: RFC 3338 (Obsoleted by RFC 6535) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Chen 3 Internet-Draft B. Zhou 4 Intended status: Informational China Mobile 5 Expires: January 7, 2010 July 6, 2009 7 Host-based Translation Problem Statement 8 draft-chen-host-ipv6-ps-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on January 7, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 When operators start to customize user terminals, host-based IPv6 57 translation will be feasible. Host-based translation should overcome 58 single-point failure problems and support various connections between 59 two IP families networks simultaneously. In addition, legacy IPv4 60 applications should not be modified. This document will discuss 61 host-based translation applicable scenarios and corresponding issues. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Host-based translation scenarios and problems . . . . . . . . . 3 67 2.1. Host-based translation scenarios . . . . . . . . . . . . . 3 68 2.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 71 5. Normative References . . . . . . . . . . . . . . . . . . . . . 5 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 74 1. Introduction 76 Current network is mostly depending on IPv4. And, several 77 sophisticated technologies have been proposed to prolong the IPv4 78 lifetime, such as NAPT, A+P[A+P] . Although these solutions could 79 alleviate IPv4 depletion pressure in a short term, the transition 80 from IPv4 to IPv6 is still a steady trend of network development. 82 Technical solutions of IPv6 transition could be divided into three 83 categories, namely dual-stack, tunneling and translation technology. 85 Dual-stack hosts can communicate with both the IPv4 and IPv6 hosts, 86 but it can not help to resolve the IPv4 address exhaustion problems. 87 The tunneling technology can connect IPv4 networks across IPv6-only 88 networks and IPv6 networks across IPv4-only networks, thus one IP 89 family communication is transparent with another IP family. 91 The translation technology can help the communications between two 92 address families. With regard to whether deploy translator on hosts 93 or networks, the majority solutions would like to choose the latter 94 since modifications on a numerous hosts were treated as not easy 95 works. However, host-based translation schemes would progress more 96 easily in recent time, since more and more operators start to 97 customize hosts for their subscribers. 99 In this document, host-based translation scenarios and underlying 100 problems have been described. 102 2. Host-based translation scenarios and problems 104 2.1. Host-based translation scenarios 106 Figure 1 shows host-based translation scenarios. Translator modules 107 have been deployed on H1 and H3 located in IPv6 only network. And, 108 both conventional IPv4 applications and IPv6 applications have been 109 installed. H2 is legacy IPv4 host located in IPv4 site. 111 With regard to this scenario, H1 and H3 might maintain following 112 service connections simultaneously. 114 o case 1: H1 and H4 initiate a service call with H2 using a IPv4 115 application 117 o case 2: H1 initiates a service all with the IPv6 application of H3 118 using a IPv4 application 120 o case 3: H3 initiates a service call with H2 using a IPv6 121 application 123 o case 4: H1 initiates a service call with the IPv4 application of 124 H3 using a IPv4 application 126 +-----------------------------+ +--------------------+ 127 |IPv6 site 4/6 | | IPv4 site | 128 | +--------+ | | | 129 | | H1 | | | | 130 | +--------+ | | | 131 | | | | | 132 | 4/6 +--------+ | | | 133 |+-------+ | Access | +--------+ |+----------+ +----+| 134 || H3 |--| Router |-- | NAT |---|| Internet |--| H2 || 135 |+-------+ +--------+ +--------+ |+----------+ +----+| 136 | | | | | 4 | 137 | +--------+ | | +--------+ | 138 | | DNS1 | | | | DNS2 | | 139 | +--------+ | | +--------+ | 140 | AAAA | | A | 141 +-----------------------------+ +--------------------+ 143 Figure 1 145 2.2. Problems 147 From individual case point-of-view, dual-stack-lite[DS-Lite] can 148 support case 1, and BIA [RFC3338] or BIS [RFC2767] can support the 149 case 2, and NAT64[NAT64] can support case 3. There are no solutions 150 to perform case 4. 152 According to the analysis, According to the analysis, existing 153 solution can!_t satisfy the demands of maintaining above all 154 potential communications in the 4/6 host at one time. Furthermore, 155 following problems should be considered. 157 o It is hard to modify numerous conventional IPv4 applications, when 158 the hosts only have an IPv6 connection 160 o The hosts located in IPv6 site usually do not initiate query to 161 DNS4 server, where IPv4 peer record is stored 163 o The hosts usually do not identify peer application type, thus 164 translation handling can not be performed correctly 166 3. IANA Considerations 168 This memo includes no request to IANA. 170 4. Security Considerations 172 It needs to be further identified. 174 5. Normative References 176 [A+P] Bush, R., "The A+P Approach to the IPv4 Address Shortage", 177 draft-ymbk-aplusp-03 (work in progress), March 2009. 179 [DS-Lite] Durand, A., "Dual-stack lite broadband deployments post 180 IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite-00 181 (work in progress), March 2009. 183 [NAT64] Bagnulo, M., "NAT64: Network Address and Protocol 184 Translation from IPv6 Clients to IPv4 Servers", 185 draft-bagnulo-behave-nat64-03.txt (work in progress), 186 March 2009. 188 [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack 189 Hosts using the "Bump-In-the-Stack" Technique (BIS)", 190 RFC 2767, February 2000. 192 [RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. 193 Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", 194 RFC 3338, October 2002. 196 Authors' Addresses 198 Gang Chen 199 China Mobile 200 53A,Xibianmennei Ave., 201 Xuanwu District, 202 Beijing 100053 203 China 205 Email: phdgang@gmail.com 206 Bo Zhou 207 China Mobile 208 53A,Xibianmennei Ave., 209 Xuanwu District, 210 Beijing 100053 211 China 213 Email: zhouboyj@chinamobile.com