idnits 2.17.1 draft-carpenter-shanti-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 704. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 7, 2007) is 6013 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-09 == Outdated reference: A later version (-03) exists of draft-woodyatt-ald-01 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Experimental November 7, 2007 5 Expires: May 10, 2008 7 Shimmed IPv4/IPv6 Address Network Translation Interface (SHANTI) 8 draft-carpenter-shanti-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 10, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 There is a pragmatic need for a packet-level translation mechanism 42 between IPv4 and IPv6, for scenarios where no other mode of IPv4 to 43 IPv6 interworking is possible. The mechanism defined here uses a 44 shim in both the translator and the IPv6 host to mitigate the 45 problems introduced by stateless translation. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.2. Summary of operation . . . . . . . . . . . . . . . . . . . 3 52 1.3. Requirements notation . . . . . . . . . . . . . . . . . . 5 53 2. Scenario of addresses and ports . . . . . . . . . . . . . . . 5 54 3. General walkthroughs . . . . . . . . . . . . . . . . . . . . . 8 55 4. Placement of the shim . . . . . . . . . . . . . . . . . . . . 9 56 5. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 6. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 58 7. Unresolved issues . . . . . . . . . . . . . . . . . . . . . . 10 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 61 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 62 11. Change log [RFC Editor: please remove this section] . . . . . 14 63 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 65 12.2. Informative References . . . . . . . . . . . . . . . . . . 14 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 Intellectual Property and Copyright Statements . . . . . . . . . . 16 69 Dedication 71 A few days before his tragic death, itojun (Jun-ichiro Itoh Hagino) 72 responded to a comment that "I absolutely don't like to see ::FFFF/96 73 on the wire" by writing "then we'd have to deprecate SIIT at least. 74 still, you cannot be sure that ::ffff:0:0/96 are not on the wire." 75 This directly inspired the idea behind SHANTI. This proposal is 76 dedicated to itojun. 78 1. Introduction 80 1.1. Disclaimer 82 This proposal is incomplete. It is posted to seek comments on 83 plausibility; much more work is needed to make it implementable. 85 1.2. Summary of operation 87 There has long been a defined mechanism for stateless translation 88 betweeen IPv4 and IPv6 packet formats, named SIIT [RFC2765]. Its 89 intended use is any scenario where dual stack coexistence between 90 IPv4 and IPv6, possibly accompanied by dual stack application level 91 proxies, is insufficient. In the most stringent case, this will 92 occur when communication is needed between unmodified ("legacy") IPv4 93 hosts and IPv6-only hosts that have no IPv4 code, and no dual stack 94 proxy is available for the application protocol of interest. Thus 95 the scenario of interest is one where an IPv6-only host is modified 96 (with the inclusion of a shim and DNS resolver changes) to allow it 97 to leverage a separate device (the translator) to access IPv4-only 98 sections of the Internet. 100 The previously proposed solution for this requirement, NAT-PT 101 [RFC2766], has known issues and has been deprecated [RFC4966]. The 102 present proposal does not resolve all of those issues; a later 103 section will identify the issues believed to remain open. This 104 proposal aims to resolve those issues that can be handled if the IPv6 105 protocol stack communicating with a translator can obtain information 106 about the translation. The objectives are to ensure that 107 o from the IPv4 host's point of view, nothing is worse than in the 108 case of an IPv4-to-IPv4 translation 109 o from the IPv6 host's point of view, no special code is generally 110 required in the transport layer or above. However, information 111 about the translation is available in the IPv6 host's network 112 stack, as needed. This is the crucial difference from NAT-PT. 113 o IPv6 routing is not affected in any way, and there is no risk of 114 importing "entropy" from the IPv4 routing tables into IPv6. 116 To achieve these goals, a shim is inserted in the protocol stack at 117 both the IPv6 host and at the translator. Its objective is to allow 118 the IPv6 stack at the host to be aware of the presence of the 119 translator, of the addresses involved in the translation, and of any 120 other information known by the translator that may be of value to the 121 IPv6 host. A shim model is chosen, as in SHIM6 122 [I-D.ietf-shim6-proto], so that upper layer protocols (ULPs) have no 123 need to be aware of anything unusual. The mechanism is known as 124 SHimmed Address Network Translation Interface (SHANTI, which means 125 "inner peace" in Sanskrit). 127 As in SHIM6, ULPs are presented with an upper layer identifier (ULID) 128 in the form of an IPv6 address which is independent of any 129 manipulation of addresses in the shim or translator. 131 Additionally, packets that flow over the IPv6 network all have quite 132 normal IPv6 addresses, with no topological constraints. The same 133 applies on the IPv4 side. This means that the translator may be 134 positioned anywhere that is operationally convenient (e.g., on the 135 IPv6 host's own site, within its ISP's network, or much closer to the 136 IPv4 host). The only requirement is that there exists an IPv6 path 137 between the IPv6 host and the translator, and an IPv4 path between 138 the translator and the IPv4 host. 140 There are two cases to consider: 141 1. A new flow of packets is started by an IPv6 host. In this case, 142 the principle of operation is that the shim in the IPv6 host 143 exchanges information with the shim in the translator before the 144 first packet of the new flow is released from the sending buffer. 145 The result of the information exchange is that the shim knows 146 what addresses and ports will be used for both IPv6 and IPv4, and 147 can appropriately manipulate the packets before sending them to 148 the translator via IPv6. 149 2. A new flow of packets is started by an IPv4 host. In this case, 150 the principle of operation is that the shim in the translator 151 sends the first packet to the IPv6 host with a shim header 152 defining what addresses and ports will be used for both IPv6 and 153 IPv4. The shim in the IPv6 host can appropriately manipulate the 154 packets before delivering them to the upper layer protocol. 156 In neither case is any IPv4 component aware of any difference from a 157 normal IPv4 packet stream. 159 The reader is assumed to have a general understanding of SHIM6. 160 Although this early draft does not assume that the SHIM6 mechanisms 161 defined in [I-D.ietf-shim6-proto] would be used unchanged, they form 162 a proof of concept for the type of communication required between two 163 network-layer shims. 165 It should be noted that this mechanism adds complexity to an IPv6- 166 only host. This has to be balanced against the complexity of a dual- 167 stack host. In this model, no residual IPv4 code is needed in the 168 IPv6 host. The shim has to handle the rewriting of addresses and 169 port numbers, but nothing else. 171 1.3. Requirements notation 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 177 2. Scenario of addresses and ports 179 Consider an IPv6-only host X and and IPv4-only host Y. 181 Let A(x) be an IPv6 address for X, and let a(y) be an IPv4 address 182 for Y. Let the port in use at X be P(x) and at Y be P(y). 184 We will observe later that it is irrelevant whether a(y) is 185 translated by an IPv4 NAT, and whether P(y) is translated by an IPv4 186 NAPT. 188 Additionally, consider a translator T between X and Y. On the IPv6 189 side it has address A(t) and on the IPv4 side it has address a(t). 190 If port translation is in effect, P(x) will become P(tx) on the IPv4 191 side. We will observe later that the A(t) address can be chosen from 192 an address pool. We cannot assume that a(t) can be chosen from a 193 pool, which is why port translation will be needed. 195 Thus A() is always an IPv6 address and a() is always an IPv4 address. 197 A diagram of the solution follows: 199 X T Y 201 ___________ A(x) A(t) _______________ a(t) a(y) _______ 202 | | | V6|P(x) P(y)| V6| | | V4|P(tx) P(y)| V4| | 203 | | S | | | | S | S | | | | | 204 | U | H | S | | S | H | I | S | | S | U | 205 | L | I | T |------------| T | I | I | T |-----------| T | L | 206 | P | M | A | | A | M | T | A | | A | P | 207 | | | C | | C | | | C | | C | | 208 | | X | K | | K | T | | K | | K | | 209 |___|___|___| |___|___|___|___| |___|___| 211 We will refer to the shim in X as SHIMX, and the shim in T as SHIMT. 213 The address set used by the shims for X is conceptually {a(t),A(x)}, 214 and for Y it is conceptually {a(y),A(t)}. In other words the ULP at 215 X sees its own ULID as a(t) and Y's ULID as a(y), both filled out to 216 128 bits. On the wire, the IPv6 packets between X and T use A(x) and 217 A(t) as the actual address pair. The IPv4 packets between T and Y 218 use a(t) and a(y). P(y) can be used everywhere, but we must assume 219 that P(x) will be used on the IPv6 side and P(tx) on the IPv4 side. 221 When a(t) and a(y) are filled out to 128 bits, an appropriate /96 222 prefix must be used. This must checksum to zero when 16-bit 223 transport checksums are computed. In SIIT, the ::ffff:0:0/96 IPv4- 224 mapped format is used to fill out addresses for IPv4 hosts. Also in 225 SIIT, an "IPv4-translated" address format is introduced to represent 226 a synthetic IPv4 address for the IPv6 host, with the ::ffff:0:0:0/96 227 prefix. This format, which is not in the IPv6 address architecture 228 [RFC4291], could be used as the ULID for X. But since the shim has 229 explicit knowledge of the addresses in use, is there any reason to 230 use this format in preference to the IPv4-mapped format? The latter 231 is assumed here for simplicity. 233 Further to this, because these addresses never appear on the IPv6 234 wire in SHANTI, there seems to be no reason in principle why the 235 deprecated ::/96 "IPv4-compatible" prefix could not be used for 236 further simplicity. However, this has been avoided to respect the 237 deprecation. 239 If there's an IPv4 NAT with routable address a(n) on the IPv4 path, 240 it won't know anything is special, and a(y) will be represented by 241 a(n). X, Y and T won't know that the NAT is there. X and T will not 242 know if Y has a private [RFC1918] address or if additional port 243 translation takes place. 245 T must have a large pool of A(t) addresses, and should have a 246 complete /64 to itself for maximum flexibility. 248 SHIMX is configured with knowledge of a default A(t) to start any new 249 exchange with SHIMT, and with knowledge of a(t). SHIMX will catch 250 all packets sent to ::ffff:0:0/96 by any ULP in X. When a ULP sends a 251 first packet to ::ffff:0:0:a(y)/128, we need to start a SHIM6-like 252 process. SHIMX will carry out a message exchange with SHIMT to 253 discover the relevant A(t) and P(tx) values. It can then update the 254 port number and recompute a transport checksum if needed, rewrite the 255 addresses as A(t),A(x), and send the packet on to A(t). Subsequent 256 packets in the same flow will not require a shim message exchange. 258 Note that the network stack in X will use the ULID ::ffff:0:0:a(t)/ 259 128 as the source address for checksum purposes. Source address 260 selection MUST choose this when the destination address matches 261 ::ffff:0:0/96. This is why a(t) must be configured in SHIMX. 262 Checksum recomputation by SHIMX will only be needed if P(tx) != P(x). 263 The NAT-like code for this will require data sharing between the 264 transport protocols and SHIMX. 266 T needs to select a specific A(t) and P(tx) for each new flow, and 267 exchange SHIM6-like messages with X, to tell SHIMX the values of A(t) 268 and P(tx) . This should create enough state in both shims to know 269 what to do with outbound and return packets. If T has a full /64 to 270 work with, it can create a new A(t) for each new X or even for each 271 new flow if that turns out to be needed. 273 Note that unlike SHIM6, SHANTI must perform the shim exchange before 274 sending the first packet of an outbound traffic flow from X. This is 275 because SHIMX must learn if P(tx) is unequal to P(x). A consequence 276 of this is that SHIMX should buffer packets of a new outbound flow 277 until it has completed its shim exchange with T. For this to scale, 278 it is important that the translator has adequate capacity for the 279 number of IPv6 hosts it serves, and adequate network connectivity to 280 them, so as to minimize buffering requirements. 282 When a data packet reaches T from X, there will already be shim state 283 established. The shim will pass the packet on to SIIT for 284 translation and IPv4 transmission. 286 Once the shim state is established, the ULPs in both X and Y will 287 work as normal. Since T uses a specific A(t) for each X, and the 288 shim at X is aware of that A(t), all port numbers are available in 289 each direction on the IPv6 side. Port mapping, if required, will 290 only affect the IPv4 side of T. Also, SHIMX is aware that the ULP in 291 Y believes it is using the address pair {a(t), a(y)} and the ports 292 {P(tx), P(y)}. Thus, address and port dependent fix-ups can be 293 performed, if needed, by SHIMX. This means that TCP and UDP 294 checksums do not need to be fixed up by T. This has scaling 295 advantages compared to NAT-PT. 297 Additionally, with this knowledge being available in the host rather 298 than being hidden in the translator as in NAT-PT, it is in principle 299 possible for any address and port dependencies in the ULP to be fixed 300 up in the host itself, precluding the need for Application Level 301 Gateways (ALGs). Although this would introduce a layer violation, it 302 is in principle a more robust design than associating ALGs with a 303 "stateless" translator. In particular, it means that new 304 applications on the IPv6 host do not require new ALG code in the 305 translator, removing a strong dependency in deployment scenarios. 307 3. General walkthroughs 309 Consider first an IPv6 client attempting to contact an IPv4 server 310 via this mechanism. The main steps that must occur are: 312 1. ULP in X obtains Y's IPv4-mapped address ::ffff:0:0:a(y)/128. 313 See DNS discussion below. 314 2. ULP sends unsolicited packet to that address. 315 3. SHIMX recognises the packet as needing attention. 316 4. SHIMX creates local state for a(y), P(x), and buffers the 317 packet. Also, it creates a packet to send to T. This is a 318 packet containing nothing but a shim header indicating that a 319 first packet is ready from A(x):P(x) to a(y):P(y). 320 5. SHIMT receives this shim header and checks for existing state 321 for {A(x):P(x),a(y):P(y)}. 322 6. If no such state exists, assign an A(t) value from the pool, and 323 create state. Includes the ports. If P(x) is already in use by 324 T, assign a P(tx). Otherwise, P(tx)=P(x). 325 7. SHIMT creates a packet to return to X. This is a packet 326 containing nothing but a shim header indicating the assigned 327 A(t) and P(tx). 328 8. SHIMX records this additional state, including P(tx) as the 329 translated port. 330 9. SHIMX now applies the following process to buffered and future 331 packets sent from ::ffff:0:0:a(t), port P(x) to ::ffff:0:0:a(y), 332 port P(y). 333 1. If P(tx) != P(x), recompute transport checksum as for 334 addresses DA=::ffff:0:0:a(y), SA=::ffff:0:0:a(t) and ports 335 DP=P(y), SP=P(tx). 336 2. Rewrite destination address as A(t). 337 3. Rewrite source address as A(x). 338 4. Rewrite destination port as P(tx). 339 5. Send packet. 340 10. SHIMT rewrites the addresses as DA=::ffff:0:0:a(y), SA=::ffff:0: 341 0:a(t), and hands the packet off to SIIT. 342 11. SIIT translates the packet to IPv4 and sends it on (destination 343 = a(y), source = a(t)). 344 12. When an IPv4 return packet comes into SIIT, SIIT translates the 345 packet to IPv6 and hands it to SHIMT. 346 13. The shim performs port demultiplexing on the destination port 347 (which will be P(tx)) to identify the A(x) involved. 348 14. The shim rewrites the addresses as A(x), A(t) and sends the 349 packet on to A(x). 350 15. The shim at X receives the packet, rewrites the header to 351 restore the original ULIDs and P(x), and sends the packet on up 352 the stack. 354 Now consider an IPv4 client attempting to contact an IPv6 server via 355 T. The main steps that must occur are: 357 1. T must be pre-configured to admit traffic for P(x) and forward it 358 to A(x). This is a normal port-forwarding issue, to be solved as 359 for NATs or perhaps as proposed in [I-D.woodyatt-ald]. It cannot 360 be performed without pre-existing state. Assuming T has only one 361 a(t), a given P(x) can only have one IPv6 listener. 362 2. ULP in Y obtains an IPv4 address for T (believing it to be the 363 actual server X). 364 3. Y sends an unsolicited packet from a(y) to a(t), port P(x). 365 4. It is passed to SIIT in T, translated to IPv6 format, and passed 366 on to SHIMT. 367 5. SHIMT performs port demultiplexing and determines that the packet 368 is destined for A(x). It creates state if none exists. 369 6. SHIMT inserts a shim header that will tell X the translation in 370 effect, translates the addresses, and sends the packet from A(t) 371 to A(x). 372 7. SHIMX receives the packet, and translates the addresses to 373 ::ffff:0:0:a(t)/128 and ::ffff:0:0:a(y)/128. This should 374 checksum OK. SHIMX creates state if none exists. 375 8. The packet is delivered to the ULP, minus the shim header. 377 Subsequent packets will flow as in the previous case. 379 Shim state will be torn down (deleted) using inactivity timers, as 380 for SHIM6 and typical NATs. 382 4. Placement of the shim 384 In SHIM6 the shim is logically placed below both the transport and 385 IPsec layers, so that their checksums do not need recalculation. In 386 SHANTI, the transport layer checksum does need to be recalculated by 387 the shim, rather in the manner that a NAT behaves. However, this 388 cannot be done for cryptographic checksums for obvious reasons. The 389 shim should perhaps be regarded as logically below transport, but a 390 better implementation would be for each transport layer to invoke the 391 shim in-line prior to executing its checksum calculation. 393 5. DNS 395 It is required that the IPv6 hosts "behind" a SHANTI translator 396 either have a resolver that maps A records into AAAA records expanded 397 with ::ffff:0:0/96, or a DNS server that actually stores such 398 records, or performs this transformation on the fly. On the 399 assumption that hosts behind a translator will need to be configured 400 in any case, in order to activate the shim, a mapping resolver seems 401 likely to be the most robust choice, applying the fate-sharing 402 principle. It would also work in a network with a mixture of SHANTI 403 and dual-stack hosts. The former would see A records mapped as AAAA, 404 and the latter would see native A records. 406 This illustrates that SHANTI is an all-or-nothing approach. It 407 doesn't seem plausible to activate SHANTI on a dual stack host since 408 DNS entries are either mapped, or they aren't. But why would it be 409 needed? 411 "Outside" the translator, SHANTI hosts must be represented by an A 412 record with the address of their translator. Specifically, the 413 host's FQDN will have one or more AAAA records with its IPv6 414 address(es) and an A record with its translator's address. A dynamic 415 DNS-ALG is not needed. 417 6. ICMP 419 In general, ICMP translation in both directions will proceed as 420 defined in SIIT. 422 The pool of IPv4 addresses concerned (section 3.5 of [RFC2765]) will 423 contain only a(t), and SHIMT will have to perform port demultiplexing 424 in order to dispatch ICMP messages translated from IPv4 to the 425 correct A(x). SHIMX will have to perform address or checksum 426 rewriting as for other packets. (More details TBD). 428 7. Unresolved issues 430 This section comments on issues raised in [RFC4966] with regard to 431 whether they are mitigated or resolved by the present specification. 432 The relevant section headings from RFC 4966 are included for 433 reference. 435 2.1. Issues with Protocols Embedding IP Addresses 437 In SHANTI, these can in principle be resolved within the IPv6 438 host, with no dependency on an up-to-date translator. This does 439 require the protocol implementation in the IPv6 host to be SHANTI- 440 aware. Also see issue 5 below. 442 2.2. NAPT-PT Redirection Issues 444 This concerns protocols where the port number is absent or 445 encrypted, so port de-multiplexing is impossible. SHANTI cannot 446 solve this problem; it is intrinsic in sharing one IPv4 address 447 among many IPv6 hosts. However, since it's an intrinsic problem 448 of the NAPT model, SHANTI doesn't create this problem either; IPv4 449 hosts already have to live with it. 451 2.3. NAT-PT Binding State Decay 453 This concerns protocols whose idle times may exceed any reasonable 454 tear-down timer, leading to a risk of P(tx) being reassigned while 455 still in use. This risk should be mitigated in SHANTI, since the 456 tear-down can be synchronized between SHIMX and SHIMT. It would 457 even be theoretically possible for SHIMX to probe the application. 459 2.4. Loss of Information through Incompatible Semantics 461 This concerns inevitable loss of information such as the IPv6 Flow 462 Label. SHANTI cannot solve this problem; it is intrinsic, as 463 observed in [RFC1671] section B1. 465 2.5. NAT-PT and Fragmentation 467 Put simply, fragments can't be port-demultiplexed without 468 reassembly. SHANTI cannot solve this problem; it is intrinsic in 469 sharing one IPv4 address among many IPv6 hosts. Only applications 470 that probe for the available MTU size can overcome this issue. 471 However, since it's an intrinsic problem of the NAPT model, SHANTI 472 doesn't create this problem either; IPv4 hosts already have to 473 live with it. 475 2.6. NAT-PT Interaction with SCTP and Multihoming 477 SCTP includes alternative addresses in its messages. This is 478 solved as in issue 2.1 above. SHANTI would remain a single point 479 of failure for SCTP. 481 2.7. NAT-PT as a Proxy Correspondent Node for MIPv6 483 The problem is that MIPv6 route optimization cannot possibly be 484 supported on the IPv4 network. This is intrinsic, but in SHANTI 485 it would be possible for SHIMX to suppress messages and headers 486 relating to changes of care-of addresses, including reverse 487 routing checks, at their source, if they are sent to the ::FFFF:0: 488 0/96 prefix. 490 2.8. NAT-PT and Multicast 492 SHANTI does not handle multicast translation. 494 Issues 3.1 through 4.5 are partly or completely related to NAT- 495 PT's requirement for a DNS-ALG. SHANTI does require DNS entries 496 for IPv4 hosts to be presented to the ULP as AAAA records, but 497 this does not require a dynamic DNS-ALG to be colocated with the 498 SHANTI translator (see Section 5). Thus, these issues are 499 intrinsically mitigated by SHANTI. 501 3.1. Network Topology Constraints Implied by NAT-PT 503 Not relevant to SHANTI. 505 3.2. Scalability and Single Point of Failure Concerns 507 Compared to NAT-PT, a SHANTI translator has a simpler job since 508 checksum calculations are left to the IPv6 host, and DNS-ALG is 509 not needed. Scalability of performance is therefore less of a 510 concern. SHANTI remains a single point of failure, unless a load 511 sharing feature with failover is added. These issues are 512 intrinsic to any translator scenario. 514 3.3. Issues with Lack of Address Persistence 516 In the absence of DNS-ALG, this appears to be identical to issue 517 2.3 above. 519 3.4. DoS Attacks on Memory and Address/Port Pools 521 In the absence of DNS-ALG, this appears to be a "standard" DoS 522 threat to which almost any protocol is exposed. See Section 8. 524 4.1. Address Selection Issues when Communicating with Dual-Stack 525 End-Hosts 527 In the absence of DNS-ALG, there should be no problem in 528 configuring IPv6 hosts to prefer native IPv6 addresses to IPv4- 529 mapped addresses. Also, the resolver code (Section 5) could be 530 designed to always return IPv4-mapped addresses last in the 531 response to getaddrinfo(). 533 4.2. Non-Global Validity of Translated RR Records 535 If an IPv4-mapped address known by host X in the above scenario is 536 passed on to any other IPv6 host equipped with SHANTI, it will 537 work, assuming that the IPv4 address is globally unique. If it's 538 a private [RFC1918] address, it may fail, but that is intrinsic to 539 private IPv4 addressing. Otherwise, in the absence of DNS-ALG, 540 this issue is not applicable to SHANTI. 542 4.3. Inappropriate Translation of Responses to A Queries 544 In the absence of DNS-ALG, this is not applicable to SHANTI. 546 4.4. DNS-ALG and Multi-Addressed Nodes 548 In the absence of DNS-ALG, this is not applicable to SHANTI. 550 4.5. Limitations on Deployment of DNS Security Capabilities 552 In the absence of DNS-ALG, this is not applicable to SHANTI. 554 5. Impact on IPv6 Application Development 556 This is closely related to issue 2.1. As noted above, a SHANTI 557 host is aware of the translation in effect. SHANTI will work "out 558 of the box" for any application that runs through a traditional 559 NAT or NAPT without problems *and* has been upgraded to AF_INET6 560 sockets. In other cases, the shimmed IPv6 stack can make an 561 application aware of the both the ULIDs in use and of the 562 translated port number, perhaps via socket options. Although 563 modifying application code to take this into account may appear 564 complex, application developers might prefer this to today's 565 obscure failure modes caused by IPv4 NAPT or NAT-PT. 567 In conclusion, it seems that SHANTI overcomes or mitigates many of 568 the issues noted with NAT-PT. Those that remain appear to be 569 intrinsic to any translation scenario. 571 8. Security Considerations 573 As for NAT-PT, there is no obvious way to carry network layer IPsec 574 across a SHANTI translator. There seems to be no reason IKE 575 [RFC4306] cannot run in a SHANTI scenario, using its port agility 576 intended for NAT tolerance. But that in itself isn't very useful. 577 It seems likely that security solutions running above the transport 578 layer will be required in order to protect a SHANTI session. 580 The use of a shim layer in SHANTI will raise some of the security 581 issues considered for SHIM6 . More analysis of the potential 582 spoofing and denial of service threats is needed to determine whether 583 a cryptographic solution is needed, or if there is a straightforward 584 way to prevent attackers taking over a session by impersonating the 585 shim. It may be possible to find a simple method of arranging a 586 shared secret between X and T, such that an elementary hash can be 587 used to authenticate the shim headers. 589 9. IANA Considerations 591 This document has not yet been exhaustively checked for possible 592 action by the IANA. 594 10. Acknowledgements 596 Vital comments on a very primitive version of this proposal were made 597 by Marcelo Bagnulo Braun and Iljitsch van Beijnum. Contributions and 598 comments by David Miles and others are gratefully acknowledged. 600 This document was produced using the xml2rfc tool [RFC2629]. 602 11. Change log [RFC Editor: please remove this section] 604 draft-carpenter-shanti-01: added dedication, clarifications, bug 605 fixes, added RFC4966 analysis, 2007-11-08 607 draft-carpenter-shanti-00: original version, 2007-10-28 609 12. References 611 12.1. Normative References 613 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 614 Requirement Levels", BCP 14, RFC 2119, March 1997. 616 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 617 (SIIT)", RFC 2765, February 2000. 619 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 620 Architecture", RFC 4291, February 2006. 622 12.2. Informative References 624 [I-D.ietf-shim6-proto] 625 Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming 626 Shim Protocol for IPv6", draft-ietf-shim6-proto-09 (work 627 in progress), November 2007. 629 [I-D.woodyatt-ald] 630 Woodyatt, J., "Application Listener Discovery (ALD) for 631 IPv6", draft-woodyatt-ald-01 (work in progress), 632 June 2007. 634 [RFC1671] Carpenter, B., "IPng White Paper on Transition and Other 635 Considerations", RFC 1671, August 1994. 637 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 638 E. Lear, "Address Allocation for Private Internets", 639 BCP 5, RFC 1918, February 1996. 641 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 642 June 1999. 644 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 645 Translation - Protocol Translation (NAT-PT)", RFC 2766, 646 February 2000. 648 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 649 RFC 4306, December 2005. 651 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 652 Address Translator - Protocol Translator (NAT-PT) to 653 Historic Status", RFC 4966, July 2007. 655 Author's Address 657 Brian Carpenter 658 Department of Computer Science 659 University of Auckland 660 PB 92019 661 Auckland, 1142 662 New Zealand 664 Email: brian.e.carpenter@gmail.com 666 Full Copyright Statement 668 Copyright (C) The IETF Trust (2007). 670 This document is subject to the rights, licenses and restrictions 671 contained in BCP 78, and except as set forth therein, the authors 672 retain all their rights. 674 This document and the information contained herein are provided on an 675 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 676 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 677 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 678 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 679 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 680 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 682 Intellectual Property 684 The IETF takes no position regarding the validity or scope of any 685 Intellectual Property Rights or other rights that might be claimed to 686 pertain to the implementation or use of the technology described in 687 this document or the extent to which any license under such rights 688 might or might not be available; nor does it represent that it has 689 made any independent effort to identify any such rights. Information 690 on the procedures with respect to rights in RFC documents can be 691 found in BCP 78 and BCP 79. 693 Copies of IPR disclosures made to the IETF Secretariat and any 694 assurances of licenses to be made available, or the result of an 695 attempt made to obtain a general license or permission for the use of 696 such proprietary rights by implementers or users of this 697 specification can be obtained from the IETF on-line IPR repository at 698 http://www.ietf.org/ipr. 700 The IETF invites any interested party to bring to its attention any 701 copyrights, patents or patent applications, or other proprietary 702 rights that may cover technology that may be required to implement 703 this standard. Please address the information to the IETF at 704 ietf-ipr@ietf.org. 706 Acknowledgment 708 Funding for the RFC Editor function is provided by the IETF 709 Administrative Support Activity (IASA).