idnits 2.17.1 draft-rfvlb-behave-v6-content-for-v4-clients-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 15, 2013) is 3928 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-sun-behave-v4tov6-00 ** Obsolete normative reference: RFC 2766 (Obsoleted by RFC 4966) ** Downref: Normative reference to an Informational RFC: RFC 4966 ** Downref: Normative reference to an Informational RFC: RFC 6144 ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behave WG B. Rajtar 3 Internet-Draft Hrvatski Telekom 4 Intended status: Standards Track I. Farrer 5 Expires: January 16, 2014 Deutsche Telekom AG 6 A. Vizdal 7 T-Mobile CZ 8 X. Li 9 C. Bao 10 CERNET Center/Tsinghua University 11 July 15, 2013 13 Framework for accessing IPv6 content for IPv4-only clients 14 draft-rfvlb-behave-v6-content-for-v4-clients-01 16 Abstract 18 With the expansion of IPv6 usage and content available on IPv6, it is 19 important that clients with legacy (i.e. non IPv6-capable) operating 20 systems are able to access such content. 22 This document describes a method for achieving this, including how 23 the method could be implemented in real-world scenarios. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 16, 2014. 48 Copyright Notice 50 Copyright (c) 2013 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Solution Requirements . . . . . . . . . . . . . . . . . . 2 67 1.2. Covered Scenarios . . . . . . . . . . . . . . . . . . . . 3 68 1.3. Functional elements . . . . . . . . . . . . . . . . . . . 3 69 2. Algorithm Description . . . . . . . . . . . . . . . . . . . . 3 70 2.1. Flow diagram . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Usage scenarios . . . . . . . . . . . . . . . . . . . . . . . 5 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 75 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 78 1. Introduction 80 At the time of writing, IPv6 is still not widely deployed. There are 81 several reasons for this, one of which is that IPv4-only operating 82 systems are still commonplace with end-users and account for a large 83 fraction of overall Internet traffic. 85 With the growth of IPv6 traffic, servers supporting only IPv6 are 86 appearing on the Internet. An approach for enabling and IPv4-only 87 clients to access this content is described below. 89 1.1. Solution Requirements 91 To clarify when this approach is applicable, the following 92 requirements can be named: 94 1. The content MUST be reachable through IPv6, i.e. the server on 95 which the content is stored must have a valid IPv6 address and a 96 working IPv6 stack. 98 2. The server hosting the content MUST have a valid AAAA record 100 3. The client MUST support IPv4 only. The other alternative is also 101 that it supports IPv6, but for some reason uses only IPv4 to 102 access content on the Internet. 104 4. Client's DNS queries MUST be resolved by a dedicated appliance, 105 i.e. a caching nameserver. 107 5. All traffic between the client and the server MUST be routed 108 through a device capable of performing translation between IPv4 109 and IPv6, as described in [RFC6145] and [RFC6052]. 111 It is feasible that requirements (4) and (5) can be combined in one 112 device and managed by the service provider.That would simplify 113 operations and remove the need for a control-plane protocol between 114 the two devices. 116 1.2. Covered Scenarios 118 [RFC6144] describes multiple scenarios for IPv4/IPv6 translation. 119 This document is mainly concerned with Scenario 4: An IPv4 Network to 120 the IPv6 Internet, but is also applicable to Scenario 6 (An IPv4 121 Network to an IPv6 Network). This scenario is not covered in this 122 memo and can be elaborated in future documents, as necessary. 123 Scenario 2, which faces similar challenges (The IPv4 Internet to an 124 IPv6 Network), is covered by [I-D.draft-sun-behave-v4tov6-00]. 126 1.3. Functional elements 128 Client User end-device, typically a personal computer or similar. 130 DNS proxy Caching nameserver which proxies DNS queries from the 131 client. 133 NAT46 translator Translation device which translates incoming IPv4 134 traffic. 136 IPv6-only server Device which holds content on an IPv6-only network. 138 2. Algorithm Description 140 This section describes how the algorithm works and the roles of every 141 functional element. The steps are in cronological order, and display 142 the scenario when the IPv4 client initiates a request for 143 ipv6.example.com which is running on an IPv6-only server. 145 1. The customer types in "ipv6.example.com" into his web browser and 146 initiaties the request for the web page. 148 2. The client operating system initiates a DNS query for 149 "ipv6.example.com". Since the client uses IPv4, the query is for 150 an A record. 152 3. The DNS proxy receives the A record query and assumes the client 153 is not IPv6 capable. Therefore, it initiates a DNS query for A 154 and AAAA records for "ipv6.example.com" to the authorative DNS 155 server. 157 4. If a DNS response is received with only an AAAA record, the DNS 158 proxy assumes that the server is IPv6-only. (In case the proxy 159 receives both A or AAAA records, or just an A record, the A 160 record is returned to the client and the process ends here.) 162 5. As a response to the client, the proxy returns a fake A record 163 for "ipv6.example.com" pointing at an un-used IPv4 address from 164 the private address space (as described in [RFC1918]). 166 6. The private IPv4 address and the resolved IPv6 address of 167 "ipv6.example.com" must be kept in the translation table of the 168 NAT46 translator. The time the translation would stay active in 169 the table would be equal to the TTL field of the DNS response. 170 How the DNS-related information is conveyed from the DNS proxy to 171 the translator is out of the scope of this document. In the case 172 the translator and the DNS proxy are functions of the same 173 device, the logic is simplified. 175 7. All IPv4 traffic from the client to "ipv6.example.com" will be 176 translated to IPv6 as described in [RFC6145]. Unlike NAT-PT 177 described in [RFC2766] (moved to Historic Status by [RFC4966]), 178 the translation is a learned state and not a session triggered 179 state. The destination address of the translated IPv6 packet 180 will be the resolved AAAA record of "ipv6.example.com", while the 181 source IPv6 address will be created according to [RFC6052]. The 182 IPv6 prefix used to create the source IPv6 address must be 183 globally unique and allocated to the device. If there are more 184 IPv6 prefixes on the device, defining which one will be used is 185 out of the scope of this document. The IPv4 address used to 186 create the source IPv6 address is the address of the client. 188 8. Return IPv6 traffic will be translated by the same device as the 189 outgoing traffic, using IPv6 to IPv4 translation analogous to the 190 previous step. The source IPv4 address will be the private IPv4 191 address given by the DNS proxy to the client, while the 192 destination IPv4 address would be the one of the client. 194 2.1. Flow diagram 196 In this example, the client is located behind a home gateway and is 197 delegated an IPv4 address of 192.168.1.3. The home gateway is acting 198 as a DNS proxy and as a NAT46 translator. 200 +-----------+ +----------------+ +-----------+ +------------+ 201 | | | (Home Gateway) | | DNS | | ipv6. | 202 | Client | | DNS proxy/ | |authorative| |example.com | 203 |192.168.1.3| |NAT46 translator| | server | |2000:db9::1 | 204 | | | 2000:db8::1 | | | | | 205 +----------- +----------------+ +-----------+ +------------+ 206 | DNS A query for | | | 207 | "ipv6.example.com" | | | 208 |--------------------->|DNS A and AAAA query | | 209 | |for "ipv6.example.com"| | 210 | |--------------------->| | 211 | | DNS AAAA response | | 212 | |for "ipv6.example.com"| | 213 |DNS A response: |<---------------------| | 214 |""ipv6.example.com" | | | 215 |is located on 10.1.1.1| | 216 |<---------------------| | 217 | IPv4 SA:192.168.1.3 | IPv6 SA:2000:db8::192.168.1.3 | 218 | DA:10.1.1.1 | DA:2000:db9::1 | 219 |--------------------->|-------------------------------->| 220 | IPv4 SA:10.1.1.1 | IPv6 SA:2000:db9::1 | 221 | DA:192.168.1.3 | DA:2000:db8::192.168.1.3 | 222 |<---------------------|<--------------------------------| 223 | | | 225 3. Usage scenarios 227 The typical scenario where such a solution can be used is the home 228 network. The customer can have a broadband service with access to 229 IPv6 Internet, but uses an IPv4-only client. The DNS proxy and the 230 translation device would in that case be the home gateway, which 231 would handle the decision-making process, as well as the translation. 233 However, other scenarios can also be foreseable, such as mobile 234 access, business customers, etc. It's applicable to all scenarios 235 where a DNS proxy is used, as well as a default gateway which can act 236 as a translation device. 238 4. IANA Considerations 240 This document makes no request of IANA. 242 Note to RFC Editor: this section may be removed on publication as an 243 RFC. 245 5. Security Considerations 247 6. Acknowledgements 249 7. Normative References 251 [I-D.draft-sun-behave-v4tov6-00] 252 , . 254 [RFC1918] , "Address Allocation for Private Internets", . 256 [RFC2119] , "Key words for use in RFCs to Indicate Requirement 257 Levels", . 259 [RFC2766] , "Network Address Translation - Protocol Translation 260 (NAT-PT)", . 262 [RFC4966] , "Reasons to Move the Network Address Translator - 263 Protocol Translator (NAT-PT) to Historic Status", . 265 [RFC6052] , "IPv6 Addressing of IPv4/IPv6 Translators", . 267 [RFC6144] , "Framework for IPv4/IPv6 Translation", . 269 [RFC6145] , "IP/ICMP Translation Algorithm", . 271 Authors' Addresses 273 Branimir Rajtar 274 Hrvatski Telekom 275 Zagreb 276 Croatia 278 Email: branimir.rajtar@t.ht.hr 279 Ian Farrer 280 Deutsche Telekom AG 281 Bonn 282 Germany 284 Email: ian.farrer@telekom.de 286 Ales Vizdal 287 T-Mobile CZ 288 Prague 289 Czech Republic 291 Email: ales.vizdal@t-mobile.cz 293 Xing Li 294 CERNET Center/Tsinghua University 295 Beijing 296 China 298 Email: xing@cernet.edu.cn 300 Congxiao Bao 301 CERNET Center/Tsinghua University 302 Beijing 303 China 305 Email: congxiao@cernet.edu.cn