idnits 2.17.1 draft-savola-v6ops-tunneling-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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 675. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 681. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 697), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 458: '... tunneling is a MUST requirement....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (Apr 2004) is 7310 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 (-03) exists of draft-ietf-v6ops-unmaneval-01 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-unmaneval (ref. '1') == Outdated reference: A later version (-11) exists of draft-ietf-v6ops-3gpp-analysis-09 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-3gpp-analysis (ref. '2') == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-isp-scenarios-analysis-01 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-isp-scenarios-analysis (ref. '3') == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-ent-scenarios-01 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ent-scenarios (ref. '4') == Outdated reference: A later version (-05) exists of draft-huitema-v6ops-teredo-01 == Outdated reference: A later version (-24) exists of draft-ietf-ngtrans-isatap-20 ** Downref: Normative reference to an Experimental draft: draft-ietf-ngtrans-isatap (ref. '6') -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-04) exists of draft-blanchet-v6ops-tunnelbroker-tsp-00 ** Downref: Normative reference to an Experimental draft: draft-blanchet-v6ops-tunnelbroker-tsp (ref. '8') == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-mech-v2-02 == Outdated reference: A later version (-02) exists of draft-chown-v6ops-vlan-usage-00 == Outdated reference: A later version (-07) exists of draft-ooms-v6ops-bgp-tunnel-02 Summary: 15 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Savola 3 Internet-Draft CSC/FUNET 4 Expires: September 30, 2004 J. Soininen 5 Nokia 6 Apr 2004 8 Evaluation of v6ops Tunneling Scenarios and Mechanisms 9 draft-savola-v6ops-tunneling-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-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 http:// 28 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 September 30, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This memo analyses the v6ops scenarios/analysis work (Unmanaged, 42 3GPP, ISP and Enterprise) for their requirements for tunneling 43 solutions, and analyses the proposed mechanisms on how they might fit 44 in these requirements, and discusses possibilities for choosing 45 solution(s). 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. The Selection Process . . . . . . . . . . . . . . . . . . . . 3 51 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3.1 3GPP Networks . . . . . . . . . . . . . . . . . . . . . . 3 53 3.2 Unmanaged Networks . . . . . . . . . . . . . . . . . . . . 4 54 3.3 Enterprise Scenarios . . . . . . . . . . . . . . . . . . . 6 55 3.4 ISP Scenarios . . . . . . . . . . . . . . . . . . . . . . 7 56 3.5 Additional Scenarios: IP Mobility . . . . . . . . . . . . 7 57 4. Scenarios and Mechanisms Evaluation . . . . . . . . . . . . . 8 58 4.1 Scenarios Evaluation . . . . . . . . . . . . . . . . . . . 8 59 4.2 Mechanisms Evaluation . . . . . . . . . . . . . . . . . . 9 60 4.3 Evaluation Summary . . . . . . . . . . . . . . . . . . . . 10 61 4.4 Features of the Mechanisms . . . . . . . . . . . . . . . . 11 62 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 67 8.2 Informative References . . . . . . . . . . . . . . . . . . . 14 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 69 Intellectual Property and Copyright Statements . . . . . . . . 16 71 1. Introduction 73 This memo analyzes the v6ops scenarios/analysis work (Unmanaged [1], 74 3GPP [2], ISP [3], Enterprise [4]) at a bit more length, summarizes 75 the exact requirements for tunneling in the scenarios, and analyzes 76 how different mechanisms would fit into those specific tunneling 77 requirements. 79 The mechanisms analyzed in this document are Teredo [5], ISATAP [6], 80 STEP [7], and TSP [8] The latter two are examples of the tunnel 81 server/broker concept [9]. Already-specified, and in many cases 82 applicable tunneling mechanisms are 6to4 [10] and configured 83 tunneling [11]. Some others include so-called "6over4" [12] and 84 Layer 2 Tunneling Protocol (L2TP) [13]. 86 2. The Selection Process 88 It is strongly desirable to be able to recommend as few mechanisms as 89 reasonably possible. This is an important tradeoff to consider. 90 However, it is likely that one has to give up some features to 91 achieve that goal. 93 However, it is recognized that there are implementations out there: 94 therefore, one can submit I-Ds specifying currently implemented (but 95 only that; no additions) mechanisms to RFC-editor as invidial 96 contributions for Informational or Experimental RFC. These documents 97 will include a clear IESG Note and/or an applicability statement that 98 these are not recommended mechanisms. The goal of this process is to 99 improve interoperability of the implementations that already exist, 100 and some have deemed fit to implement. XXX: anything about the 101 timing when these can be submitted to the RFC-editor? 103 3. Scenarios 105 This section described the specific cases identified inside the 106 scenarios where a form of tunneling is desirable. 108 3.1 3GPP Networks 110 There are two closely related cases: 112 1. Providing IPv6 connectivity to User Equipment (UE) when it roams 113 to an another operator's network, and the other operator does not 114 support IPv6 PDP contexts. 116 2. Providing IPv6 connectivity to UEs when the "home" 3GPP operator 117 has not deployed even minimal IPv6 PDP context support yet in its 118 network -- but would like to enable IPv6 connectivity through a 119 transition mechanism which can be transparently overlayed on the 120 existing IPv4 3GPP network. 122 Note that the current document strongly recommends at least initial 123 IPv6 PDP context support: this only requires support from HLR, SGSN 124 and one GGSN. 126 The case where there is no IPv6 connectivity at all in the 3GPP 127 network is considered out of scope (but a solution can be achieved 128 using one of the Unmanaged connectivity mechanisms if appropriate). 130 In this scenario, it is assumed that the users are typically using 131 private IPv4 addresses, but there is no NAT in the path between the 132 different users in the same 3GPP network. 134 There are a couple of differences with the two cases described above: 135 in the first case, the operator has deployed IPv6 PDP context 136 support, as recommended, but some other ISP has not: waiting for all 137 the operators to deploy IPv6 PDP context support prior to launching 138 the service would be unacceptable -- so there has to be a solution to 139 this. 141 Also, note that the tunnel from the foreign 3GPP network is 142 terminated at the local 3GPP operator's network, inducing delay and a 143 bottle-neck; "direct connectivity" optimization is not much different 144 whether the tunnel would be terminated at a tunnel server, or 145 communicating directly. In the second case, one could argue that the 146 deployment should only be temporary, with at least minimal IPv6 PDP 147 context support being the goal. 149 In any case, the critical question in this specific scenario is, how 150 desirable is it to have direct tunneling between the UEs in the same 151 3GPP network -- instead of a slightly longer "leg" through a tunnel 152 server? Clearly, this would be desirable -- but not a strict 153 requirement. Also, to re-iterate the (strongly) recommended 154 deployment scenario in the 3GPP networks is the native (even if 155 minimal) IPv6 PDP context support; accepting non-direct connectivity 156 could be an acceptable tradeoff in the early adopter phase, also 157 encouraging to move to proper IPv6 support. 159 3.2 Unmanaged Networks 161 The unmanaged scenarios seem to include two cases, with a subcase, 162 totalling 3 different cases; these are derived from both unmanaged 163 and ISP scenario documents. 165 1. When the user's direct ISP does not offer any IPv6 service at 166 all, and connectivity must be obtained automatically. 168 1. When the connectivity must be obtained with as little 169 infrastructure as possible, without any signups or contracts, 170 etc. 172 2. When the connectivity can be obtained from a third party, 173 through a sign-up, contract, etc. -- for higher 174 manageability, more control, increased security benefits, or 175 for other reasons. (Whether such "3rd party connectivity" is 176 feasible or good enough is a separate question.) 178 2. When the user's direct ISP would like to offer IPv6 service, but 179 would require tunneling for some reason (e.g., access router, 180 access link, or the gateway in the unmanaged network is incapable 181 of IPv6). In this case the options are basically tunneling from 182 the gateway, a separate IPv6 gateway or tunneling from the 183 host(s). 185 It should be noted that a solution to problem 1.2) would solve 186 problem 2) as well, but a solution to problem 2) would not 187 necessarily be adequate for solving 1.2). 189 NAT traversal must be supported. Dynamic IPv4 addresses must be 190 supported -- but the solution does not necessarily have to be better 191 than dynamic IPv4 addresses are today; e.g., a dynamic IPv6 address 192 would be acceptable as well. 194 When the gateway has been upgraded to support IPv6 (but access router 195 or link has not, resulting in tunneling from the gateway, NAT 196 traversal doesn't need to be used as often. That is, often the 197 gateway has a public IPv4 address on its Internet-side interface, so 198 a mechanism like 6to4 can be used on the gateway to provide 199 "native-like" IPv6 support to the unmanaged network. However, there 200 are a number of cases where this is not sufficient -- for example, 201 when the gateway is connecting to a privately-addressed access 202 network shared by multiple ISPs. In such case, the gateway may be 203 unable to obtain IPv6 connectivity. 205 It seems obvious that direct tunneling between users is required at 206 least when there is no ISP support -- to minimize the latency 207 increase, and to decrease the bandwidth aggregation. However, it is 208 not a strict requirement with hosts in the same ISP: in such a case, 209 the slight increase in latency and concentration of traffic is 210 probably manageable. It should be re-iterated that tunneling is not 211 meant to be a permanent solution, and accepting that the connectivity 212 may not be fully optimal should be acceptable. 214 One should note that direct connectivity that traverses NATs, as is 215 requirement here, is a very difficult thing to do right; essentially, 216 this is what Teredo is doing. On the other hand, if the ISP is 217 offering service which does not provide direct connectivity between 218 hosts, the use of another mechanism (such as 6to4 or Teredo) "on the 219 side" could perhaps provide at least partial direct connectivity. 221 3.3 Enterprise Scenarios 223 This scenario/analysis work is still incomplete, so it is not fully 224 addressed in this memo. 226 The only scenario which is obvious at the moment is when the 227 enterprise wishes to deploy IPv6 without changing the gear to be 228 dual-stack, without injecting IPv6 into existing VLANs [14], or 229 without adding additional IPv6 routers in the VLANs. In particular, 230 this may be the case when the IPv6 deployment is "sparse" -- because 231 if it was sufficiently "dense", it would make sense to expand the 232 infrastructure in one of the several ways. It would be nice if the 233 tunneling between the nodes is direct from node-to-node, but this is 234 not a strict requirement. 236 There are at least three subcases of this scenario: 238 1. When the enterprise does not NAT between different parts of the 239 internal network. This case is useful to separate from case 2 240 merely because it is generally the common case, where simplicity 241 is the most highly valued. 243 2. When NATs exist within the enterprise network, e.g., to connect 244 branch offices to the corporate network. Hence, some form of NAT 245 traversal must be supported. 247 3. When the enterprise internally uses multicast applications/ 248 protocols that they want to transition to IPv6. Here the 249 enterprise has already deployed intra-domain IPv4 multicast to 250 support this stage. As with case 1, there are no internal NATs in 251 this case since IPv4 multicast itself does not cross NATs. 253 Case 3 is special because the number of enterprises with all-reaching 254 IPv4 multicast deployment is low. While IPv4 multicast support is 255 typically more commonplace than (even unicast) IPv6 support, the 256 enterprises are typically in a better position than those which would 257 not have IPv4 multicast at all. Therefore, native IPv6 multicast 258 support is a possibility, while using tunneling mechanism(s) which 259 support IPv6 multicast by tunneling is a simple short-term deployment 260 fix. 262 The need for direct connectivity in all cases is strong due to two 263 factors: 265 o The high end-to-end bandwidth requirements for enterprise 266 applications, e.g., many clients accessing various servers, such 267 that bottlenecks occur if all traffic must be funneled through one 268 or a few tunnel endpoints. However, note that heavy usage is 269 quite a strong argument for native (or hierarchical/distributed) 270 IPv6 deployment. 272 o The use of collaborative applications, possibly including 273 high-bandwidth streams such as audio/video. 275 Finally, most enterprise networks currently lack IPv6 expertise, and 276 have a great need to keep costs low. Hence simplicity and low 277 infrastructure costs are also required. (This is not really specific 278 to enterprises, though.) 280 3.4 ISP Scenarios 282 ISPs have two possible requirements for tunneling: either inside 283 their own infrastructure (e.g., through a non-upgraded core network) 284 or to their peers or upstreams, or towards customers. 286 Internal tunneling requirements can be satisfied with configured 287 tunneling or the use of [15] as described in [3] so there is no need 288 to discuss that in this memo. Similarly, tunneling requirements 289 towards peers or upstreams are satisfied by configured tunneling 290 only. 292 As for tunneling towards customers, ISPs do not have specific 293 scenarios which need to be addressed which haven't been already 294 mentioned: some ISPs want to provide IPv6 connectivity, possibly over 295 a tunnel, to their unmanaged or enterprise customers, or ISPs. 296 However, these requirements have already been discussed; only two 297 particular considerations should be explicitly mentioned: 299 1. Mechanisms used must be very simple if we want them to be adopted 300 by many ISPs, 302 2. Very few ISPs want to be providing service, for free at least, to 303 the users which are not their customers. Therefore being able to 304 identify the user as your own customer is very important. 305 (Whether this is done by explicit user authentication or basing 306 on IP-address -based knowledge of whether the user is your 307 customer is a detail.) 309 3.5 Additional Scenarios: IP Mobility 311 Recently, there some concerns have been raised about additional 312 scenarios work, which might be partially worked under v6ops WG. One 313 such is work on the scenarios where IP nodes are not stationary, 314 i.e., are expected to change IPv4 or IPv6 address relatively rapidly. 315 In many cases this implies that either MIPv4 or MIPv6 is being run to 316 ensure a relatively stable IP address being available, and to make 317 the changes in IP addresses as transparent as possible. 319 This is not a formal scenario as such, but in these events it would 320 be extremely desirable to have minimal amount of signalling when the 321 attachment point (whether a care-of or home address) changes -- to 322 ensure seamless IP mobility. 324 4. Scenarios and Mechanisms Evaluation 326 4.1 Scenarios Evaluation 328 NAT-T Direct ISP Secure Simple Low Mcast Gateway 329 Overhead 330 Unman 1.1 * * N - - - - - 331 Unman 1.2 * N * -/* - - - - 332 Unman 2 * - * - * - - - 333 3GPP 1 N -/* * - * * - N 334 3GPP 2 N -/* * - * * - N 335 Enterprise 1 N -/* * -/* * - - -/N 336 Enterprise 2 * -/* * - * - - -/N 337 Enterprise 3 N -/* * - * - * -/N 339 Legend: * = MUST; - = Nice to have; N = No 341 NAT traversal specifies whether NAT traversal is a requirement. 343 Direct tunneling states whether direct tunneling between the nodes 344 using the same mechanism is a requirement. 346 "ISP" indicates whether the scenario assumes that the ISP provides 347 IPv6 support. That is, whether the mechanism must be able to operate 348 (at least to a degree) without explicit support from an ISP which is 349 identifying the user. 351 "Secure" is an overly simplistic term to evaluate whether the 352 scenario requires some specific amount of security. Here, security 353 implies security issues which may not be trivially fixable, whether 354 the operational mode or in the mechanism, such that it is difficult 355 to secure, whether it creates new significant threats to either IPv4 356 or IPv6 infrastructures, etc. 358 Simple is a term which refers to the simplicity of the protocol or 359 the operational model in which it operates; simple protocols and 360 specifications are easy to understand, evaluate, implement, and 361 deploy, and thus preferable to more complex ones. 363 "Low overhead" refers to both minimal encapsulation -- as few added 364 bytes in the messages or signalling as possible -- and signalling 365 latency (e.g., the number of messages/round-trips to set-up, change, 366 or tear down a tunnel). 368 Multicast states whether IPv6 multicast should be supported. 370 Gateway refers to whether the scenario also requires that an upgraded 371 gateway, to provide IPv6 connectivity to the local link(s), must be 372 supported. 374 4.2 Mechanisms Evaluation 376 One should note that we are not evaluating the specific version of 377 the specification, but rather the mechanism in a more generic sense 378 ("which features could this mechanism easily be made to work with?"). 380 NAT-T Direct ISP Secure Simple Low Mcast Gateway Impl. Depl 381 Overhead 382 Teredo Y Y N Y N N N N R Y 383 ISATAP N Y@ Y N/R R Y N R Y R? 384 TSP Y N Y? Y R N Y# Y R R? 385 STEP Y N Y Y Y/R Y Y# R N N 386 L2TP Y N Y Y N N Y# R? Y Y 387 6to4 N Y$ N N Y Y N Y Y Y 388 6over4 N Y@ Y N/R Y Y Y R R N 390 @: intra-site, when no NATs are in the path 391 #: in a non-optimal fashion 392 $: only between public IPv4 addresses 394 Legend: Y = Yes; R = Relatively good; N = No 396 Notes: 6to4 does not work behind a NAT, so it is not applicable in 397 3GPP scenarios, and practically also not applicable in Enterprise 398 scenarios. 6over4 requires IPv4 multicast infrastructure, so it is 399 practically only applicable in Enterprise scenario 3. 401 NAT traversal states whether the mechanism is able to perform full 402 NAT traversal. 404 Direct tunneling states whether the mechanism is able to provide 405 direct tunneling between the nodes using the same mechanism. 407 "ISP" indicates whether ISP(s) must explicitly, identifying the user, 408 support the mechanism in order for the mechanism to operate (at least 409 to a degree). 411 "Secure" is an overly simplistic term to evaluate whether the 412 mechanism has obvious security issues which may not be trivially 413 fixable, whether the operational mode or in the mechanism, such that 414 it is difficult to secure, whether it creates new significant threats 415 to either IPv4 or IPv6 infrastructures, etc. 417 Simple is a term which refers to the simplicity of the protocol or 418 the operational model in which it operates; simple protocols and 419 specifications are easy to understand, evaluate, implement, and 420 deploy, and thus preferable to more complex ones. 422 "Low overhead" refers to both minimal encapsulation -- as few added 423 bytes in the messages or signalling as possible -- and signalling 424 latency (e.g., the number of messages/round-trips to set-up, change, 425 or tear down a tunnel). 427 Multicast states whether the mechanism supports IPv6 multicast. 428 Bidirectional tunnels support it but do not leverage the underlying 429 link-layer for packet duplication, as e.g., so-called 6over4 does. 431 "Gateway" refers to whether the mechanism can be used on a router to 432 provide "native-like" IPv6 connectivity to its link(s), or whether 433 the mechanism can only be used at each individual host. 435 Implemented refers how widely the mechanism has been implemented 436 (e.g., no implementations, one implementation, multiple interoperable 437 implementations), and how large part of the mechanism has been 438 implemented. 440 "Widely deployed" refers to how widely the mechanism has been 441 deployed: is it in use as deployed by multiple vendors, or in many 442 operational scenarios? 444 4.3 Evaluation Summary 446 By combining the two matrices, we obtain the following: 448 o Unmanaged scenario 1.1) requires Teredo. 450 o Unmanaged 1.2) requires STEP, TSP or L2TP. 452 o Unmanaged 2) requires STEP or TSP. 454 o 3GPP 1) can be filled by STEP or ISATAP; if a higher level of 455 security is required, ISATAP may not be applicable. 457 o 3GPP 2) can be filled by STEP or ISATAP; only ISATAP if direct 458 tunneling is a MUST requirement. 460 o Enterprise 1) requires STEP, TSP, or ISATAP. 462 o Enterprise 2) requires STEP or TSP. 464 o Enterprise 3) requires STEP, TSP, or 6over4. 466 This evaluation indicates that Teredo is needed, no matter what. 467 STEP can satisfy all the other requirements, and TSP almost all. So, 468 the minimum number of recommended "new" mechanisms appears to be 2: 469 Teredo and something else. 471 6to4 can (continue to) be used when the gateway has been upgraded in 472 all the unmanaged scenarios; this does not work in every case, 473 though. 475 On the other hand, if direct connectivity was a strict requirement, 476 the minimum number of "new" mechanisms would have to be 3, as Teredo 477 and ISATAP would not be sufficient on their own. 479 Actually, it would be preferable in some sense to combine TSP and 480 STEP as they are best applicable in quite similar scenarios. This 481 might allow one to combine the best features of both proposals. If 482 an auto-discovery feature would be added to that mechanism, we would 483 have a very powerful mechanism which would apply well in almost all 484 scenarios. 486 4.4 Features of the Mechanisms 488 If we would assume that we'd prefer to recommend two solutions, in 489 addition to 6to4 and configured tunneling, which are already there, 490 we would have to judge, based on the scenario requirements, three 491 critical features: 493 1. NAT traversal 495 2. Direct connectivity inside a site/ISP/enterprise 497 3. Operation with third party ISPs 499 In several scenarios, it's impossible to have both 1) and 2) without 500 a relatively complex solution. Similarly, there is often a conflict 501 with 2) and 3). 503 Therefore, we must be able to make a decision which features/ 504 requirements we are willing to give up in which specific scenarios, 505 or whether we have to specify more mechanism to satisfy all the 506 features. 508 For example, by picking Teredo and {TSP or STEP}, we would have to 509 give up direct connectivity inside the 3GPP, Enterprise and the 510 unmanaged scenarios where the ISP is offering service -- except where 511 it would automatically come along where Teredo (or 6to4) service is 512 active in any case. 514 On the other hand, ISATAP is unable to properly perform NAT 515 traversal, and it is not designed to securely interact with third 516 party ISPs. By picking Teredo and ISATAP, we would not have a 517 solution to operate with 3rd party ISPs, ISPs which do not properly 518 secure their borders, or in the cases where NAT traversal is required 519 and Teredo is seen as too cumbersome a choice. However, Teredo does 520 provide a means to interoperate with a specifically crafted, 521 simplistic Tunnel Server implementation; if we assume that it would 522 be acceptable to recommend implementation and deployment of Teredo to 523 be able to use a tunnel server service, implementing a stub tunnel 524 server could provide a means to achieve support in the 3rd party ISP 525 case. 527 Direct connectivity inside (a vague definition of) a "site" is 528 sometimes seen as attractive, e.g., to be done with ISATAP. There 529 are two possible arguments: sparse and dense deployment. In the 530 "sparse" deployment case, the requirements of the site can be met 531 with an (auto-discovered) tunnel server solution. In the "dense" 532 deployment case, when direct connectivity could be desirable because 533 the tunnel servers would get overloaded or the bandwidth could be 534 wasted, there is a strong reason to go for a dual-stack (whether 535 partial, e.g., with hierarchical tunnel servers or full deployment) 536 solution instead. Therefore, it seems that when other choices are 537 feasible, "intra-site" direct connectivity is not a progressive way 538 forward. 540 As Teredo is the only solution available for scenario 1.1), it seems 541 that it cannot be left out. 543 5. Conclusions 545 There seems to be clear need for Teredo. There is also clear desire 546 to keep using 6to4 in the cases where it's applicable. 548 There seems to be clear need for a tunnel server protocol which is 549 able to traverse NATs and work with dynamic IPv4 addresses. This 550 tunnel server should be able to automatically discover the server 551 address if the service is provided by the ISP. 553 Direct connectivity is desirable but difficult to provide in a few 554 specific scenarios when considering the other trade-offs. However, 555 global direct connectivity can be obtained with 6to4 and Teredo; 556 local direct connectivity, inside 3GPP, ISP or enterprise is 557 something that one could be able to live without. 559 (Further TBD.) 561 6. Security Considerations 563 This memo analyses the tunneling scenario requirements and mechanisms 564 trying to address these requirements. As such, it does not have 565 significant security considerations. When considering which 566 mechanism(s) to adopt, the security properties of the mechanisms vary 567 considerably -- and this has to be taken in consideration in the 568 evaluation and selection. However, mechanism-specific considerations 569 are to be addressed in the respective documents. 571 7. Acknowledgements 573 This memo was written from scratch at IETF59, and it has been 574 improved based on feedback received both prior, during, and after the 575 session by numerous people. 577 Alain Durand, Alain Baudot, Jeroen Massar, and Hesham Soliman sent 578 substantive feedback, helping in improving this memo. Dave Thaler 579 contributed the majority of enterprise scenarios, and provided other 580 feedback as well. 582 8. References 584 8.1 Normative References 586 [1] Huitema, C., "Evaluation of Transition Mechanisms for Unmanaged 587 Networks", draft-ietf-v6ops-unmaneval-01 (work in progress), 588 February 2004. 590 [2] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks", 591 draft-ietf-v6ops-3gpp-analysis-09 (work in progress), March 592 2004. 594 [3] Lind, M., "Scenarios and Analysis for Introducing IPv6 into ISP 595 Networks", draft-ietf-v6ops-isp-scenarios-analysis-01 (work in 596 progress), February 2004. 598 [4] Bound, J., "IPv6 Enterprise Network Scenarios", 599 draft-ietf-v6ops-ent-scenarios-01 (work in progress), February 600 2004. 602 [5] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", 603 draft-huitema-v6ops-teredo-01 (work in progress), February 2004. 605 [6] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site 606 Automatic Tunnel Addressing Protocol (ISATAP)", 607 draft-ietf-ngtrans-isatap-20 (work in progress), February 2004. 609 [7] Savola, P., "Simple IPv6-in-IPv4 Tunnel Establishment Procedure 610 (STEP)", draft-savola-v6ops-conftun-setup-02 (work in progress), 611 January 2004. 613 [8] Blanchet, M., "IPv6 Tunnel Broker with the Tunnel Setup 614 Protocol(TSP)", draft-blanchet-v6ops-tunnelbroker-tsp-00 (work 615 in progress), February 2004. 617 8.2 Informative References 619 [9] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel 620 Broker", RFC 3053, January 2001. 622 [10] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 623 IPv4 Clouds", RFC 3056, February 2001. 625 [11] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 626 IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-02 (work in 627 progress), February 2004. 629 [12] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 630 Domains without Explicit Tunnels", RFC 2529, March 1999. 632 [13] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and 633 B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, 634 August 1999. 636 [14] Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in 637 Enterprise Networks", draft-chown-v6ops-vlan-usage-00 (work in 638 progress), October 2003. 640 [15] Clercq, J., "Connecting IPv6 Islands across IPv4 Clouds with 641 BGP", draft-ooms-v6ops-bgp-tunnel-02 (work in progress), March 642 2004. 644 Authors' Addresses 646 Pekka Savola 647 CSC/FUNET 649 Espoo 650 Finland 652 EMail: psavola@funet.fi 654 Jonne Soininen 655 Nokia 657 EMail: jonne.soininen@nokia.com 659 Intellectual Property Statement 661 The IETF takes no position regarding the validity or scope of any 662 Intellectual Property Rights or other rights that might be claimed to 663 pertain to the implementation or use of the technology described in 664 this document or the extent to which any license under such rights 665 might or might not be available; nor does it represent that it has 666 made any independent effort to identify any such rights. Information 667 on the IETF's procedures with respect to rights in IETF Documents can 668 be found in BCP 78 and BCP 79. 670 Copies of IPR disclosures made to the IETF Secretariat and any 671 assurances of licenses to be made available, or the result of an 672 attempt made to obtain a general license or permission for the use of 673 such proprietary rights by implementers or users of this 674 specification can be obtained from the IETF on-line IPR repository at 675 http://www.ietf.org/ipr. 677 The IETF invites any interested party to bring to its attention any 678 copyrights, patents or patent applications, or other proprietary 679 rights that may cover technology that may be required to implement 680 this standard. Please address the information to the IETF at 681 ietf-ipr@ietf.org. 683 Disclaimer of Validity 685 This document and the information contained herein are provided on an 686 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 687 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 688 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 689 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 690 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 691 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 693 Copyright Statement 695 Copyright (C) The Internet Society (2004). This document is subject 696 to the rights, licenses and restrictions contained in BCP 78, and 697 except as set forth therein, the authors retain all their rights. 699 Acknowledgment 701 Funding for the RFC Editor function is currently provided by the 702 Internet Society.