idnits 2.17.1 draft-blanchet-ngtrans-tsp-applicability-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (June 23, 2002) is 7971 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-vg-ngtrans-tsp-v6v4profile-00 -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-01) exists of draft-vg-ngtrans-tsp-00 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-01) exists of draft-blanchet-ngtrans-tsp-dstm-profile-00 -- Possible downref: Normative reference to a draft: ref. '3' -- No information found for draft-vg-ngtrans-tsp-teredo - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' -- No information found for draft-blanchet-ngtrans-tsp-compressed - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 3053 (ref. '6') Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Blanchet 3 Internet-Draft F. Parent 4 Expires: December 22, 2002 Viagenie inc. 5 June 23, 2002 7 Applicability of the Tunnel Setup Protocol(TSP) as an IPv6 Transition 8 Technique 9 draft-blanchet-ngtrans-tsp-applicability-00 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 22, 2002. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 There are multiple environments where IPv6 transition techniques can 41 be used. There are multiple IPv6 transition techniques. This 42 document describes the applicability of transition techniques based 43 on the Tunnel Setup Protocol(TSP) used in different environments, 44 such as: provider, enterprise, unmanaged networks, cable-dsl 45 operators, wireless operators, mobile hosts and networks. TSP 46 enables the automation of prefix assignment, DNS delegation and 47 routing preferences. TSP supports IPv6 over IPv4 and IPv4 over IPv6 48 encapsulations, as well as UDP-IPv4 encapsulation for IPv4 NAT 49 traversals, through automatic NAT discovery. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Description of the TSP framework . . . . . . . . . . . . . . . 3 55 2.1 NAT Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2 Any encapsulation . . . . . . . . . . . . . . . . . . . . . . 4 57 2.3 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.4 Compression of TSP . . . . . . . . . . . . . . . . . . . . . . 4 59 2.5 Advantages of TSP . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Applicability of TSP in Different Environments . . . . . . . . 5 61 3.1 Applicability of TSP in Provider Networks with Enterprise 62 Customers . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2 Applicability of TSP in Provider Networks with Home/Small 64 Office Customers . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.3 Applicability of TSP in Enterprise Networks . . . . . . . . . 6 66 3.4 Applicability of TSP in Wireless Networks . . . . . . . . . . 6 67 3.5 Applicability of TSP in Unmanaged networks . . . . . . . . . . 6 68 3.6 Applicability of TSP in Exchange Points . . . . . . . . . . . 7 69 3.7 Applicability of TSP for Mobile Hosts . . . . . . . . . . . . 7 70 3.8 Applicability of TSP for Mobile Networks . . . . . . . . . . . 7 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 75 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 This document first describes the TSP framework as well as the 80 different profiles used. It then describes the applicability of TSP 81 in different environments. 83 2. Description of the TSP framework 85 The experience with the freenet6.net Tunnel Broker [6] gave a good 86 input of what a real IPv6 deployment can be. A new generation of 87 Tunnel Broker was designed [2][1] based user inputs, management of 88 the service as well as requirements given by the community. This new 89 generation is based on a signaling protocol, called Tunnel Setup 90 Protocol (TSP). 92 Tunnel Setup Protocol (TSP) is a control/signaling protocol to setup 93 tunnel parameters between two tunnel end-points. TSP is implemented 94 as a tiny client code in the requesting tunnel end-point. The other 95 end-point is the TSP server. TSP uses XML basic messaging over TCP 96 or UDP. The use of XML gives extensibility and easy option 97 processing. 99 Inside a session, TSP can negociate between the two tunnel end- 100 points: 102 o authentication of the users, using any kind of authentication 103 mechanism as well as anonymous 105 o IPv6 over IPv4 tunnels 107 o IPv4 over IPv6 tunnels 109 o IPv6 over UDP-IPv4 tunnels, when IPv4 NAT are in the path between 110 the two endpoints 112 o IPv6 prefix assignment of any size 114 o DNS delegation of the inverse tree, based on the ipv6 prefix 115 assignment 117 o Routing protocols 119 o etc. 121 The TSP connexion can be established between two nodes, where each 122 node can control a tunnel end-point. In this context, it is possible 123 to have up to 4 parties involved: 1- the tsp client, 2- controlling 124 the requesting tunnel end-point, 3- the tsp server, 4- controlling 125 the receiving tunnel end-point. 1,3 and 4 is the Tunnel Broker 126 model. 1 and 2 can be on the same node, as well as 3 and 4 can be on 127 the same node. 129 From the point of view of an operating system, TSP is implemented as 130 a client application which is able to configure network parameters of 131 the kernel and operating system. 133 2.1 NAT Discovery 135 TSP is also used to discover if a NAT is in the path. In this 136 discovery mode, the client sends a TSP message, containing its source 137 tunnel information and the request for the tunnel over UDP-IPv4 to 138 the TSP server. The TSP server verifies if the inner information was 139 not changed by an IPv4 NAT in the path. 141 If an IPv4 NAT is discovered, then UDP-IPv4 encapsulation of the IPv6 142 tunnel is used[4]. If there is no IPv4 NAT in the path, then usual 143 IPv6 in IPv4 encapsulation is used[1]. When the TSP client moves to 144 another network, the same discovery process is done. This IPv4 NAT 145 discovery builds the most effective tunnel for all cases, and in a 146 dynamic situation where the client moves. 148 Considering the current dominant IPv4 networks and the current use of 149 mobile devices, this NAT discovery is very useful, given that with 150 TSP, the client always keeps the same IPv6 addresses, prefixes, dns 151 delegation, routing, etc.. 153 2.2 Any encapsulation 155 TSP is used to negociate IPv6 over IPv4 tunnels[1], IPv6 over UDP- 156 IPv4 tunnels [4] and IPv4 over IPv6 tunnels [3]. IPv4 in IPv6 157 tunnels are used in the Dual Stack Transition Mechanism (DSTM) 158 together with TSP [3]. 160 2.3 Mobility 162 When a tunnel endpoint changes its underlying IP address (i.e. 163 change of its IPv4 address when doing IPv6 in IPv4 encapsulation), 164 the TEP operating system restart the TSP client to refresh the new 165 information to the TSP server. With the response of the TSP server, 166 the tunnel is re-established using the new information. This enables 167 mobility of the tunnel end-point. 169 2.4 Compression of TSP 171 In bandwidth-limited environments, TSP can be compressed [5]. 173 2.5 Advantages of TSP 175 o A signaling protocol to establish the tunnel: no need to change 176 kernels, routing... 178 o A signaling protocol flexible and extensible 180 o one solution to many encapsulation techniques: v6 in v4, v4 in v6, 181 v6 over udp over v4, ... 183 o prefix assignment 185 o dns delegation 187 o routing negociation 189 o discovery of IPv4 NAT in the path, establishing the most optimized 190 tunnelling technique depending on the discovery. 192 o mobility of the underlying IP node. 194 o two to four tier tunnel broker model 196 o signaling protocol can be compressed in bandwidth-limited 197 environments 199 3. Applicability of TSP in Different Environments 201 This section describes the applicability of TSP in different 202 environments. 204 3.1 Applicability of TSP in Provider Networks with Enterprise Customers 206 In a provider network where IPv4 is dominant, a tunnelled 207 infrastructure can be used to provider IPv6 services to the 208 enterprise customers, before a full IPv6 native infrastructure is 209 built. In order to start deploying in a controlled manner and to 210 give enterprise customers a prefix, the TSP framework is used. The 211 TSP server can be put in the core, in the aggregation points or in 212 the pops to offer the service to the customers. IPv6 over IPv4 213 encapsulation[1] can be used. If the customers are behind an IPv4 214 NAT, then IPv6 over UDP-IPv4 encapsulation [4] can be used. 216 3.2 Applicability of TSP in Provider Networks with Home/Small Office 217 Customers 219 In a provider network where IPv4 is dominant, a tunnelled 220 infrastructure can be used to provider IPv6 services to the home/ 221 small office customers, before a full IPv6 native infrastructure is 222 built. In order to start deploying in a controlled manner and to 223 give customers a prefix, the TSP framework is used. The TSP server 224 can be put in the core, in the aggregation points or in the pops to 225 offer the service to the customers. IPv6 over IPv4 encapsulation[1] 226 can be used. If the customers are behind an IPv4 NAT, then IPv6 over 227 UDP-IPv4 encapsulation [4] can be used. 229 Automation of the prefix assignment and DNS delegation, done by TSP, 230 is a very important feature for a provider in order to substantially 231 decrease support costs. The provider can use the same authentication 232 database that is used to authenticate the IPv4 users. Customers can 233 deploy home IPv6 networks without any intervention of the provider 234 support people. 236 With the NAT discovery function of TSP, providers can use the same 237 TSP infrastructure for both NAT and not-NAT parts of the network. 239 3.3 Applicability of TSP in Enterprise Networks 241 In an enterprise network where IPv4 is dominant, a tunnelled 242 infrastructure can be used to provider IPv6 services to the IPv6 243 islands (hosts or networks) inside the enterprise, before a full IPv6 244 native infrastructure is built. TSP can be used to give IPv6 245 connectivity, prefix and routing for the islands. This gives to the 246 enterprise a full control deployment of IPv6 while maintaining 247 automation and permanence of the IPv6 assignments to the islands. 249 3.4 Applicability of TSP in Wireless Networks 251 In a wireless network where IPv4 is dominant, hosts and networks move 252 and change IPv4 address. TSP enables the automatic re-establishment 253 of the tunnel when the IPv4 address change. 255 In a wireless network where IPv6 is dominant, hosts and networks 256 move. TSP enables the automatic re-establishment of the tunnel 257 together with the DSTM mechasnism [3]. 259 TSP can be compressed [5] for bandwidth-limited networks. 261 3.5 Applicability of TSP in Unmanaged networks 263 An unmanaged network is where no network manager or staff is 264 available to configure network devices. TSP is particularly powerful 265 in this context where automation of all necessary information for the 266 IPv6 connectivity is handled by TSP: tunnel end-points parameters, 267 prefix assignment, dns delegation, routing. 269 An unmanaged network may be behind a NAT, maybe not. With the NAT 270 discovery function, TSP works automatically in both cases. 272 3.6 Applicability of TSP in Exchange Points 274 TSP can be used to connect the providers that have only IPv4 275 connectivity to the exchange point. This gives to the exchange point 276 a tool to reach customers who are not ready for native IPv6 277 connectivity. 279 3.7 Applicability of TSP for Mobile Hosts 281 Mobile hosts are common and used. Laptops moving from wireless, 282 wired in office, home, ... are examples. They often have IPv4 283 connectivity, but not necessarily IPv6. TSP framework enables the 284 mobile hosts to have IPv6 connectivity wherever they are, by having 285 the TSP client sends updated information of the new environment to 286 the TSP server, when a change occur. Together with NAT discovery, 287 the mobile host can be always IPv6 connected wherever it is. 289 Mobile here means only the change of IPv4 address. MobileIP 290 mechanisms and fast handoff take care of additional constraints in 291 mobile environments. 293 3.8 Applicability of TSP for Mobile Networks 295 Mobile networks share the applicability of the mobile hosts. 296 Moreover, in the TSP framework, they also keep their prefix 297 assignment and can control the routing. NAT discovery can also be 298 used. 300 4. Security Considerations 302 This document does not specify any protocol. It describes the 303 applicability of a protocol and a set of profiles. Security 304 considerations are described in each document describing the protocol 305 or a profile. 307 It should be noted however that this signaling protocol together with 308 authentication makes the tunnel server a more robust server than 309 other transition techniques that have the server as an open relay. 311 5. Conclusion 313 The Tunnel Setup Protocol (TSP) is applicable in many environments, 314 such as: providers, enterprises, wireless, unmanaged networks, mobile 315 hosts and networks. TSP gives the two tunnel end-points the ability 316 tonegociate tunnel parameters, as well as prefix assignment, dns 317 delegation and routing in an authenticated session. It also provides 318 IPv4 NAT discovery function by using the most effective 319 encapsulation. It also supports the IPv4 mobility of the nodes. 321 References 323 [1] Blanchet, M., "IPv6 over IPv4 profile for Tunnel Setup Protocol 324 (TSP)", draft-vg-ngtrans-tsp-v6v4profile-00 (work in progress), 325 July 2001. 327 [2] Blanchet, M., "Tunnel Setup Protocol (TSP)", draft-vg-ngtrans- 328 tsp-00 (work in progress), July 2001. 330 [3] Blanchet, M., "DSTM IPv4 over IPv6 tunnel profile for Tunnel 331 Setup Protocol(TSP)", draft-blanchet-ngtrans-tsp-dstm-profile-00 332 (work in progress), February 2002. 334 [4] Blanchet, M. and F. Parent, "TSP-TEREDO: Stateful IPv6 over IPv4 335 Tunnels with NAT using TSP and TEREDO", draft-vg-ngtrans-tsp- 336 teredo-00 (work in progress), June 2002. 338 [5] Blanchet, M., "Compression of the Tunnel Setup Protocol(TSP)", 339 draft-blanchet-ngtrans-tsp-compressed-00 (work in progress), 340 June 2002. 342 [6] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel 343 Broker", RFC 3053, January 2001. 345 Authors' Addresses 347 Marc Blanchet 348 Viagenie inc. 349 2875 boul. Laurier, bureau 300 350 Sainte-Foy, QC G1V 2M2 351 Canada 353 Phone: +1 418 656 9254 354 EMail: Marc.Blanchet@viagenie.qc.ca 355 URI: http://www.viagenie.qc.ca/ 356 Florent Parent 357 Viagenie inc. 358 2875 boul. Laurier, bureau 300 359 Sainte-Foy, QC G1V 2M2 360 Canada 362 Phone: +1 418 656 9254 363 EMail: Florent.Parent@viagenie.qc.ca 364 URI: http://www.viagenie.qc.ca/ 366 Full Copyright Statement 368 Copyright (C) The Internet Society (2002). All Rights Reserved. 370 This document and translations of it may be copied and furnished to 371 others, and derivative works that comment on or otherwise explain it 372 or assist in its implementation may be prepared, copied, published 373 and distributed, in whole or in part, without restriction of any 374 kind, provided that the above copyright notice and this paragraph are 375 included on all such copies and derivative works. However, this 376 document itself may not be modified in any way, such as by removing 377 the copyright notice or references to the Internet Society or other 378 Internet organizations, except as needed for the purpose of 379 developing Internet standards in which case the procedures for 380 copyrights defined in the Internet Standards process must be 381 followed, or as required to translate it into languages other than 382 English. 384 The limited permissions granted above are perpetual and will not be 385 revoked by the Internet Society or its successors or assigns. 387 This document and the information contained herein is provided on an 388 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 389 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 390 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 391 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 392 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 394 Acknowledgement 396 Funding for the RFC Editor function is currently provided by the 397 Internet Society.