idnits 2.17.1 draft-anderson-v6ops-siit-dc-2xlat-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.anderson-v6ops-siit-dc]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 15, 2014) is 3505 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-anderson-v6ops-siit-dc-00 -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations T. Anderson 3 Internet-Draft Redpill Linpro 4 Intended status: Standards Track September 15, 2014 5 Expires: March 19, 2015 7 SIIT-DC: Dual Translation Mode 8 draft-anderson-v6ops-siit-dc-2xlat-00 10 Abstract 12 This document describes an extension of the SIIT-DC 13 [I-D.anderson-v6ops-siit-dc] architecture, which allows applications 14 that are incompatible with IPv6, SIIT-DC and/or Network Address 15 Translation in general to operate correctly in an SIIT-DC 16 environment. This is accomplished by introducing a new component 17 called a SIIT-DC Host Agent, which reverses the translations made by 18 an SIIT-DC Gateway. The application is thus provided with seemingly 19 native IPv4 connectivity. 21 The reader is expected to be familiar with the SIIT-DC architecture 22 described in [I-D.anderson-v6ops-siit-dc]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 19, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. SIIT-DC Host Agent Specification . . . . . . . . . . . . . . 4 61 4. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 62 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 6 63 5.1. IPv6 Path MTU . . . . . . . . . . . . . . . . . . . . . . 6 64 5.2. IPv4 MTU . . . . . . . . . . . . . . . . . . . . . . . . 6 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 66 7. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 9.1. Address Spoofing . . . . . . . . . . . . . . . . . . . . 7 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 10.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 SIIT-DC [I-D.anderson-v6ops-siit-dc] describes an architecture where 78 IPv4-only users can access IPv6-only services through a stateless 79 translation gateway. However, this only works for applications that 80 are compatible with Network Address Translation (NAT), due to the 81 fact that the SIIT-DC Gateway will rewrite the addresses in the IP 82 header as part of the translation process. SIIT-DC will also fail to 83 work correctly for applications that make use of legacy IPv4-only 84 socket calls. 86 This document remedies this problem by defining an extension to SIIT- 87 DC. Translations performed by the SIIT-DC Gateway will also be done 88 in reverse by an SIIT-DC Host Agent running on the server. The 89 resulting IPv4 packets are then passed to the application. This way, 90 the application will be able to use legacy IPv4-only socket calls and 91 /or include references to its own IPv4 address in the application 92 payload, while maintaining correct operation. 94 The approach is heavily inspired by and very similar to 464XLAT 95 [RFC6877]. The SIIT-DC Host Agent described in this document is 96 almost identical to the CLAT component in 464XLAT, except for the 97 fact that it will be located on a server, rather than on the 98 customer-side node. Furthermore, an SIIT-DC Host Agent uses 99 statically configured public IP addresses, whereas a 464XLAT CLAT 100 uses a dynamic IPv6 address and a private IPv4 address. The SIIT-DC 101 Gateway described in [I-D.anderson-v6ops-siit-dc] is used instead of 102 the PLAT described by 464XLAT. 104 2. Terminology 106 This document makes use of the following terms: 108 IPv4 Service Address A public IPv4 address with which IPv4-only 109 clients will communicate. This communication will be translated 110 to IPv6 by the SIIT-DC Gateway. 112 IPv6 Service Address A public IPv6 address assigned to a server or 113 application in the IPv6 network. IPv6-only and dual stacked 114 clients communicates with this address directly without invoking 115 SIIT-DC. IPv4-only clients also communicate with this address 116 through the SIIT-DC Gateway and via an IPv4 Service Address. 118 SIIT-DC Host Agent A logical function very similar to an SIIT-DC 119 Gateway that resides on a server and provides virtual IPv4 120 connectivity to applications, by performing 121 [I-D.anderson-v6ops-siit-dc] translation on packets passing 122 through it. See Section 3. 124 SIIT-DC Gateway A device or a logical function that translates 125 between IPv4 and IPv6 in accordance with 126 [I-D.anderson-v6ops-siit-dc]. 128 Static Address Mapping A bi-directional mapping between an IPv4 129 Service Address and an IPv6 Service Address configured in the 130 SIIT-DC Gateway. When translating between IPv4 and IPv6, the 131 SIIT-DC Gateway changes the adddress fields in the translated 132 packet's IP header according to any matching Static Address 133 Mapping. 135 Translation Prefix An IPv6 prefix into which the entire IPv4 address 136 space is mapped. This prefix is routed to the SIIT-DC Gateway's 137 IPv6 interface. It is either an Network-Specific Prefix or a 138 Well-Known Prefix as specified in [RFC6052]. When translating 139 between IPv4 and IPv6, the SIIT-DC Gateway prepends or strips the 140 Translation Prefix from the address fields in the translated 141 packet's IP header, unless a Static Address Mapping exists for the 142 IP address in question. 144 3. SIIT-DC Host Agent Specification 146 The SIIT-DC Host Agent runs on the servers hosting application which 147 do not work correctly with the SIIT-DC architecture as specified by 148 [I-D.anderson-v6ops-siit-dc]. Its task is the performing the exact 149 same packet translation as the SIIT-DC Gateway, only in reverse. It 150 therefore shares the same implementation requirements as the SIIT-DC 151 Gateway defined in Section 4 of [I-D.anderson-v6ops-siit-dc], with 152 one exception: The SIIT-DC Host Agent is not required to support 153 configuring an arbitrary number of Static Address Mappings, but it 154 must support at least one. 156 The SIIT-DC Host Agent must be configured with a Static Address 157 Mapping that corresponds exactly with the same mapping found on the 158 SIIT-DC Gateway. The IPv4 address of the Static Address Mapping 159 (i.e., the IPv4 Service Address) must be configured on a virtual 160 network interface which applications running on the server can bind 161 to, and the server is expected to install a default IPv4 route 162 poining to this virtual IPv4 interface. The IPv6 address of the 163 Static Address Mapping must be a secondary address that is routed to 164 the server by the IPv6 network. The server must forward all packets 165 it receives destined for this IPv6 address to the SIIT-DC Host Agent. 167 4. Architectural Overview 169 The following figure shows how an application (that is presumably 170 incompatible with standard SIIT-DC) is being made available to the 171 IPv4 Internet on the IPv4 address 192.0.2.4. The application will be 172 able to know that this is its local address and thus be able to 173 provide correct references to it in application payload. 175 The figure also shows how the same application is available over IPv6 176 on its IPv6 Service Address 2001:db8:12:34::3. This is included in 177 order to illustrate how native IPv6 connectivity is not impacted by 178 the SIIT-DC Host Agent, and also to illustrate how the address 179 assigned to the SIIT-DC Host Agent (2001:db8:12:34::4) is separate 180 from the primary IPv6 address of the server. It is however important 181 to note that the application in question does not have to be dual- 182 stack capable at all. IPv4-only applications would also be able to 183 operate behind a SIIT-DC Host Agent in the exact same manner. 185 Note that the figure below could be considered a more detailed view 186 of Customer A's FTP server from the example topology figure in 187 Appendix A of I-D.anderson-v6ops-siit-dc 188 [I-D.anderson-v6ops-siit-dc]. Both figures intentionally use the 189 exact same example IP addresses and prefixes. 191 SIIT-DC Host Agent Architecture 193 +-------------------+ +----------------+ 194 | IPv6-capable user | | IPv4-only user | 195 | ================= | | ============== | 196 | | | | 197 +-<2001:db8::ab:cd>-+ +-<203.0.113.50>-+ 198 | | 199 | | 200 (the IPv6 internet) (the IPv4 Internet) 201 | | 202 | | 203 | +------------------<192.0.2.0/24>-+ 204 | | | 205 | | SIIT-DC Gateway | 206 | | =============== | 207 | | | 208 | | Translation Prefix: | 209 | | 2001:db8:46::/96 | 210 | | | 211 | | Static Address Mapping: | 212 | | 192.0.2.4 <=> 2001:db8:12:34::4 | 213 | | | 214 | +--------------<2001:db8:46::/96>-+ 215 | | 216 | | 217 (the IPv6-only data centre network) 218 | | 219 | | 220 +--<2001:db8:12:34::3>-------<2001:db8:12:34::4>---+ 221 | | | | 222 | | IPv6-only server | | 223 | | ================ | | 224 | | | | 225 | | +-------------<2001:db8:12:34::4>-+ | 226 | | | | | 227 | | | SIIT-DC Host Agent | | 228 | | | ================== | | 229 | | | | | 230 | | | Translation Prefix: | | 231 | | | 2001:db8:46::/96 | | 232 | | | | | 233 | | | Static Address Mapping: | | 234 | | | 192.0.2.4 <=> 2001:db8:12:34::4 | | 235 | | | | | 236 | | +---------------------<192.0.2.4>-+ | 237 | | | | 238 | | | | 239 | +-[2001:db8:12:34::3]--------------[192.0.2.4]-+ | 240 | | AF_INET6 AF_INET | | 241 | | | | 242 | | Dual-stacked application | | 243 | | | | 244 | +----------------------------------------------+ | 245 +--------------------------------------------------+ 247 Figure 1 249 5. Deployment Considerations 251 5.1. IPv6 Path MTU 253 The IPv6 Path MTU between the SIIT-DC Host Agent and the SIIT-DC 254 Gateway will typically be larger than the default value defined in 255 Section 4 of [RFC6145] (1280), as it will typically contained within 256 a single administrative domain. Therefore, it is recommended that 257 the IPv6 Path MTU configured in the SIIT-DC Host Agent is raised 258 accordingly. It is RECOMMENDED that the SIIT-DC Host Agent and the 259 SIIT-DC Gateway use identical configured IPv6 Path MTU values. 261 5.2. IPv4 MTU 263 In order to avoid fragmentation, it is RECOMMENDED that the virtual 264 IPv4 interface is configured with an MTU value identical to the 265 configured IPv6 Path MTU - 20. This ensures that the application may 266 do its part in avoiding IP-level fragmentation from occurring, e.g., 267 by segmenting/fragmenting outbound packets at the application layer, 268 and advertising the maximum size its peer may use for inbound packets 269 (e.g., through the use of the TCP MSS option). 271 6. Acknowledgements 273 The author would like to especially thank the authors of 464XLAT 274 [RFC6877]: Masataka Mawatari, Masanobu Kawashima, and Cameron Byrne. 275 The architecture described by this document is merely an adaptation 276 of their work to a data centre environment, and could not have 277 happened without them. 279 The author would like also to thank the following individuals for 280 their contributions, suggestions, corrections, and criticisms: Fred 281 Baker, Tobias Brox, [YOUR NAME GOES HERE]. 283 7. Requirements Language 285 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 286 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 287 document are to be interpreted as described in [RFC2119]. 289 8. IANA Considerations 291 This draft makes no request of the IANA. The RFC Editor may remove 292 this section prior to publication. 294 9. Security Considerations 296 This section discusses security considerations specific to the use of 297 a SIIT-DC Host Agent. See the Security Considerations in I-D 298 .anderson-v6ops-siit-dc [I-D.anderson-v6ops-siit-dc] for additional 299 security considerations applicable to the SIIT-DC architecture in 300 general. 302 9.1. Address Spoofing 304 If the SIIT-DC Host Agent receives an IPv4 packet from the 305 application from a different source address than the one it has a 306 Static Address Mapping for, the both the source and destination 307 addresses will be rewritten according to [RFC6052]. After undergoing 308 the reverse translation in the SIIT-DC Gateway, the resulting IPv4 309 packet routed to the IPv4 network will have a spoofed IPv4 source 310 address. The SIIT-DC Host Agent should therefore ensure that ingress 311 filtering (cf. BCP38 [RFC2827]) is used on the SIIT-DC Host Agent's 312 IPv4 interface, so that such packets are immediately discarded. 314 If the SIIT-DC Host Agent receives an IPv6 packet with both the 315 source and destination address equal to the one it has a Static 316 Address Mapping for, the resulting packet would appear to the 317 application as locally generated, as both the source address and the 318 destination address will be the same address as the one configured on 319 the virtual IPv4 interface. This could trick the application into 320 thinking this packet came from a trusted source, and give elevated 321 privileges accordingly. To prevent this, the SIIT-DC Host Agent 322 should discard any received IPv6 packets that have a source address 323 that is equal either to either the IPv4 (after undergoing [RFC6052] 324 translation) or the IPv6 address in the Static Address Mapping. 326 10. References 328 10.1. Normative References 330 [I-D.anderson-v6ops-siit-dc] 331 Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation in 332 IPv6 Data Centre Environments", draft-anderson-v6ops-siit- 333 dc-00 (work in progress), September 2014. 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, March 1997. 338 10.2. Informative References 340 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 341 Defeating Denial of Service Attacks which employ IP Source 342 Address Spoofing", BCP 38, RFC 2827, May 2000. 344 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 345 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 346 October 2010. 348 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 349 Algorithm", RFC 6145, April 2011. 351 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 352 Combination of Stateful and Stateless Translation", RFC 353 6877, April 2013. 355 Author's Address 357 Tore Anderson 358 Redpill Linpro 359 Vitaminveien 1A 360 0485 Oslo 361 NORWAY 363 Phone: +47 959 31 212 364 Email: tore@redpill-linpro.com